Wednesday, 2014-06-11

*** pidge <pidge!pidge@nat/intel/x-evgdvvfjuqpsjnxl> has quit IRC00:01
*** maxtothemax <maxtothemax!maxtothema@nat/intel/x-gkbfaskprsskyfje> has quit IRC00:16
-YoctoAutoBuilder- build #132 of nightly-qa-logrotate is complete: Success [build successful] Build details are at
*** Jefro <Jefro!> has quit IRC00:24
*** sjolley <sjolley!~sjolley@> has joined #yocto00:35
*** sameo <sameo!~samuel@> has quit IRC00:38
*** radzy_ is now known as radzy_away00:38
*** Squix <Squix!> has joined #yocto00:42
*** adelcast <adelcast!~adelcast@> has quit IRC00:45
*** munch <munch!> has quit IRC00:47
-YoctoAutoBuilder- build #134 of nightly-x32 is complete: Success [build successful] Build details are at
*** dvhart <dvhart!dvhart@nat/intel/x-cbcyxblniqwrezqi> has joined #yocto01:40
*** nitink1 <nitink1!nitink@nat/intel/x-medrmahilqpyfmfv> has joined #yocto01:59
*** nitink <nitink!nitink@nat/intel/x-azwzbrnfclkwdfpp> has quit IRC02:02
-YoctoAutoBuilder- build #132 of nightly-qa-systemd is complete: Success [build successful] Build details are at
*** nitink1 <nitink1!nitink@nat/intel/x-medrmahilqpyfmfv> has quit IRC02:07
*** rcw <rcw!> has joined #yocto02:09
*** rcw <rcw!> has quit IRC02:21
*** simmel80___ <simmel80___!> has joined #yocto02:22
*** simmel80 <simmel80!> has quit IRC02:25
*** joeythesaint <joeythesaint!~joe@> has quit IRC03:04
*** Squix <Squix!> has quit IRC03:18
*** Squix <Squix!> has joined #yocto03:19
*** nitink <nitink!~nitink@> has joined #yocto03:26
*** Jefro <Jefro!> has joined #yocto03:26
*** LCyrin <LCyrin!~LCyrin@2607:fb90:2709:2306:5a05:b2e7:1af4:636f> has quit IRC03:28
*** dvhart <dvhart!dvhart@nat/intel/x-cbcyxblniqwrezqi> has quit IRC03:33
*** michael_e_brown <michael_e_brown!> has quit IRC03:35
*** sgw_ <sgw_!> has joined #yocto03:49
*** Jefro <Jefro!> has quit IRC03:58
*** Jefro <Jefro!> has joined #yocto04:15
*** lsb_tester <lsb_tester!~milan@> has quit IRC04:29
*** kalyank <kalyank!> has joined #yocto04:44
*** zecke <zecke!> has joined #yocto04:48
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-xukcmavgeixpjala> has joined #yocto04:57
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-idamwqsgsecrrlub> has joined #yocto05:02
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-kqfsyeocvszgzleg> has joined #yocto05:06
*** Jefro <Jefro!> has quit IRC05:07
*** tyler-baker <tyler-baker!~tyler@linaro/tyler-baker> has quit IRC05:08
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-igyrabivqvkoqkip> has joined #yocto05:11
*** lsb_tester <lsb_tester!~milan@> has joined #yocto05:14
*** radzy_away is now known as radzy_05:15
*** radzy_ is now known as radzy_away05:15
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-hwehcctuklbqljrt> has joined #yocto05:16
*** Jefro <Jefro!> has joined #yocto05:17
*** Jefro <Jefro!> has quit IRC05:19
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-kwsrxumrjscpnhqu> has joined #yocto05:20
*** sachin__ <sachin__!~sachin@> has joined #yocto05:23
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-juryrnjikeuvadtm> has joined #yocto05:26
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-uihkriouhkmbveny> has joined #yocto05:30
*** agust <agust!> has joined #yocto05:33
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-ayxifvzlrtkrpzze> has joined #yocto05:34
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-daldickykjwxtcbb> has joined #yocto05:40
*** blloyd <blloyd!> has joined #yocto05:42
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-lwmnjwshfwudveuw> has joined #yocto05:44
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-rafjmvztvnfcgsft> has joined #yocto05:48
*** Jefro <Jefro!> has joined #yocto05:50
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-spgbhwmowhayqiaq> has joined #yocto05:54
*** qt-x <qt-x!~ionel@> has joined #yocto05:57
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-rnswqzxhvtrurldb> has joined #yocto05:58
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-qmivgbphkjprlqup> has joined #yocto06:02
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-zogajplwollgzpei> has joined #yocto06:08
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-tjmtsrgatyblpgdf> has joined #yocto06:12
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto06:13
*** TobSnyder <TobSnyder!> has joined #yocto06:13
zeckeAre there any known issues with quilt-native/chrpath on Ubuntu?06:13
zecke(12.04 LTS) and Dora?06:13
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-kfzfzlanvenatzel> has joined #yocto06:17
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-oswrxmmveeibctzc> has joined #yocto06:22
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-hxcawvfqjeqipdxb> has joined #yocto06:26
zeckeRP: how can I see the output of a bb.note from within a python routine?06:29
zeckeRP: it is not printed to my pty, it doesn't show up in the log file. I am semi-confident that the code got executed06:30
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-xkosiyoagqzmqwrs> has joined #yocto06:31
zeckelooks like I had to nuke the cache too06:32
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-qejkcmjsjanvjvjb> has joined #yocto06:36
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-pfulsehrmevcbuth> has joined #yocto06:40
*** nitink <nitink!~nitink@> has quit IRC06:40
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-pfulsehrmevcbuth> has quit IRC06:40
*** nitink <nitink!nitink@nat/intel/x-qwirkzthrbrjjgku> has joined #yocto06:42
*** kroon <kroon!> has quit IRC06:43
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-hzegtbezgifeatla> has joined #yocto06:45
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-jjjodfdmcriovtwu> has joined #yocto06:54
*** eballetbo <eballetbo!> has joined #yocto06:56
*** zecke <zecke!> has quit IRC07:02
*** neabax <neabax!~neabax@> has joined #yocto07:12
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC07:16
*** g1zer0 <g1zer0!> has joined #yocto07:16
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto07:18
*** kroon <kroon!~kroon@> has joined #yocto07:21
*** nitink <nitink!nitink@nat/intel/x-qwirkzthrbrjjgku> has quit IRC07:22
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto07:26
*** jbrianceau_away is now known as jbrianceau07:26
*** rburton <rburton!> has quit IRC07:30
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto07:34
*** mckoan|away is now known as mckoan07:34
mckoangood morning07:34
*** rburton <rburton!> has joined #yocto07:36
*** nitink <nitink!nitink@nat/intel/x-ajxntcvquxvcbayc> has joined #yocto07:38
*** vmeson <vmeson!~quassel@> has quit IRC07:42
*** vmeson <vmeson!~quassel@> has joined #yocto07:44
*** rburton <rburton!> has quit IRC07:44
*** rburton <rburton!> has joined #yocto07:45
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:53
*** rink <rink!50f6c8c8@gateway/web/freenode/ip.> has joined #yocto07:54
*** rink is now known as rink_07:54
rink_hi all :)07:54
rink_anyone have time for a quick q? i'm trying to make an initrd/initramfs-based rootfs.cpio.gz - it builds okay, but includes the zImage which I obviously don't want07:55
*** rburton <rburton!> has quit IRC07:55
rink_how can I ensure the kernel image ends up in tmp/deply/zImage, but won't be part of the rootfs?07:55
*** rburton <rburton!> has joined #yocto07:55
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has quit IRC07:57
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto07:58
RPrink_: looking at kernel.bbclass, RDEPENDS_kernel-base = "" looks like it might help07:58
rink_hmm I also just noticed it was part of IMAGE_INSTALL_append = "kernel"07:58
rink_is it safe just to 'rm -rf tmp' and bitbake the image again to be sure it builds what I need?07:59
RPrink_: that dependency won't help, yes07:59
RPrink_: should be safe although even if you don't do that, it should adjust to the changes08:00
rink_Well, for your platform, I need a separate kernel, rootfs  and devicetrees, combined in a single custom image08:01
rink_s/your/our/ # doh08:01
*** Jefro <Jefro!> has quit IRC08:03
RPrink_: shouldn't be a problem, its just a matter of configuration. if you change the image configuration, it should get accurately regenerated as per the change08:04
*** sameo <sameo!~samuel@> has joined #yocto08:11
*** sameo <sameo!~samuel@> has joined #yocto08:12
*** radzy_away <radzy_away!~radzy@> has quit IRC08:12
*** radzy_away <radzy_away!~radzy@> has joined #yocto08:13
*** nitink <nitink!nitink@nat/intel/x-ajxntcvquxvcbayc> has quit IRC08:17
*** nitink1 <nitink1!~nitink@> has joined #yocto08:17
*** nitink1 <nitink1!~nitink@> has quit IRC08:32
*** nitink <nitink!nitink@nat/intel/x-ktbnspfrokgcaced> has joined #yocto08:33
*** ant_work <ant_work!> has joined #yocto08:35
*** pev <pev!~pev@> has quit IRC08:42
*** 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
bluelightningmorning all09:01
*** belen <belen!Adium@nat/intel/x-rkitochfuyniblzn> has joined #yocto09:02
*** _valle_ <_valle_!> has quit IRC09:03
*** Denwid <Denwid!c2cc4226@gateway/web/freenode/ip.> has joined #yocto09:03
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has quit IRC09:06
*** _valle_ <_valle_!> has joined #yocto09:06
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto09:08
*** neabax <neabax!~neabax@> has quit IRC09:14
*** Squix <Squix!> has quit IRC09:20
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC09:20
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto09:22
rink_hmm, I've added custom image_type, with IMAGE_CMD_custom = ..., but it isn't buitl09:29
rink_the .bbclass is built, however09:29
rink_uhm ,i mean, it is processed09:30
*** JimBaxter <JimBaxter!> has joined #yocto09:35
*** lsb_tester <lsb_tester!~milan@> has quit IRC09:36
rink_I've made classes/image_type_sys.bb09:42
rink_added it using IMAGE_CLASSES += "image_type_sys" in the machine.conf file09:42
rink_the .bb is processed09:42
rink_the machine.conf contains IMAGE_FSTYPES = "sys"09:42
rink_however, the IMAGE_CMD_sys = "..." command in the file isn't called09:43
rink_why not?09:43
ant_workrink_: ^09:47
rink_isn't that exactly what I am doing?09:47
ant_worknote IMAGE_TYPES =09:47
rink_hmm, my 'sys' type shows up in bitbake -e |grep ^IMAGE_TYPES09:48
rink_so why is it ignoring the IMAGE_CMD_sys = "..." thing completely ? how can I find what it does?09:49
ant_workyou have to check the logs and the run. files in the image workdir09:51
*** mulhern <mulhern!~mulhern@> has joined #yocto09:52
rink_this is odd09:54
rink_the command _does_ get executed after a cleansstate09:54
rink_how does yocto decide that the command should be run?09:54
ant_workshort version: if the checksum of the task has changed09:55
ant_workbtw, it is bitbake and not Yocto09:56
rink_hmmm, I don't see a means to tell my image recipe what the output file is09:56
Denwidwhat do you mean by output file?09:59
Denwidwhat kind of filesystem?09:59
rink_i'm making a TAR file of the kernel, the initrd, the boot script and the device tree09:59
Denwidah that's what you want to do...10:00
rink_odd thing is10:00
rink_now that I've run cleansstate, it will rebuild the file as needed10:01
-YoctoAutoBuilder- build #140 of nightly-arm is complete: Success [build successful] Build details are at
Denwidyou ran bitbake yourimage -c cleansstate and now it works?10:03
Denwidit seems that bitbake doesn't recognize a new IMAGE_CMD_  it automatically, it probably decided to not run do_rootfs alltogether since you ran it before already and didn't change the image recipe10:07
*** belen <belen!Adium@nat/intel/x-rkitochfuyniblzn> has quit IRC10:07
*** zecke <zecke!~ich@> has joined #yocto10:08
Denwidsometimes it can be a little difficult with the whole dependecy chains and stuff, especially with features like IMAGE_CMD_ or thelike.10:08
rink_I can imagine that :)10:09
rink_hmm it never even seems to rebuild the IMAGE_CMD_ ... likely because the input hasn't changed10:10
*** ant_work <ant_work!> has quit IRC10:10
DenwidI think the IMAGE_CMD is part of the do_rootfs task and if thatone isn't run then so is the IMAGE_CMD_10:10
DenwidYou can probably force it with bitbake yourimage -c rootfs -f10:11
DenwidIf you know everything up to that point is already as it should be10:12
*** zecke <zecke!~ich@> has quit IRC10:15
*** zecke <zecke!~ich@> has joined #yocto10:15
zeckebluelightning: ping?10:16
*** ant_work <ant_work!> has joined #yocto10:16
rink_hhmmm after deleting 'tmp' my deploy directory is almost empty :(10:19
rink_save for modules-*10:19
rink_Denwid, and after doing the -c rootfs -s line, I don't have my own tar file but the rest is built10:21
rink_this is off10:21
rink_*scratches had*10:21
rink_head, even10:21
Denwidmhh did you have a look at the logs in tmp/work/*/yourimage/temp?10:29
rink_need to be afk, will have a look afterwards10:30
rink_Denwid, ant_work, thanks!10:31
*** zecke <zecke!~ich@> has quit IRC10:57
*** Krampus <Krampus!> has quit IRC11:02
*** Krampus <Krampus!> has joined #yocto11:02
*** roxell <roxell!~roxell@linaro/roxell> has quit IRC11:18
*** smurray <smurray!> has quit IRC11:18
*** roxell <roxell!~roxell@linaro/roxell> has joined #yocto11:18
*** smurray <smurray!> has joined #yocto11:18
*** ndec <ndec!~ndec@linaro/ndec> has quit IRC11:18
*** ndec <ndec!~ndec@linaro/ndec> has joined #yocto11:19
*** AlexVaduva <AlexVaduva!c1ca1642@gateway/web/freenode/ip.> has quit IRC11:20
*** jluisn <jluisn!~quassel@> has joined #yocto11:24
*** fray <fray!> has quit IRC11:27
*** scot_ <scot_!~scot@> has joined #yocto11:30
*** fray <fray!U2FsdGVkX1@> has joined #yocto11:32
*** scot <scot!~scot@> has quit IRC11:32
*** fray <fray!U2FsdGVkX1@> has quit IRC11:34
*** zyla <zyla!> has quit IRC11:36
*** jmpdelos <jmpdelos!> has quit IRC11:36
*** jmpdelos <jmpdelos!> has joined #yocto11:36
*** zyla <zyla!> has joined #yocto11:37
TobSnyderwhen running GST_DEBUG=5 with my application, I do see full path of where GStreamer was built11:38
TobSnyder0:00:00.003091334   941   0x261200 DEBUG             GST_MEMORY /data/BoundaryDevices/yocto/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.2.4-r0/gstreamer-1.2.4/gst/gstallocator.c:586:_priv_gst_memory_initialize: memory alignment: 711:38
TobSnyderis there a way to remove that path, bevause it makes GST Logs hard to read?11:39
rburtontobiash: sed?11:39
rburtonthe log contains the source, so you either change the logging code to remove that, or sed it out before reading11:40
*** belen <belen!~Adium@> has joined #yocto11:41
*** Denwid <Denwid!c2cc4226@gateway/web/freenode/ip.> has quit IRC11:49
*** lyang0 <lyang0!~lyang001@> has quit IRC11:55
*** sachin__ <sachin__!~sachin@> has quit IRC11:55
*** lyang0 <lyang0!~lyang001@> has joined #yocto11:55
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC11:56
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto11:56
*** diego_r <diego_r!> has joined #yocto12:02
*** zecke <zecke!~ich@> has joined #yocto12:03
*** joeythesaint <joeythesaint!~joe@> has joined #yocto12:05
*** zecke <zecke!~ich@> has quit IRC12:08
*** zecke <zecke!~ich@> has joined #yocto12:10
TobSnyderthe same message on my PC:12:12
TobSnyder0:00:00.000197984 25813      0x2140a00 DEBUG             GST_MEMORY gstallocator.c:586:_priv_gst_memory_initialize: memory alignment: 712:12
TobSnyderI have never seen logs with full paths before, so I assume it is some configuration of yocto / poky compiler ?12:13
*** diego_ <diego_!> has joined #yocto12:15
*** diego_r <diego_r!> has quit IRC12:15
*** diego_ is now known as diego_r12:15
*** sroy_ <sroy_!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has joined #yocto12:19
*** RP <RP!> has quit IRC12:27
*** adelcast <adelcast!~adelcast@> has joined #yocto12:30
*** sakoman1 <sakoman1!> has joined #yocto12:32
*** sakoman <sakoman!> has quit IRC12:34
*** RP <RP!> has joined #yocto12:38
*** sakoman1 <sakoman1!> has quit IRC12:38
*** JaMae <JaMae!> has joined #yocto12:39
*** zyla <zyla!> has quit IRC12:42
*** zyla1 <zyla1!> has joined #yocto12:42
*** msm <msm!> has joined #yocto12:46
*** abelloni_ <abelloni_!> has joined #yocto12:46
*** RagBal <RagBal!> has quit IRC12:47
*** Rootert <Rootert!> has quit IRC12:47
*** RagBal <RagBal!> has joined #yocto12:48
*** Denwid <Denwid!c2cc4226@gateway/web/freenode/ip.> has joined #yocto12:48
*** abelloni <abelloni!> has quit IRC12:48
*** Rootert <Rootert!> has joined #yocto12:48
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC12:49
*** thaytan <thaytan!> has quit IRC12:49
*** thaytan_ <thaytan_!> has joined #yocto12:49
*** maxin <maxin!> has quit IRC12:50
*** maxin <maxin!> has joined #yocto12:50
*** sakoman <sakoman!> has joined #yocto12:53
*** bfederau <bfederau!> has quit IRC13:01
*** bfederau <bfederau!> has joined #yocto13:01
*** zecke <zecke!~ich@> has quit IRC13:05
*** zecke <zecke!~ich@> has joined #yocto13:11
rink_otavio, help - still can't get the gpu-viv samples to be removed13:16
rink_well, I can, but not without losing the libraries as well13:16
rink_if anyone reads, includes - see
rink_I've made a .bbappend file - see
rink_the idea is to throw away everything in /opt/viv_samples and keep the libraries it installs intact13:18
rink_but the result is that absolutely nothing of the gpu-viv- ... recipe is installed anymore13:18
rink_Help! :)13:18
rink_i wonder if the problem is that bb things: Hey, these libraries aren't needed by anything => let's remove them from the image13:26
*** codinho <codinho!> has joined #yocto13:28
*** codinho <codinho!~me@unaffiliated/codinho> has joined #yocto13:28
*** ant_work <ant_work!> has quit IRC13:28
*** dmoseley <dmoseley!> has quit IRC13:30
*** kapare <kapare!> has quit IRC13:32
*** adelcast <adelcast!~adelcast@> has quit IRC13:35
*** rcw <rcw!~rwoolley@> has joined #yocto13:35
rink_otavio, turns out adding the lib*-mx6 specifically to IMAGE_INSTALL_append solves it for me; it was indeed deciding no one needed the libs13:37
otaviorink_: uh?13:38
rink_scroll up a bit? :)13:38
rink_as before, I was having problems with removing the viv_samples directory from the installed image - this would also remove libGLES etc13:39
rink_but adding IMAGE_INSTALL_append += 'libgles-mx6'   fixes this for me13:40
*** scot_ <scot_!~scot@> has quit IRC13:45
*** fray <fray!> has joined #yocto13:45
*** blitz00 <blitz00!~stefans@> has joined #yocto13:47
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto13:47
*** scot <scot!~scot@> has joined #yocto13:47
*** belen <belen!~Adium@> has quit IRC13:53
*** radzy_away is now known as radzy_13:55
*** mkeeter <mkeeter!~mkeeter@> has joined #yocto14:05
*** sjolley <sjolley!~sjolley@> has quit IRC14:07
*** RP <RP!> has quit IRC14:09
*** RP <RP!> has joined #yocto14:09
eliza411RP, I have some preliminary prototype work on for your review and shared some notes with your lf address14:10
eliza411RP, things are just roughed in right now. I won't focus on visual presentation too much until the structure and naming are right.14:11
*** Mahesh__ <Mahesh__!~sachin@> has joined #yocto14:14
mkeeteranyone around that’s comfortable with formfactor stuff?14:14
mkeeterI’m trying to figure out how to rebuild when I change a machconfig file14:15
mkeeterbecause I’m unclear where that configuration data actually goes14:15
*** RP <RP!> has quit IRC14:17
*** RP <RP!> has joined #yocto14:17
*** simmel80___ <simmel80___!> has quit IRC14:19
*** simmel80_ <simmel80_!> has joined #yocto14:20
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC14:22
iontehi. i need to refetch a recipe (using git). so i run: bitbake linux-raspberrypi -c fetch -f14:24
ionteumm, wait..14:25
ionteit seems to have worked anyway. nevermind...14:25
ionteok, another problem. anyone familiar with the raspberry pi bsp? i can't get "kernel_configure_variable" to work..14:27
*** qt-x <qt-x!~ionel@> has quit IRC14:28
ionteumm, wait ... :)14:28
*** sjolley <sjolley!sjolley@nat/intel/x-wuapkyiikzjmiirz> has joined #yocto14:29
*** simmel80_ <simmel80_!> has quit IRC14:34
*** simmel80_ <simmel80_!> has joined #yocto14:36
*** kroon <kroon!~kroon@> has quit IRC14:38
zeckebluelightning: ping?14:39
bluelightningzecke: pong14:39
zeckebluelightning: I think gmane ate my mail. Should lead to the pseudo sources?14:40
*** munch <munch!> has joined #yocto14:40
bluelightningzecke: did you have that link from somewhere else?14:41
bluelightningah, it's in the recipe isn't it14:42
zeckebluelightning: in dora14:42
bluelightningso the answer is yes it absolutely should14:42
zeckebluelightning: but it looks like it is broken in master too14:42
bluelightningzecke: I am filing a bug now14:42
zeckethanks. i didn't know who to chase. :)14:43
yoctiBug 6426: major, Undecided, ---, melissa, NEW , pseudo broken download14:47
*** armpit <armpit!> has joined #yocto14:47
*** adelcast <adelcast!~adelcast@> has joined #yocto14:53
*** mebrown <mebrown!> has joined #yocto14:54
*** g1zer0 <g1zer0!> has quit IRC14:59
*** tyler-baker <tyler-baker!~tyler@linaro/tyler-baker> has joined #yocto15:01
*** simmel80 <simmel80!> has joined #yocto15:01
*** simmel80_ <simmel80_!> has quit IRC15:02
ionteok. anyone in the knows about meta-raspberrypi? i've created a bbappend for the kernel. i've added do_configure_prepend to it and included kernel_configure_variable to change some defaults.15:05
ionteit doesn't work though15:05
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC15:06
ionteif i understand it correctly do_configure_prepend in my bbappend is called first, and then do_configure_prepend in meta-raspberrypi. and meta-raspberrypi clears all my changes at the start...15:06
ionteso what is the preferred way to change some kernel configs with meta-raspberrypi?15:06
*** dvhart <dvhart!dvhart@nat/intel/x-pdeasqmscgvrjfcg> has joined #yocto15:06
blloydionte: is there a reason you don't do an append instead?15:08
*** simmel80_ <simmel80_!> has joined #yocto15:08
ionteblloyd: yes. the kernel_configure_variable simply appends to the .config file.15:08
ionteblloyd: so if i use append i can get CONFIG_SPI_SPIDEV=y in the middle of the file, and then my "# CONFIG_SPI_SPIDEV not set" at the end of the file15:09
*** simmel80 <simmel80!> has quit IRC15:09
blloydperhaps do a sed in an append operation?15:15
bluelightningthat's exactly what config fragments are designed to allow15:15
*** _ccube <_ccube!ccube@2a01:4f8:130:1014::54> has joined #yocto15:22
volker-721.0K  grub-sparc64-setup15:26
mkeeterI’ve got a second question related to machines and formfactors:15:28
mkeeterwhat’s the difference between enabling keyboard in MACHINE_FEATURES and setting HAVE_KEYBOARD=y in a formfactor machconfig?15:28
mkeeterany enlightenment would be much appreciated15:28
rburtonmachine features control what hardware the machine has and generally control things like kernel modules15:29
rburtonformfactors are unrelated and saying HAVE_KEYBOARD tells eg Sato that it doesn't need to display a virtual keyboard because you have a real one15:29
mkeeterhuh, okay15:30
mkeeterand formfactors are chosen based on machine name15:31
mkeeterokay, it looks like HAVE_KEYBOARD ends up as a bash variable15:31
mkeeterwhich can then be used in other things15:31
*** belen <belen!Adium@nat/intel/x-vhhtnwiabxlgvcei> has joined #yocto15:31
*** vquicksilver <vquicksilver!> has joined #yocto15:31
*** vquicksilver <vquicksilver!~wolf@gentoo/contributor/vquicksilver> has joined #yocto15:31
mkeeterah, and formfactor/config gets called in things like sato config scripts15:32
mkeeteralright, that makes sense15:32
*** fusman <fusman!~fahad@> has quit IRC15:34
*** vquicksilver <vquicksilver!~wolf@gentoo/contributor/vquicksilver> has quit IRC15:38
*** Piziwate <Piziwate!5503efcb@gateway/web/freenode/ip.> has joined #yocto15:45
PiziwateHello, I've a simple bbappend recipe question...15:45
PiziwateI'm building several images with Yocto Daisy. One use meta-ti and others only Yocto. I've created a kernel bbappend for ti-linux-staging in my own meta.15:46
*** Jefro <Jefro!> has joined #yocto15:47
PiziwateNow if i want to build an image not based on meta-ti I got an error :  No recipes available for...15:47
PiziwateThis is normal because my current build doesn't include meta-ti... how can I solve that ?15:48
dvhartPiziwate, which recipes aren't available?15:48
dvhartwhich image are yout rying to build15:48
dvhartwhich machine?15:48
kergothhe has a general layer that wants to bbappend to a bsp specific recipe, and wants to use it whether that bsp layer is included or not15:48
*** TobSnyder <TobSnyder!> has quit IRC15:48
Piziwatethe linux-ti-staging15:48
kergothi've had to support that case before15:48
Piziwatethis is my own machine file15:48
Piziwateyes Kergoth you're right15:49
kergothyou can split up your layer into two, one with the ti specifics and one without, or you can structure your layer to support layer-specific appends15:49
kergothwe do this in meta-mentor15:49
Piziwatelayer-specific appends will be a good choice...15:50
kergoththen you can create a subdir in your layer from the layer name . e.g. move your recipes-kernel/linux/linux-ti-staging_3.12.bbappend to meta-ti/recipes-kernel/linux/linux-ti-staging_3.12.bbappend15:50
kergoththat'll only be included when meta-ti is included15:50
kergothit works quite well for us15:50
kergothe.g. see all the layer subdirs in
kergothof course, you can always set bb_danglingappends_warnonly, but then you can miss a legitimate case where it *should* fail if the recipe goes missing but the append still exists, for example if upstream bumps a recipe version15:51
kergothso this is a better approach than that15:52
dvhartkergoth, thanks - I learned something here today too ;-)15:53
Piziwategreat ! thank you kergoth !15:53
*** fray <fray!> has quit IRC15:54
kergothOT, but anyone know of a good script to backup your github repositories for a user/org? Actually, it'd be ideal to also extract issues, etc, to truly get all your data out, but a dead simple iterate-over-the-repos-from-the-github-api might be a start15:54
mkeeteroops, wrong window15:54
*** mckoan is now known as mckoan|away16:03
*** Mahesh__ <Mahesh__!~sachin@> has quit IRC16:03
*** cbzx <cbzx!> has joined #yocto16:04
*** zecke <zecke!~ich@> has quit IRC16:05
*** TobSnyder <TobSnyder!> has joined #yocto16:08
*** msm <msm!> has left #yocto16:22
*** jbrianceau is now known as jbrianceau_away16:28
*** eballetbo <eballetbo!> has quit IRC16:34
iontebluelightning: right. i could not use fragments before, when i used the freescale bsp, but hopefully they work eith meta-raspberrypi. thanks16:38
*** _ccube <_ccube!ccube@2a01:4f8:130:1014::54> has quit IRC16:38
blloydkergoth: thanks for sharing that.  That's a much more elegant solution to that headache than I had come up with.  (.bbappend where .bb may not be there)16:38
*** seebs <seebs!> has quit IRC16:38
*** ccube <ccube!> has quit IRC16:38
bluelightningionte: I think it depends on whether the kernel recipe does "require recipes-kernel/linux/"16:39
bluelightningFYI we have an example of a kernel recipe that supports config fragments but doesn't need the split meta branch in meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb16:40
*** ccube <ccube!ccube@2a01:4f8:130:1014::54> has joined #yocto16:40
iontebluelightning: yes, the freescale bsp is based on oe, not yocto16:40
bluelightningionte: the base support is available in OE-Core, it's not yocto-specific16:40
bluelightning(if that means anything...)16:41
*** seebs <seebs!> has joined #yocto16:41
CroftonYocto is a project to make embedded development easier16:42
Croftonrepeat after me16:42
bluelightningright ;)16:42
blloydI played with the raspberry pi image a while ago (people wanted to know if we could run our stuff on raspberry and answer came back no).  Anyways, I found that bsp didn't play well with modifications.  It's why I suggested the sed in an append.  I got that method to work to change the config, while it seemed the bsp itself works to a hardcoded .config16:42
*** mkeeter <mkeeter!~mkeeter@> has quit IRC16:43
bluelightningblloyd: the answer there is to badger the maintainer to fix the issues preventing modifications (or send patches to fix them)16:43
blloydtrue, or just not use it.  (We aren't going to support raspberry pi so no need for that bsp)16:44
blloydare there any examples of creating bootp images using yocto?16:47
*** maxtothemax <maxtothemax!~maxtothem@> has joined #yocto16:51
*** TobSnyder <TobSnyder!> has quit IRC16:59
*** LCyrin <LCyrin!~LCyrin@2607:fb90:40f:9f6c:a486:527e:54cb:ebef> has joined #yocto17:03
blloydso, is there a command in bitbake to invalidate everything after a given item?  So, while working on an update to say the live-boot script, we can get that package and all images that use it cleaned?17:10
kergothall you have to do is rebuild it. bitbake automatically erbuilds stuff that depends on it for you if their deps changed17:12
kergothbitbake -C fetch foo; would result in rebuilding foo from scratch and then if you did a regular build that included the stuff that depends on foo, they'd be rebuilt too17:12
*** mkeeter <mkeeter!~mkeeter@> has joined #yocto17:17
*** diego_r <diego_r!> has quit IRC17:22
*** dmoseley <dmoseley!> has joined #yocto17:23
*** belen <belen!Adium@nat/intel/x-vhhtnwiabxlgvcei> has quit IRC17:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:32
*** radzy_ is now known as radzy17:35
*** sameo <sameo!~samuel@> has quit IRC17:36
*** dmoseley <dmoseley!> has quit IRC17:38
*** radzy <radzy!~radzy@> has quit IRC17:38
*** radzy <radzy!~radzy@> has joined #yocto17:39
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-fuidwbaizqpphvca> has joined #yocto17:40
*** Crofton <Crofton!~balister@> has quit IRC17:45
*** dmoseley <dmoseley!> has joined #yocto17:48
*** dmoseley <dmoseley!> has quit IRC17:50
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-hmsxhmdbbiaqutsk> has joined #yocto17:50
*** Crofton <Crofton!> has joined #yocto17:57
*** fray <fray!> has joined #yocto18:07
*** neabax <neabax!~neabax@> has joined #yocto18:08
*** droy <droy!rishabhsix@gateway/shell/waartaa/x-bndyhgptbreaiwrp> has joined #yocto18:09
volker-python installation with 9 additional python-* packages takes up a lot of space18:10
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC18:14
*** jkridner <jkridner!> has joined #yocto18:15
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto18:15
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC18:19
*** tyler-baker <tyler-baker!~tyler@linaro/tyler-baker> has left #yocto18:24
-YoctoAutoBuilder- build #141 of nightly is complete: Success [build successful] Build details are at
*** radzy is now known as radzy_away18:29
volker-Is there a option to only pack python pyc files and not the pyo files? deleting .py and pyo halfs the size python needs18:30
*** nitink <nitink!nitink@nat/intel/x-ktbnspfrokgcaced> has quit IRC18:31
*** fusman <fusman!~fahad@> has joined #yocto18:32
kergothgood question18:34
volker-ls|wc -l => 4218:35
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC18:37
*** dmoseley <dmoseley!> has joined #yocto18:41
rburtonvolker-: not sure the details of .pyc vs .pyo.  is .pyc generic but .pyo machine specific? is .pyo machine specific but for the wrong machine?18:49
volker-pyo is an 'optimized' pyc18:50
volker-but there are debates about pyo if you should use it or not18:50
rburtoni know that much, what does that mean :)18:50
rburtonoh, its missing assertions and line numbers18:50
rburtonthat's not much of an optimisation18:50
rburtonhell, wipe them all18:50
volker- ;-)18:50
yoctiBug 6434: normal, Undecided, ---, richard.purdie, NEW , python packages every build output: .py, .pyc and .pyo18:50
*** nitink <nitink!nitink@nat/intel/x-dpcucgvyhgjtguxa> has joined #yocto18:52
volker-AFAIR ubuntu ships all python files without the pyc and compiles it on installation (don't take that for granted, I think I saw it somewher ein the past)18:52
volker-beside this, pyo are not even installed on my ubuntu system here18:53
rburtonpyo seems like a waste of time and effort18:54
rburtonyes, debian and derivs generate byte code on install, because they let you install a single .py and then symlink it into multiple python versions18:55
*** beaver_545 <beaver_545!~stuart@> has joined #yocto18:55
rburtonso it has to compile for each one18:55
rburtonvolker-: fwiw, the meta-yocto component is only for the meta-yocto* layers18:55
volker-good, at least I am note alone in the opinion that we can reduce data here :)18:56
volker-rburton: yeah, I am not sure about that. But then the question is if meta is oe-core or if it is 'other layer'18:56
rburtonmeta *is* oe-core18:56
rburtonand python is oe-core18:56
rburtoni've moved it to oe-core/devtools as the python recipes are in meta/recipes-devtools18:56
rburtonand now i need to sneak out of my daughters room with a dead foot18:57
kergothhmmm, apparently changes to IMAGE_FEATURES or FEATURE_PACKAGE_* don't cause re-execution of do_rootfs18:57
* kergoth preps fix18:57
volker-rburton: thanks for the info. the naming here is a little bit confusing for me because it does not match directly the directory naming18:58
kergothoe-core/meta == poky/meta, same for scripts18:58
kergothso the directory naming does match, just underneith toplevel18:58
*** freanux <freanux!~freanux@unaffiliated/freanux> has quit IRC18:58
kergothoh, it doesn't match the bugzilla category, gotcha18:58
volker-I am not familiar with oe-core. Therefore I am not sure about it18:59
*** freanux <freanux!~freanux@unaffiliated/freanux> has joined #yocto19:00
volker-wit also seems like not the entire meta-openbedded repository is provided in yocto19:00
kergothnothing from meta-openembedded is in poky/yocto19:01
kergothoe ~= oe-core + meta-oe + whatever else, poky ~= oe-core + meta-yocto + meta-yocto-bsp19:01
*** challinan <challinan!> has quit IRC19:02
kergothnaturally you can use meta-oe with poky fine19:02
Croftonpoky is the Yocto project reference distribution. OpenEmbedded is the build system :)19:03
rburtonto elaborate on kergoth's point, poky literally is oe-core+meta-yocto+meta-yocto-bsp+yocto-docs, squashed together into a single git repo using combo-tool.19:04
rburtonCrofton: i thought bitbake was the build system ;)19:04
* Crofton slaps rburton with a large trout19:05
volker-sounds like yocto reinvented the wheel ;-)19:05
rburtonCrofton: i'm still mourning so liable to grab a frying pan/cricket bat19:06
rburtonvolker-: yocto was formed around projects that have existed for ~10 years19:06
Croftonvolker-, long story :)19:06
volker-I was kidding now you guys start to argue about it ;-)19:07
rburtonvolker-: it's a touchy subject ;)19:07
volker-I use it and am fine with it.19:07
*** Jefro <Jefro!> has quit IRC19:10
kergothYeah, yocto is just an umbrella project, and poky is a reference distro and integration of various components. people naturally get confused with all the terms and where all the pieces come from and how they fit together19:13
volker-Ok... the yocto book release got pushed back to July...19:15
*** tasslehoff <tasslehoff!> has joined #yocto19:18
kergoth /me adds to his upstream submission todo list19:22
blloydok, there has to be a less painful way to do this.  I'm editing a package (taking several attempts to get it working properly).  Used to I could just -c cleansstate on the package, and get that package and the images to rebuild.  Now, with the images tracking sstate they don't rebiuld.  So how do I get around this fun during the initial testing?  Of course, during commit the PR is incremented, so no problems once shared.  But what abou19:22
blloydt during that initial development phase where we got images produced already so it doesn't recreate them?19:22
*** radzy_away is now known as radzy19:23
kergothI don't understand the question19:25
kergothoh, you're making changes outside of bitbake's knowledge?19:25
kergothchanges to the metadata will automatically change checksums and result in re-building recipes which depend on it, including the image19:25
kergothyou can "taint" a task to make bitbake believe it needs to rebuild it and everything after it with bitbake's -C argument19:26
kergoththat sounds like it may be what you want19:26
volker-blloyd: I am confused. I tell you how I do it:   "make -c clean <package>; make -c build <package>" for development. and then a build script that updates the changes and execute the bitbake <image-to-build>19:26
*** radzy is now known as radzy_away19:27
kergothhe wants to rebuild a recipe from scratch, and still rebuild the image to include those changes, explicitly, afaict19:27
kergothit'd be better to let bitbake know about your changes, to avoid the need to manually force a rebuild entirely, but -C may get you what you want for now19:27
volker-kergoth: should also work with the clean flag19:27
kergothit'll just pull from sstate and not rebuild19:27
volker-I need to look in the newer samba soon19:29
volker-the availableone installes 81M19:29
blloydkergoth: so you are suggesting that each attempt should increment the PR variable?  So when I submit a patch, PR could go from 11 to 21?19:30
*** mawillia1 <mawillia1!> has joined #yocto19:30
kergothagain, if you adda  patch to SRC_URI it'll rebuild and bump pr automatically, if your'e using the pr server. there's no need to force a rebuild at all in that case19:30
kergothif you're modifying an scm repository, then you should add SRCPV to PV and use AUTOREV so bitbake picks up the change19:31
kergothin either case, bitbake knows the source changed and knows to rebuild and bump pr automatically19:31
kergothif you're maintaining a feed, and honestly even if you aren't, you should really use the pr server :)19:31
*** mawillia <mawillia!> has quit IRC19:31
rburtonblloyd: it really depends on what steps you're taking outside of bitbake's knowledge, and how you can tell bitbake you're making changes.19:32
*** Jefro <Jefro!> has joined #yocto19:32
*** JimBaxter <JimBaxter!> has quit IRC19:32
blloydkergoth: a number of items I am working on are like initramfs-live-boot.  They have a source file in files subdirectory.  I'm modifying that file.  Thus two files get changed for patch (one to increment PR in recipe, and the source file itself).19:32
kergothyou never have to touch pr in a recipe anymore19:33
kergothjust run the pr server and get on with your day :)19:33
kergothif the source file is referenced in SRC_URI, bitbake will detect those changes to that file19:33
blloydsadly, if that is the case, there appears to be a bug.19:33
rburtonblloyd: don't suppose you can share the layer19:34
kergothinsufficient information to say whether thats the case or not, from our perspective :)19:34
rburton(or replicate in a dummy recipe that you can share)19:34
blloydso, let's use my current update as an example: meta/recipes-core/initrdscripts/files/init-live.sh19:35
*** tasslehoff <tasslehoff!> has quit IRC19:36
blloydI've modified that file.  Then I rebuild image-restore8 (generates a .hddimg) that uses the live-boot.  After file change, the build of image-restore8 gets 5825 of which 5825 didn't need to be rerun.19:37
blloydBuilding core-image-sato-dev has the same behavior (which means it can be done with a base yocto installation).19:38
rburtonso the dependency from the hddimg to the live image isn't right19:39
blloydit builds properly from an empty tmp folder.19:40
kergothif you bitbake initrdscripts, does it get rebuilt?19:42
rburtonconveniently this can be replicated fairly simply19:42
blloydI've actually seen a user put 2 boot disks into a system.  Systems like Fedora's live boot make it where it is possible to identify which disk was used to load the root filesystem.  The doesn't allow this, so was adding and testing (and finding issues, fixing and retesting).19:42
blloydNo kergoth.  Not without the -c cleansstate or a -f.19:42
kergoththat'd be a serious problem. that's not how it's supposed to work19:43
kergothis in SRC_URI?19:43
kergothbitbake checksums every file:// file in SRC_URI19:43
blloydSRC_URI = "file://"19:43
kergothand includes that in the do_fetch checksum19:43
rburtonblloyd: master or daisy?19:44
kergothwhat version of yocto/poky / what branch?19:44
*** fusman <fusman!~fahad@> has quit IRC19:44
rburtonblloyd: this is right?19:44
blloydmaster, latest19:44
blloydyes sir19:44
blloydI've got build directories that use only meta-oe, yocto, and meta-intel, as well as one that uses those and my companies custom layers.19:45
rburtonc'mon disks faster faster19:46
kergothoh, so you'd want to bitbake initramfs-live-boot and see if that rebuilds when the file changes, in that case19:46
rburtonfwiw it appears to be working here19:46
blloydwill retest19:46
rburtonits busy setscening the universe right now, presumably because its about to do stuff19:47
rburtonok why does a kernel setscene take SO LONG19:47
blloydI just did a git pull a little bit ago, moving forward a few days.19:47
*** zecke <zecke!> has joined #yocto19:47
rburtonyep, works here19:47
rburtonblloyd: try replicating with a clean poky19:47
blloydI have one of those, due to my fun with meta-oe recently.  :)19:48
rburtonso no meta-oe or meta-intel, or your own layers19:48
blloydalso, is there a better way to do something like   sed -i 's#^\(1:[S123456789]*:\)respawn:/sbin/getty\(.*\)$#\1once:/sbin/getty -n -l /usr/bin/automaticrestore\2#g' "$D/etc/inittab"?19:49
rburtonTask initramfs-live-boot:do_fetch couldn't be used from the cache because:19:51
rburton  We need hash dd6928066425f1742c6114ce7da5939e, closest matching task was d8869f65dcedcf345170e804f62896c919:51
rburton  Checksum for file changed from cbe75c87da1dcd01c70660b33b144bfb to c07ecdc8d43b750e696c3591f53ad73219:51
rburtonthat's from bitbake -S printdiff initramfs-live-boot after doing a build and the changing init-live.sh19:51
rburtonso yes, it works here19:51
rburtonmaybe you've a layer that's breaking something19:52
rburtonpossibly its pulling another from a different layer :)19:52
volker-does anyone run TPM with yocto?19:55
*** dvhart_ <dvhart_!dvhart@nat/intel/x-bqefittjxigphlsk> has joined #yocto19:55
*** dvhart_ <dvhart_!dvhart@nat/intel/x-bqefittjxigphlsk> has quit IRC19:55
blloydwell, it just fired do_package, with only the file changed.  That's nice.19:56
*** dvhart <dvhart!dvhart@nat/intel/x-pdeasqmscgvrjfcg> has quit IRC19:56
blloydand now it's running do_rootfs for the minimal ram disk.  Wonder why it was skipping them earlier.  (I like the current behavior!)19:57
*** dvhart <dvhart!~dvhart@> has joined #yocto19:58
rburtonvolker-: TPM as in in trusted stuff?  there's a layer on git.yocto iirc19:58
volker-yes, TPM the cryptochip. didn't find anything when grepping through the code19:59
rburtonblloyd: it should have started at do_fetch but that might have passed very quickly that you didn't get to see it19:59
volker-only found something in layers.openembeeded.org19:59
volker-meta-measured, not official layer19:59
blloydI think it did rburton, but as you said, it runs fast (the file to "download" is on a local disk after all).20:00
*** ccube <ccube!ccube@2a01:4f8:130:1014::54> has quit IRC20:00
rburtonvolker-: yeah, there's meta-measured, or experimental/meta-trusted on git.yoctoproject.org20:01
*** ccube <ccube!> has joined #yocto20:01
rburtonvolker-: official layers are only official if they are proposed to be official20:01
volker-ok, didn't know about the experimental. We try to stay around 1.620:02
volker-better I... man, I need a new job20:02
rburtonnot official != not good20:02
rburtonnow i can't vouch for either but meta-measured is active at least20:02
volker-rburton: not official = needs more reviews20:03
rburtonvolker-: well its simply not official == author hasn't proposed it, or doesn't want to move it to git.yoctoproject.org20:03
rburtonwhat do you define as official20:03
volker-rburton: not in yocto = needs to be added to the current base in some other ways like meta-openembedded :)20:03
rburtonon  that's not a requirement.20:04
volker-rburton: official in kind of "well known project" like hosting it on openembeeded or yocto20:04
volker-I wouldn't call layers I throw somewhere on github as official :)20:04
rburtonthere are more layers on github than anywhere else :)20:04
volker-yocto is not on github ;-)20:04
rburtonactually, most of it is mirrored there :)20:05
volker-support is often a problem with such packages. I saw it in other fields.20:05
*** smartin_ <smartin_!> has joined #yocto20:05
volker-s/support/continuous development/g20:05
rburtonvolker-: joining forces with an existing layer must be easier than starting from scratch, right?20:06
rburtonanyway time to cook20:06
* rburton goes20:06
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:06
*** zecke <zecke!> has quit IRC20:07
*** mawillia1 <mawillia1!> has quit IRC20:15
*** Piziwate <Piziwate!5503efcb@gateway/web/freenode/ip.> has quit IRC20:15
*** mawillia <mawillia!> has joined #yocto20:16
*** dvhart <dvhart!~dvhart@> has quit IRC20:18
*** madisox <madisox!~madisox@nat/cisco/x-zebucrrlcpmtkmbe> has quit IRC20:19
*** radzy_away is now known as radzy20:20
*** flihp <flihp!> has quit IRC20:21
*** kscherer <kscherer!~kscherer@> has quit IRC20:21
*** ccube <ccube!> has quit IRC20:24
*** codinho <codinho!~me@unaffiliated/codinho> has quit IRC20:24
*** dvhart <dvhart!dvhart@nat/intel/x-ulhdopbxubwzmwqj> has joined #yocto20:26
ionteblloyd, bluelightning: regarding the kernel config trouble on rpi we discussed earlier. i tried to add configuration fragments, but they do not change the final config :(20:30
bluelightningionte: I'm guessing because the kernel recipe does not use as I mentioned earlier20:30
bluelightningwithout that, there is no config fragment support20:30
ionteguess so..20:32
*** sroy_ <sroy_!~sroy@2607:fad8:4:6:3e97:eff:feb5:1e2b> has quit IRC20:35
*** Letothe2nd <Letothe2nd!~jd@unaffiliated/letothe2nd> has quit IRC20:39
*** halstead <halstead!> has quit IRC20:39
*** mckoan|away <mckoan|away!~marco@unaffiliated/mckoan> has quit IRC20:39
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC20:39
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC20:39
*** Anarky <Anarky!> has quit IRC20:39
*** evanp <evanp!~evan@> has quit IRC20:39
*** SorenHolm <SorenHolm!> has quit IRC20:39
*** kimrhh <kimrhh!~kimrhh@exherbo/developer/kimrhh> has quit IRC20:39
*** DarkKnight <DarkKnight!> has quit IRC20:39
*** mankku <mankku!> has quit IRC20:39
*** bunk <bunk!> has quit IRC20:39
*** SorenHolm <SorenHolm!> has joined #yocto20:40
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto20:40
*** mckoan|away <mckoan|away!> has joined #yocto20:40
*** kimrhh <kimrhh!~kimrhh@exherbo/developer/kimrhh> has joined #yocto20:40
*** halstead <halstead!> has joined #yocto20:40
*** mankku <mankku!> has joined #yocto20:40
*** Letothe2nd <Letothe2nd!~jd@unaffiliated/letothe2nd> has joined #yocto20:40
*** evanp <evanp!~evan@> has joined #yocto20:40
*** bunk <bunk!> has joined #yocto20:40
*** Anarky <Anarky!> has joined #yocto20:40
*** ccube <ccube!> has joined #yocto20:40
*** DarkKnight <DarkKnight!> has joined #yocto20:41
*** nerdboy <nerdboy!> has joined #yocto20:43
nerdboybluelightning: the config is modable, but it's different...20:44
*** jluisn <jluisn!~quassel@> has quit IRC20:45
nerdboyprobably do it different now, but i made the recipe look for a custom defconfig in workdir20:46
*** kroon <kroon!> has joined #yocto20:46
volker-.oO( tpm-tools used by most distribution wasn't updated since 2012!?!?!? )20:48
*** rburton <rburton!> has quit IRC20:48
* nerdboy triggers the superblock mount time in the future error20:50
*** rburton <rburton!> has joined #yocto20:53
*** halstead <halstead!> has quit IRC20:55
*** halstead <halstead!> has joined #yocto20:55
*** dvhart <dvhart!dvhart@nat/intel/x-ulhdopbxubwzmwqj> has quit IRC20:57
*** cbzx <cbzx!> has quit IRC21:01
*** rcw <rcw!~rwoolley@> has quit IRC21:11
*** seezer <seezer!quassel@quassel/developer/seezer> has quit IRC21:11
*** JaMae is now known as JaMa21:12
mkeeterI’ve got a headscratcher related to root filesystem construction:21:14
*** seezer <seezer!quassel357@quassel/developer/seezer> has joined #yocto21:14
mkeeterIf I build a core-image-base with the beaglebone machine, it puts uImage in /boot of the filesystem21:14
mkeeteron the other hand, if I make a new machine that’s exactly the same but with a different name (so different file in conf/machine, same preferred KBRANCH for the new machine name, etc), it doesn’t install uImage21:15
mkeeteris there something weird I have to do with the COMPATIBLE_MACHINE variable?  that’s the only config variable that I don’t understand in the kernel .bbappend file21:17
*** flihp <flihp!> has joined #yocto21:17
blloydmkeeter: perhaps look for beaglebone setting MACHINE_ESSENTIAL_EXTRA_RDEPENDS.21:17
*** jackmitchell <jackmitchell!> has quit IRC21:18
*** jackmitchell <jackmitchell!> has joined #yocto21:18
*** Jefro <Jefro!> has quit IRC21:19
blloydOr look at KERNEL_IMAGETYPE.  Beaglebone sets it in their machine conf, does your new one do so?21:21
mkeeteryes, I just copied the beaglebone conf file and gave it a new name21:21
mkeeterbut I’ve found something suspicoius:21:21
mkeeterit’s warning me that linux-dummy is trying to install files into a shared area when those files already exist21:22
mkeeterin tmp/sysroots/beagleboo/sysroot-providers/virtual_kernel21:22
mkeeterand telling me “Please verify which package should provide the above files"21:22
mkeeterso that sounds relevant to these issues21:22
blloydbesides  changing the file name, the internal of the file needs to be updated to be consistent with the new name.21:22
mkeeterthe beaglebone.conf file?21:23
mkeeterI don’t see anything name-specific other than the #@NAME header, which I changed21:23
blloydjust looked, looks like it derives the name from filename now.  Sorry21:25
mkeeteryeah, I think it’s to do with the warnings about installing files into a shared area where the files already exist21:26
*** neabax <neabax!~neabax@> has quit IRC21:26
mkeeteris there a convenient way to tell which recipes are trying to provide which files?21:28
*** radzy is now known as radzy_away21:29
*** kbouhara <kbouhara!> has quit IRC21:30
mkeeterhmmm, something like a conflict between linux-dummy and linux-yocto?21:31
mkeeterthose are the only two manifests that contain kernel-modules.packaged21:32
mkeeterand similarly, linux-dummy.populate_sysroot and linux-yocto.populate_sysroot both contain “virtual_kernel”, which I was also warned about21:32
mkeeterah, and this brings me back to COMPATIBLE_MACHINE something21:33
*** agust <agust!> has quit IRC21:48
*** sameo <sameo!samuel@nat/intel/x-preiitcscliwekeq> has joined #yocto21:56
*** bfederau <bfederau!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** sjolley <sjolley!sjolley@nat/intel/x-wuapkyiikzjmiirz> has quit IRC22:01
*** tyler-baker <tyler-baker!~tyler@linaro/tyler-baker> has joined #yocto22:01
*** mkeeter <mkeeter!~mkeeter@> has quit IRC22:03
*** ant__ <ant__!> has joined #yocto22:08
*** beaver_545 <beaver_545!~stuart@> has quit IRC22:11
blloydyou are putting two kernels on your system?22:14
blloydand I would expect those to conflict.  They generate the same thing to go on the filesystem.22:14
*** sjolley <sjolley!sjolley@nat/intel/x-ataadphsxbiaudhq> has joined #yocto22:28
*** smartin_ <smartin_!> has quit IRC22:31
*** Jefro <Jefro!> has joined #yocto22:34
*** seebs <seebs!> has quit IRC22:41
fraywhois sgw_22:41
* fray notes a '/' would help.. whoops ;)22:41
*** ant__ <ant__!> has quit IRC22:43
*** seebs <seebs!> has joined #yocto22:43
sgw_fray, I am sgw!22:44
*** jkridner <jkridner!~jkridner@> has joined #yocto22:48
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto22:48
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC22:48
*** rburton <rburton!> has quit IRC22:49
*** rburton <rburton!> has joined #yocto22:53
*** jzhang <jzhang!~jzhang@> has quit IRC22:54
*** jkridner <jkridner!~jkridner@> has joined #yocto22:59
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto22:59
*** rburton <rburton!> has quit IRC23:04
*** rburton <rburton!> has joined #yocto23:05
*** munch <munch!> has quit IRC23:15
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:28
*** radzy_away is now known as radzy23:37
*** rburton <rburton!> has quit IRC23:39
*** rburton <rburton!> has joined #yocto23:40
*** rburton <rburton!> has quit IRC23:48
*** rburton <rburton!> has joined #yocto23:49

Generated by 2.11.0 by Marius Gedminas - find it at!