Thursday, 2019-08-29

*** khem <khem!~khem@unaffiliated/khem> has joined #yocto00:06
*** Dvorkin <Dvorkin!~Dvorkin@> has quit IRC00:11
zeddiiRP: bugger! will send an updated patch.00:11
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:16
*** stew-dw <stew-dw!~stew-dw@> has quit IRC00:42
*** stew-dw <stew-dw!~stew-dw@> has joined #yocto00:42
*** micka <micka!> has quit IRC01:05
*** micka <micka!> has joined #yocto01:05
*** armpit <armpit!~armpit@2601:202:4180:c33:e5a5:4b94:b3b5:f092> has joined #yocto01:22
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:55
*** kaspter <kaspter!~Instantbi@> has quit IRC02:00
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:00
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC03:17
*** gattuso <gattuso!> has quit IRC03:58
*** gattuso <gattuso!> has joined #yocto04:00
*** learningc <learningc!> has joined #yocto04:25
*** User_ <User_!> has joined #yocto04:29
*** learningc <learningc!> has quit IRC04:33
nrossiRP: i am here now, I am on UTC+10 so i just missed your message04:42
khemzeddii:I sent a patch for 5.2 to fix kernel-selftests please include them as well while here, both the patches are backports from mainline
*** frsc <frsc!~frsc@> has joined #yocto05:18
*** AndersD <AndersD!> has joined #yocto05:33
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto05:35
*** User_ <User_!> has quit IRC05:37
*** learningc <learningc!> has joined #yocto05:41
*** Dracos-Carazza_ is now known as Dracos-Carazza05:52
*** goliath <goliath!> has joined #yocto06:03
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:04
*** kroon <kroon!~kroon@> has joined #yocto06:27
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto06:33
*** TobSnyder <TobSnyder!> has joined #yocto06:49
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto06:50
*** tprrt <tprrt!~tprrt@> has joined #yocto06:54
*** jmiehe <jmiehe!> has joined #yocto07:09
*** lfa <lfa!~lfa@> has quit IRC07:13
*** yann <yann!> has quit IRC07:14
*** chakie <chakie!~jekholm@> has joined #yocto07:30
*** goliath <goliath!> has quit IRC07:30
chakiehi folks!07:30
jwwwwhi chakie .07:31
chakiei'm updating a product that we have which is based on yocto to "warrior". Previously we've been using "sumo" and before that some older version. Been working fine07:32
chakieNow immediately when I start the bitbake for the image I get: "ERROR: Nothing PROVIDES 'cpio-native'."07:33
chakieWhile googling for the error I saw that there was some talk about it here last year, but I saw no solution.07:33
chakieI didn't figure out any way to actually provide the native version of cpio, so I resorted to a "ASSUME_PROVIDED += ' cpio-native '".07:35
erbochakie: it's provided by poky/meta/recipes-extended/cpio/cpio_2.12.bb07:37
chakieThat made the error go away (yay!) and successfully built the image (yay!) as well as the SDK (yay!). However, the builds were not complete as there are no u-boot.img, boot.bin and similar files actually generated07:37
chakieI saw no errors anywhere, but the build simply didn't produce what it was supposed to do when I compare to what the sumo version did.07:38
chakieI did try to add dependencies to various versions of "cpio" all over the place, but nothing seemed to have any effect on the error.07:38
erbochakie: could you try "bitbake-layers show-recipes cpio-native"?07:40
chakieNOTE: Starting bitbake server...07:41
chakieWARNING: Host distribution "neon-18.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.07:41
chakieLoading cache: 100% |######################################################################################################################################################################################################################################| Time: 0:00:0007:41
chakieLoaded 3327 entries from dependency cache.07:41
chakieParsing recipes: 100% |####################################################################################################################################################################################################################################| Time: 0:00:0207:41
chakieParsing of 2244 .bb files complete (2243 cached, 1 parsed). 3328 targets, 340 skipped, 0 masked, 0 errors.07:41
chakieHm, that was a bit ugly. But it really shows nothing at all except for the normal "parsing recipes".07:41
erbochakie: no "=== Matching recipes: ===" section at the end?07:42
chakieNo, that's all07:42
chakieJust a:07:42
chakieSummary: There was 1 WARNING message shown.07:42
chakie(about the distro)07:42
erbodo "bitbake-layers show-layers" list the "meta" layer?07:43
chakieTrying the show-recipes for "cpio" gives:07:43
chakie=== Matching recipes: ===07:44
chakie  meta                 2.1207:44
jofrThanks for those progress bars. I will save those for later. *tongue-in-cheek*  :p07:44
chakieTo my defense I haven't been on IRC for 10 years.07:44
erboand poky/meta/recipes-extended/cpio/ has BBCLASSEXTEND = "native" at the bottom?07:44
chakieLet me see07:45
chakiefind chugs along07:46
LetoThe2ndchakie: pro tip: use ag (a.k.a. the silver searcher) instead of grep and fd instead of find.07:47
chakieyes, it ends with:07:47
chakieBBCLASSEXTEND = "native"07:47
erboThen I don't really know what's going on. :(07:48
chakieWhat would be a good variable to add the dependency to?07:50
erboI would try to find what's causing this weird stuff instead of finding some way to make it work anyway07:51
LetoThe2ndchakie: my suggestion would rather be to find out what pulls it in and trace from there backwards.07:52
erbocpio-native should be there, you shouldn't need to use ASSUME_PROVIDED07:52
chakieyeah, it's a pretty fundamental thing07:52
chakiewe do (for some reason I don't know) have a cpio_%.bbappend that contains BBCLASSEXTEND = "nativesdk"07:53
chakiethat of course clobbers the "native" in the actual recipe07:53
erboEr, right :)07:55
erboMaybe use BBCLASSEXTEND_append = " nativesdk" instead07:55
chakieI never noticed that before07:55
chakieI've cursed at this for a while now. Thank you for guiding me to finding the problem07:56
chakieLeoThe2nd: it got pulled in by the script that builds final images.07:57
LetoThe2ndchakie: :-) glad you found it07:58
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC07:58
chakieLeoThe2nd: damn ag is fast...08:01
LetoThe2ndchakie: i know.08:01
LetoThe2ndhence the tip :)08:01
qschulzLetoThe2nd: I didn't know about fd, I'll try this one :)08:02
chakiethanks for that too. recursive grep is so slooow08:03
LetoThe2ndqschulz: have fun!08:03
qschulzwhen you can't install ag (non-root etc..) git grep is already A BIG step forward :)08:03
LetoThe2ndqschulz: "non-root"? what does this mean? :P08:05
qschulzLetoThe2nd: while we're at it. I can't connect over ssh without using mosh now. SO convenient.08:11
LetoThe2ndqschulz: yeah i know about mosh, but i usually just stick to standard ssh-into-shell-with-tmux08:11
qschulzit just recovers nicely from unstable connections. I've one session open at all times on my laptop, survives suspend/resume and network switches. Very happy about it :) (i'm still using screen though after it)08:13
*** goliath <goliath!~goliath@> has joined #yocto08:13
LetoThe2ndmaybe need to try it again some time!08:13
qschulzonly annoying thing about it is that you need to open a big range of ports or know how many sessions max you'll have open at one time08:15
*** behanw <behanw!uid110099@gateway/web/> has quit IRC08:18
*** mckoan|away is now known as mckoan08:18
chakieag did a search through my build directory in 30s while i'm building an image. pretty impressive, considering this is some laptop garbage ssd08:18
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:19
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC08:19
LetoThe2ndchakie: the trick is that i 1) pully exploits threads 2) skips anything not instantly appearing as text searchable, e.g. any binaroes.08:20
*** yacar_ <yacar_!~yacar@> has joined #yocto08:22
*** marka <marka!~marka@> has quit IRC08:35
*** yacar_ <yacar_!~yacar@> has quit IRC08:39
*** yacar_ <yacar_!~yacar@> has joined #yocto09:07
RPnrossi: I thought timezones may be tricky09:15
RPnrossi: it was just to follow up on the email discussion and see how best to move forward09:15
*** soderstrom <soderstrom!~soderstro@gateway/shell/> has quit IRC09:38
*** yann <yann!~yann@> has joined #yocto09:39
nrossiRP: was just having dinner, you still around?09:55
RPnrossi: yes09:56
RPnrossi: I'm still trying to wake up, caffeine isn't working today :/09:56
nrossiRP: so I tried to see if i could get the gcc/g++ part of the test suite into the gcc-runtime execution. and that seems to work well. For binutils i imagine the only solution there is to create a testsuite recipe09:57
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC09:58
nrossiwith the binutils-cross recipe stashing the build directory like gcc-cross/gcc-runtime does09:58
RPnrossi: ok, I think we'll probably need to do that. "target" dependencies cause huge problems for the cross recipes10:00
RPnrossi: I'm relieved the gcc runtime part works!10:00
nrossiRP: i did find a bug though when I ran the gcc testsuite in gcc-runtime, specifically with gcc plugins.... i guess there are no users of gcc plugins in oe?10:01
RPnrossi: probably not, no. I think there was a recent patch related to that?10:01
nrossiRP: how old? cause the issue is that staging rewrite the configargs.h file in the recipe sysroot, which causes issues with the compiler configure args check at plugin load time10:03
RPnrossi: I'm probably thinking of as there were comments made about plugins at the time too10:05
RPnrossi: I've not heard of a configargs issue before10:05
nrossiRP: interesting... essentially its the value you get when you run gcc -v10:06
nrossiRP: I haven't checked the gcc code itself, but it appears to sanity check that vs what the plugin was built against10:06
RPnrossi: I suspect there are build reproducibility issues in here too10:08
nrossiRP: likely, i think it would probably be something solved by rewriting the configargs.h that is used to compile gcc as well as what it installed into the sysroot with dummy paths. Similar to was you see when running gcc -v on a "normal" host distro10:09
RPnrossi: yes, sounds like a plan, either target paths, or paths with placeholders for the OE build path10:10
nrossiRP: ok, I will look into getting a patch for that.10:11
RPnrossi: did you understand the issue with the oeqa result logging?10:11
RPnrossi: still not 100% sure I have a good solution to that :/10:11
nrossiRP: sort of, that was the next questions i have10:11
nrossiRP: firstly, the selftest/cases location... does it make sense to move it into a new module or does it make more sense to start decorating testcase classes with "categories"10:12
*** yacar_ <yacar_!~yacar@> has quit IRC10:12
RPnrossi: I've been giving it a bit more thought and realised we do already have some selftests we run on a per machine basis10:12
*** iceaway2 <iceaway2!~pelle@> has joined #yocto10:12
RPnrossi: here:
nrossiRP: i did initial mimic the testcase... i assume that is one of the selftest cases that are machine dependent?10:13
RPnrossi: we've kind of sleepwalked into this :/10:13
RPnrossi: the two we run as machine specific are runqemu and meta_ide. You're right and go should be on that list though10:14
nrossiRP: so what stops them from being run in default oe-selftest builder?10:16
RPnrossi: I'm now wondering if we split these into two classes, or mark the tests up somehow or quite what to do10:16
RPnrossi: nothing. As I said, we just kind of accidentally ended up here without thinking10:17
RPnrossi: I'm just realising we need to do something about this rather than a hardcoded list in the autobuilder config10:17
nrossiRP: ok, just making sure im not overlooking big pieces of config :).10:18
RPnrossi: A lot time ago we did talk about "tagging" tests, e.g. "fast" or "slow" or in this case "target"10:18
RPnrossi: Perhaps we should create some decorators for the tests and do that this way?10:18
nrossiRP: that is exactly along the line of what i was thinking10:18
RPnrossi: that would make your tests work as is and just need some extra code to get access to the markup from the commandline10:19
nrossiRP: unfortunately the base unittest in python does not have a test category function. But not hard to implement10:19
*** frsc <frsc!~frsc@> has quit IRC10:20
RPnrossi: wouldn't be the first time we've had to extend it :/10:21
nrossiRP: probably making the decorator work on a per class or per method yer? so you can mark the individual test methods as fast/slow/etc.10:22
RPnrossi: yes10:23
iceaway2I am just starting out with Yocto for a new project of ours, and I am slightly confused. If I bring in a layer to my bblayers.conf file, will all recipes in that layer be downloaded and built when I bitbake an image, or only the parts that the image specifies will end up on my rootfs?10:25
nrossiRP: ok, so the for the results part. I tried to keep it simple to make sure it was in the right direction. But you mentioned injecting the test result differently? Since all the tests are not explicitly runtime tests I was not sure if there was a good way to log them10:27
nrossiiceaway2: only the parts you image specifies generally10:28
*** iceaway2 is now known as iceway10:28
*** iceway is now known as iceaway210:28
*** iceaway2 is now known as iceaway10:29
RPnrossi: I thought I'd said the results injection was fine?10:29
RPnrossi: my main thoughts now would be on the namespaces so we can make best use of the current result handling10:30
nrossiRP: by namespaces are you referring to putting the subtest results into a nested results hierarchy of some sort?10:32
*** frsc <frsc!> has joined #yocto10:33
RPnrossi: we generate these reports from the results:
RPnrossi: so if for example we injected as a pretend ptest, it would show up in the ptest table10:34
RPnrossi: I'm not sure that is a good or a bad idea, just thinking what makes sense right now10:35
RPnrossi: we could inject that as ptestresult.gcc-cross for example10:36
RPnrossi: when we implement better refgression analysis in resulttool, it would then work for these "for free"10:37
nrossiRP: ok, makes sense, putting them under ptest is fine? not going to cause too much confusion?10:37
nrossiRP: also should it seperate the suites, e.g. "gcc", "g++", "libatomic"... "gas", "ld"....10:38
*** vdehors <vdehors!> has joined #yocto10:38
nrossiRP: and if so, should they be just the suite or e.g. "gcc.gcc", "gcc.libatomic"10:38
RPnrossi: I think we want to separate the suites where we can as the results are more meaningful10:39
RPnrossi: it may need to become gcc-libatomic as I'm not sure we support nesting that namespace to sublevels10:40
RPor just libatomic I guess10:40
nrossiRP: I will do the "-" so that its clear what package its from. I think that covers my questions I will get crackin on these things :)10:41
nrossiRP: oh, before i forget, did you have any issues with the glibc-testsuite implementation? or did that make sense from a review standpoint?10:42
RPnrossi: good question, not sure I looked closely at that :/10:44
nrossiRP: have a look when you get a chance, i will still be around for another 4 hours or so :) but just going afk for 10 minutes now10:46
RPnrossi: Looks basically good to me. I just don';t like the BUILD_TEST_ namespace10:47
nrossiRP: i think TEST_* is what the testimage class uses, does that make more sense?10:48
RPnrossi: these are used by glibc, gcc, anything else?10:48
nrossiRP: they are just used in the recipe for glibc-testsuite and gcc*. They can be any prefix really10:49
RPnrossi: I'm tempted to suggest TOOLCHAIN_TEST_10:50
RPnrossi: also, I think if the tests move out the cross recipe, we hopefully don't need the gcc-common change. I think adding in a target dep there on RECIPE_SYSROOT may cause problems10:51
nrossiRP: ok, will change them to that :).10:51
RPnrossi: running the selftest sstate sigs tests would show that up10:51
nrossiRP: the gcc-common change is needed so that the extracted builddir has the right paths...10:52
RPnrossi: ok, I wondered if that was the case10:52
RPnrossi: we'll need to run the sigs tests, see if they do show issues10:53
nrossiRP: I could change is to that only gcc-runtime uses a modified extract function? How do i run sigs tests?10:54
nrossi"is to" -> "it so"10:55
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto10:58
RPnrossi: oe-selftest -r sstatetests10:59
RPnrossi: lets see if there is a problem or not10:59
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC11:02
*** weltling <weltling!> has joined #yocto11:07
RPzeddii: I have the multilib ca-certs issue figured out FWIW, that one isn't kernel11:09
chakieHm, I rebuilt everything from scratch but still got no u-boot.img or boot.bin images11:11
chakieHave the image names changed since sumo?11:11
chakieIn sumo I got a few files like: .build-sumo/build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/u-boot-xlnx/v2018.01-xilinx-v2018.1+gitAUTOINC+949e5cb9a7-r0/package/boot/u-boot.img11:15
chakieSame for boot.bin and others. Now no files with those names.11:15
*** yacar_ <yacar_!~yacar@> has joined #yocto11:23
iceawayI struggle a bit to figure out how the DISTRO variable will affect my build output etc. We are building a custom board around a SOM from Variscite which has a NXP i.MX 8X CPU. Variscite/Freescale provides in their example a distro called "fsl-imx-wayland" and an image called "fsl-image-gui". We do not need any GUI stuff, and I would like to start out as small as possible and later add the extra packages11:33
iceawaythat we need. Now I am a bit confused whether I should keep the distro, and start from a "core-image-minimal", or if I should change the distro to "poky" and use "core-image-minimal". It's difficult for me as a newcomer to understand what implications changing the DISTRO has. Currently I have at least successfully build and booted an image based on "poky" and "core-image-minimal".11:33
*** berton <berton!~berton@> has joined #yocto11:39
tgoodwinDoes anyone know if submissions to the YP Summit 2019 call for papers should be as attachments to the e-mail or in-line?11:41
Crofton|workWe will take either11:43
Crofton|workpreferably in a free format ;)11:43
Crofton|workbut we can deal11:44
tgoodwinunderstood :)11:44
*** berton <berton!~berton@> has quit IRC11:44
*** berton <berton!~berton@> has joined #yocto11:46
chakieMeh, figuring out where the boot and fs images would come from and why they don't come from there isn't trivial at all11:49
tgoodwinchakie: what Xilinx machine are you targeting?  In general, I've found some of their targets don't include things like boot.bin as part of the boot files list.11:52
chakieThis is a setup that's been ok for a few years and a few versions of Yocto, but now with warrior I see some issues. Probably something that has been overridden somewhere either in our conf or the xiling bsp11:55
tgoodwinchakie: I see.  The last build I have for that target was back on thud, so I'm afraid I won't be much of a help.  It might be worth standing up both build environments and comparing "bitbake -e" outputs.11:56
mckoaniceaway: if you are not using GUI I'd switch to Poky distro11:57
tgoodwinchakie: are the boot.bin, etc. in your deploy directory, but not on the SD card (assuming you're using MMC)?11:57
chakieI see "IMAGE_BOOT_FILES += "boot.bin uEnv.txt ${KERNEL_IMAGETYPE}-zynq-zed.dtb""11:57
chakiegoodwin: they are nowhere in my entire tree.11:58
chakiegoodwin: in this case we later take the images, move them to developers, extract the images, add in lots more sw compiled using the created sdk, packaged back to an image and then deployed11:59
tgoodwinchakie: at a glance between thud and warrior of the machine config, I'm not seeing anything that would prevent those two from being built.12:03
tgoodwinHave you tried "bitbake virtual/boot-bin"?12:03
tgoodwin(I'm mainly curious if it'll complete without executing anything as if it's already built)12:03
chakieLet me see12:05
chakieI looked at "bitbake -e" to see if it referenced "u-boot.img" at all and found:12:05
chakieIMAGE_BOOT_FILES="uImage zImage u-boot.img zynq-zed.dtb boot.bin uEnv.txt uImage-zynq-zed.dtb"12:05
chakieSo the environment "knows" about what it should produce12:06
*** Chrusel <Chrusel!c1669b04@> has joined #yocto12:06
chakiegoodwin: huh, doing "bitbake virtual/boot-bin" started fetching/building u-boot stuff12:07
tgoodwinSure, but if nothing is depending (RDEPENDS) on the package that provides those files, then they won't be available at runtime.12:07
chakieSo something is now broken in out setup12:07
tgoodwinDid you modify EXTRA_IMAGEDEPENDS at all?12:07
tgoodwinThe machine has that defined with "virtual/boot-bin", so once you build an image, it should have also built that package.12:08
chakiesounds logical12:08
tgoodwin(also has virtual/bootloader, FWIW)12:09
chakieThere is "EXTRA_IMAGEDEPENDS_remove = "u-boot-zynq-uenv""12:09
chakieA comment says it introduced some license issues. But then there should be some other u-boot depended upon somewhere else, right?12:10
*** florian__ <florian__!~florian_k@Maemo/community/contributor/florian> has joined #yocto12:11
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC12:12
tgoodwinThat recipe only builds out a uEnv.txt file for the SD card that maps to the various file names for your target (kernel, dtb, etc.)12:13
chakie"bitbake -e" says "EXTRA_IMAGEDEPENDS=" u-boot-zynq-uenv""12:13
chakieok, so that's not what makes the real images?12:13
tgoodwinThat's funny.  I would read the comments above that line to see what all is adding/removing.  That variable not having virtual/boot-bin, etc., is why it's not being built for your image.12:14
tgoodwinIf you have a pastebin of your -e output, I would be happy to look at it.12:15
chakieIt's 1.4MB12:16
chakieLet me upload it somewhere12:18
*** vmeson <vmeson!> has quit IRC12:21
chakieI have lots to learn about debugging this stuff...12:22
iceawaymckoan: thanks that was my initial thought as well. Coming from a previous project using buildroot yocto seems quite a bit more complex. I was thinking of also creating our own distro (based on poky, not sure if we need our own distro though?) and image based on core-image-minimal. If I have understood things correctly, we should create our own layer meta-whatever and keep our customizations there, to make12:23
iceawayit easier to share between developers (as opposed to having everything in local.conf).12:23
* zeddii wakes up to have someone informing him of how virtual/kernel is used.12:24
tgoodwinchakie: Did you modify the zedboard-zynq7.conf?  Your environment says it only adds u-boot-zynq-uenv vs. the other lines I see here:
zeddiiRP: I see your email. A lot of history here, so I'll go from what you have in the email.,12:26
chakiegoodwin: yes, it has been changed a bit12:28
chakiegoodwin: but those extra dependencies have not been removed though.12:29
chakieperhaps something in the xilinx layer has changed that just happened to make us depend on those before.12:30
tgoodwinchakie: alright, well from your log, it's only adding that one recipe to that variable and nothing is attempting to remove anything.12:30
tgoodwinIf you search for "EXTRA_IMAGE_DEPENDS [3 operations]" you'll see it calls out line 19 of your machine conf as where it adds that one recipe, and nothing else changes it.12:31
tgoodwinBTW if you copied the machine to your new layer (rpd?), you should probably rename it.12:32
chakieI didn't set this up, so I'm not exactly sure why things were done the way they were.12:32
tgoodwin(i.e., define a new machine entirely)12:32
chakieThat is perhaps a wise way to go12:33
tgoodwinI understand.  That log is showing that it's pulling in meta-rpd/conf/machine/zedboard-zynq7.conf vs. the meta-xilinx-bsp one12:33
chakieAnd to actually understand what happens...12:33
chakiegoodwin: but you mean that this is never actually executed: EXTRA_IMAGEDEPENDS_remove = "u-boot-zynq-uenv"12:35
tgoodwinWhere is it written?12:36
chakieI also saw in that environment that it was only added to12:36
tgoodwin(and no, according to your log it never gets picked up)12:36
chakieit's in the root recipe that we build12:36
chakiea ""12:37
zeddiiahaha. RP. now I know why I didn't see the eudev build issue.12:37
zeddiiERROR: Nothing PROVIDES 'eudev'12:37
zeddiieudev was skipped: conflicting distro feature 'systemd' (in DISTRO_FEATURES)12:37
chakieIt basically inherits core-image, adds some extra packages and removes some unwanted ones12:38
tgoodwinchakie: ah.  Well if you ran "bitbake -e rpd-base-image", I would expect to see the _remove show up.12:39
tgoodwinchakie: also, I'm not sure that making changes to that variable in an image definition is really fitting with the intent of that variable:
tgoodwinIt's a list of packages that are not needed for the rootfs (vs. the image defining what goes in the rootfs)12:41
zeddiiRP: but yet lttng-ust build here for qemuppc. hmm. I'll dig more.12:42
chakiegoodwin: yeah, now I see the remove and it's left empty12:42
chakieFrom what I can grok, we used to get a dependency on "virtual/u-boot" or similar with the sumo versions of our layers, but now don't12:44
chakieWhich means we build an assload of packages that never get used anywhere. :)12:45
*** Chrusel <Chrusel!c1669b04@> has quit IRC12:47
tgoodwinchakie: Yeah, I'm not sure how that dependency would have changed between sumo vs. warrior unless something is horked up with your bblayers.conf and layer priorities between those two builds (this would end up picking the xilinx -defined machine vs. your meta-rpd one)12:47
RPzeddii: that is odd :/12:48
RPzeddii: note it was the mpc, not qemuppc12:48
zeddiiI can try that as well. but just switching to sysvinit is going to take about an hour for my builder to recover, so I'll churn away on them as fast as I can12:49
* zeddii builds @ home with two servers in his basement, so no corporate build power unfortunately.12:50
chakiegoodwin: hm, now when I look at the files we have a bit closer it seems that the zedboard-zynq7.conf is never updated based on new changes, it's been like that for years12:51
*** AndersD <AndersD!> has quit IRC12:52
*** cpo <cpo!> has quit IRC12:52
zeddiiRP: the one I find the most odd is the qemuarm /dev/fb0 one. I was building and booting that constantly. So I'll dive into the logs while I wait for builds and see if I can spot a difference.12:52
*** cpo <cpo!~cpo@> has joined #yocto12:53
RPzeddii: its possible its some other patch in -next :/12:53
RPzeddii: it sounds kernel related though12:53
RPzeddii: btw, I think I missed qemumips issues from that email :/12:53
zeddiiagreed. starting with the kernel is the right thing.12:53
tgoodwinhmm.  Well, layer order matters in bblayers.conf since that's going to wind up being the set of search paths for recipes, conf files, etc.  Since your environment is picking up your meta-rpd -based machine, you should update the EXTRA_IMAGEDEPENDS to include those two virtual targets so it'll build them with your image.12:54
kanavin_RP: zeddii: I wonder if the /dev/fb0 is this
zeddiibugger. I build qemumips/mips64 for all the images I could think of.12:54
kanavin_still, as far as12:54
tgoodwinIt's that or you'll have to manually build virtual/boot-bin and virtual/bootloader ahead of building your image(s).12:54
RPlib64-packagegroup-core-device-devel-1.0-r1 do_populate_lic - 2h53m1s (pid 8842)12:54
RPthat sounds wrong12:54
tgoodwin(so that the files will exist in the deploydir)12:54
zeddiiRP: and if yous eee alex's follow up. I missed a kernel feature in my recipe copy. so I bet that is the fb0 thing.12:55
chakiegoodwin: yeah, I added them to EXTRA_IMAGEDEPENDS and building right now12:55
kanavin_as far as I understand, -device VGA,edid=on is equivalent to -display vga, and -display vga is actually the default, so it doesn't need to be specified explicitly12:55
kanavin_yeah, maybe the missing drm-bochs bit also plays a role12:55
zeddiiI'll deal with the root cause of me dropping that, once we are green with 5.2.12:55
RPzeddii: ok, are you going to send some more patches and we can retest?12:56
chakiegoodwin: ok, now I got all the image files except a uImage-zynq-zed.dtb12:56
zeddiiRP: yes. do you want new versions or follow on patches. I can easily do either flow.12:56
*** yacar_ <yacar_!~yacar@> has quit IRC12:56
RPzeddii: may as well do follow on and let me know if anything should be squashed12:57
RPzeddii: I have Kevin's BSP uprev to add in the next round which may help mpc12:57
*** nabokov <nabokov!~armand@> has joined #yocto12:57
tgoodwinchakie: It looks like your machine adds that name to IMAGE_BOOT_FILES, which ultimately ends up containing zynq-zed.dtb and uImage-zynq-zed.dtb (the former is added by xilinx's according to your env file).12:59
tgoodwinchakie: Do you have a package that installs uImage-zynq-zed.dtb to the deploydir?13:00
zeddiiRP: works for me. I'll just keep stacking changes, and can put in the temp section where it can be squashed.13:01
* zeddii deals with follow ons better than new revisions when merging as well13:01
*** jeanba <jeanba!~jbl@> has joined #yocto13:01
*** jeanba <jeanba!~jbl@> has left #yocto13:02
chakiegoodwin: to build/tmp/deploy/images/zedboard-zynq7?13:02
tgoodwinchakie: right.  If you have a package that builds that file (and inherits from deploy, etc.), then similar to before, you can add it to the machine's EXTRA_IMAGEDEPENDS too so that it implicitly gets built (the rest of your config like KERNEL_DEVICETREE seems to imply you're also using the one from the virtual/kernel package)13:04
tgoodwinchakie: so unless you don't want that device tree blob as well, you should probably remove the zynq-zed.dtb from IMAGE_BOOT_FILES list in your machine as well.13:05
jwesselRP: I tracked down the getty fast fail problem.  systemd is ever changing...13:05
jwesselIt only happened on a first boot.13:05
zeddiilove those kind of ones. means constantly copying images or rebuilding new ones.13:05
jwesselAnd even then, not all the time, as it is a udev/systemd race.13:05
RPjwessel: ah. Glad we're not imagining it then :)13:05
jwesselThat is why I copied the image the one time I saw it.13:06
chakiegoodwin: our scripts that grab the built files seem to expect that dtb file.13:06
RPzeddii: qemu can do COW13:06
jwesselI figured it must be something super odd.13:06
RPjwessel: runqemu should only ever work off a copy and hence be a first boot13:06
jwesselI am reading the latest systemd foo in order to figure out a different way to use it, hopefully without patching the code.13:06
RPjwessel: hence the 100% autobuilder hit13:06
*** rcw <rcw!~rcw@> has joined #yocto13:06
jwesselBut runqemu makes a copy only the first time.  Statistically autobuilder was going to hit it more often because of that.13:07
jwesselsecond boot, as far as I can tell never will hit it, because udev is running much earlier.13:07
jwesselIn the systemd in thud, it was fine to use the BindsTo=...13:10
jwesselNow it has to work like this:13:10
jwesselAfter=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service13:10
jwesselSo for the ttyUSB0 transient device case we get:13:10
jwesselAug 29 13:09:05 qemux86-64 systemd[1]: Condition check resulted in Serial Getty on ttyUSB0 being skipped.13:10
nrossichakie: tgoodwin: zynq-zed.dtb is the proper name for the dtb, uImage-...dtb is no longer produced by the kernel see (
jwesselAt least we didn't have to patch systemd...13:12
tgoodwinchakie: alright.  Looking at the history of meta-xilinx, it looks like it used to be called ${KERNEL_IMAGETYPE}-zynq-zed.dtb and then the moved it all up into that machine include file as a function.13:12
tgoodwinnrossi: beat me to it.13:13
tgoodwinthanks ;)13:13
*** learningc <learningc!> has quit IRC13:14
tgoodwinchakie:  it looks like that function (get_default_image_boot_files) then received another tweak to do what nrossi pointed out, which is no longer prefix KERNEL_IMAGETYPE to the KERNEL_DEVICETREE name(s).13:15
chakiegoodwin: aha, our scripts expected the image type to be prefixed.13:16
chakieNo worries there, easy fix as zynq-zed.dtb is generated just fine.13:17
tgoodwinchakie: yeah, at least we've identified you don't have some other package providing that other name :)13:17
yoctiNew news from stackoverflow: updating nodejs on linux (yocto) using npm <>13:17
chakiegoodwin: no, but we do have a small mess that has seen some bit rot :)13:20
chakiegoodwin: I would never have figured this out without your help... Thank you so much!13:22
tgoodwinchakie: you're welcome :)13:25
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC13:27
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto13:27
*** stefandxm <stefandxm!> has quit IRC13:29
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC13:30
*** yates <yates!> has quit IRC13:31
*** vmeson <vmeson!~rmacleod@> has joined #yocto13:33
RPJPEW: reproducibility tests ran on the autobuilder, it wasn't so good :/13:38
RPJPEW: I might have found the ca-certs one13:39
JPEWRP: Yep, those look like the usual suspects13:49
JPEWWell, except for the kernel module13:49
*** marka <marka!~marka@> has joined #yocto13:51
mckoaniceaway: yes, you are right13:51
zeddiiRP: gah. on my builder the ppc neard issues doesn't show up. that's two now that I can't reproduce.13:52
zeddiiI was using musl in that config. but really, that should hurt, not help.13:52
zeddiiTARGET_SYS           = "powerpc-poky-linux-musl"13:53
zeddiiMACHINE              = "mpc8315e-rdb"13:53
zeddiiDISTRO               = "poky"13:53
zeddiiaaaaaand eudev just built for the mpc as well.13:53
*** tsjsieb <tsjsieb!~quassel@> has joined #yocto13:54
RPzeddii: could be a musl vs glibc difference? :/13:54
RPJPEW: so they're known issues?13:55
zeddiiI just switched to glibc and started again. I'll know soon.13:55
*** bachp <bachp!bachpmatri@gateway/shell/> has quit IRC13:55
*** kaspter <kaspter!~Instantbi@> has quit IRC13:55
JPEWRP: They look familiar... I think those might be the ones that have trouble passing without doing 2 clean builds (it was a while ago, so I don't remember exactly).13:57
jwesselRP, thanks for the information from the autobuilder.13:58
jwesselI sent a new v2 of the getty fast-fail patch, which is tested specifically against u-dev race that was found.13:58
JPEWRP: The doc ones are almost certainly because of pod2man in HOSTTOOLS13:59
jwesselI also re-tested against the hardware states of having the usb device in, out, plugged in after boot, and unplugged after boot to make sure the behavior was all still consistent.13:59
*** bachp <bachp!bachpmatri@gateway/shell/> has joined #yocto14:01
JPEWRP: ACL is probably also because of HOSTTOOL paths changing (coreutils mostly) due to rebuilds with RSS, and perl-ptest.... is just a mess :)14:01
*** rcw <rcw!~rcw@> has quit IRC14:03
*** bisbarn <bisbarn!> has joined #yocto14:07
*** yates <yates!> has joined #yocto14:09
*** rcw <rcw!~rcw@> has joined #yocto14:09
yatesthis is my file:
yateswhat is the "bb.utils.contains" function on line 13?14:10
qschulzif SWUPDATE_INIT contains tiny then initscripts-swupdate else initscripts sysvinit14:12
*** sgw <sgw!~sgw@> has quit IRC14:12
khemzeddii: meta-openembedded also shows some failures with 5.2 headers see
khemklibc linux-atm can-util qtserialbus qtwebengine14:14
zeddiikhem: yep, I knew there would be failures, given that I had to fix packages for the tweaked y2038 headers, but I'm tapped out on cycles at the moment.14:15
khemerror: use of undeclared identifier 'MAP_PRIVATE'14:15
zeddiiRP: I can reproduce none of the autobuilder failures.14:15
zeddiiI just built lttng-ust, neard and eudev for the fsl_mpc14:15
khemis MAP_PRIVATE gone ?14:15
zeddiiit may have moved. /me goes to check.14:16
yatesha ha. /me14:16
khemother issue is error: use of undeclared identifier 'SIOCGSTAMP' which is trivial to fix14:16
yatesqschulz: thanks!14:16
zeddiiyah. that was was littered in a few packages.14:17
zeddiiI just have NFI how I can be building the packages fine that the autobuilder couldnt14:18
yatesno financial information?14:18
RPzeddii: not good :(14:19
zeddiiI'm switching to your master-next with none of my local changes and will try that.14:19
zeddiiI'm sure none of them are that hard, if I can just reproduce them. I had to fix a lot during the early days after I bumped the headers.14:20
*** chinhuat64 <chinhuat64!~chinhuat@> has joined #yocto14:22
khemzeddii:btw. musl version in oe-core does have 5.2 fixes so it is possible that something will build with musl but not glibc14:22
*** chinhuat6 <chinhuat6!~chinhuat@> has quit IRC14:23
*** stephano <stephano!~stephano@> has joined #yocto14:24
*** goliath <goliath!~goliath@> has quit IRC14:25
*** kroon <kroon!~kroon@> has quit IRC14:25
*** Crofton|mini <Crofton|mini!~Crofton@2601:5c0:c100:b84:3d3f:64d6:2ba1:780b> has quit IRC14:28
*** sgw <sgw!~sgw@> has joined #yocto14:31
*** yacar_ <yacar_!~yacar@> has joined #yocto14:33
bisbarnGoodday, I'm currently trying to find the best way to deal with device tree overlays. I basically want to use u-boot to load overlays over the base device tree, the only problem is that the base devicetree (that will be built by kernel-devicetree) does not use the "-@" flag for dtc, and thus there are no __symbols__ in the blob which u-boot needs. My workarround currently is to clear KERNEL_DEVICETREE and add a recipe file which inherits14:35
bisbarnfrom devicetree. Within this recipe I build the base devicetree and all the overlays (I can overrite DTC_FLAGS which is used by I was wondering if there might be a better solution to that problem ;)14:35
bisbarnA soluition that would work with KERNEL_DEVICETREE14:36
__angelohi :) have an image with a DEPENDS += "another_image" but seems the build of "another_image" is not triggered14:38
*** learningc <learningc!~learningc@> has joined #yocto14:42
ykronsHi all, I'm trying to build a node.js package with Yocto (rocko) according to I finally succeed building the example cute-files, but when I go with my own package its fails with "Exception: RecursionError: maximum recursion depth exceeded in comparison" (it seems) during dependencies research. Does someone already have similar issue?14:45
*** yacar_ <yacar_!~yacar@> has quit IRC14:45
qschulzbisbarn: when I manually compiled the kernel for DT overlays, I made those two patches:
qschulzmaybe you can apply those to your kernel14:49
*** rcw <rcw!~rcw@> has quit IRC14:51
qschulz__angelo: here we have do_rootfs[depends] += "foo-image:do_build"14:52
__angeloqschulz, oh thanks14:53
bisbarnqschulz: that should work, I'll give it a try tomorrow, thank you ;) wondering why they haven't added a config option to enable building the devicetrees with symbols to the kernelconfig :)14:53
qschulzHonestly I don't know, they have changed already a few times the format of device trees,nothing's fixed yet AFAIR14:54
qschulzmight not even be -@ anymore14:54
bisbarnwell atleast with 4.9.13 it still is ;)14:55
qschulzand you need dtc > 1.14 from what I recall, directly in the kernel sources14:55
bisbarnbut I guess 4.9.13 should come with dtc  1.14 ;)14:56
*** Bunio_FH <Bunio_FH!> has joined #yocto14:56
mckoan__angelo: of course a dependency from an image can make sense only as runtime so it should be a kind of RDEPENDS14:56
qschulzwell, the patch I sent you is for 4.9 (I don't know the dot)14:57
qschulzmckoan: it's a bit trickier I think. There is a task dependency behind DEPENDS and RDEPENDS14:58
qschulzimage recipes are different and i honstely don't know if they have those tasks or if something is done in there14:58
qschulzso one task depends on a task which is empty or never executed or so, basically a no-op14:59
qschulze.g. This dependency is from the recipe's do_build (not to be confused with do_compile) task to the do_package_write_* task of the recipes that build bar and baz.14:59
*** yacar_ <yacar_!~yacar@> has joined #yocto15:01
qschulzbisbarn: FYI, only since 4.1115:08
__angelomckoan, tested also RDEPENDS, not working for mw15:09
*** frsc <frsc!> has quit IRC15:09
*** rcw <rcw!~rcw@> has joined #yocto15:10
*** lfa <lfa!~lfa@> has joined #yocto15:12
__angeloqschulz, oh, seems do_rootfs[depends]  is also not working. Shoudl i cleanall ?15:19
*** TobSnyder <TobSnyder!> has quit IRC15:24
armpitYP bug triage over15:24
*** goliath <goliath!> has joined #yocto15:25
*** florian__ is now known as florian15:29
nrossiRP: no sstatetests failures with the gcc-common change15:31
RPnrossi: ok, great. I'm surprised but that is good15:31
*** jmiehe <jmiehe!> has quit IRC15:31
JPEWRP: Sent clean build patch for reproducible OEQA test15:31
RPJPEW: thanks, I'll rerun it with that15:31
nrossiRP: also looks like there is already a "tag" decorator in the oeqa core. But i think it works in reverse to how you might want it to work for the toolchain tests15:32
nrossiRP: the runner filters cases that match the tag15:33
mckoan__angelo: of course, I didn't say to use RDEPENDS15:33
zeddiiRP: I just can't break any of the packages that blew up for you.15:33
RPnrossi: oh. Do we use that anywhere? Could we add a match option I wonder?15:34
nrossiRP: it did not appear anywhere in oe-core/meta. So it could just be reversed15:34
mckoan__angelo: AFAIK is not possble to depend on an image though15:35
RPnrossi: very tempted to do that...15:35
nrossiRP: i will look at doing that then, see if it can work. anyways I am off to bed, will likely have updates for you tomorrow15:38
RPnrossi: thanks, sleep well!15:40
*** yacar_ <yacar_!~yacar@> has quit IRC15:49
__angelomckoan, ooh, so it is not possible to trigger another image from the current ?15:54
__angelook :(15:55
*** yann <yann!~yann@> has quit IRC15:58
zeddiiheh. even on master next, mpc8315e-rdb, I can build lttng-ust, eudev and neard. time to ponder WTF is going on.15:58
kanavin_RP, sadly, looks like u-boot is not ready for python 3, they need to update several scripts that are used during build16:01
kanavin_I wonder if we can apply pressure for them to get on with it somehow16:02
yoctiNew news from stackoverflow: YOCTO : Where can I find my Linux kernel source directory? <>16:18
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:31
RPkanavin_: I think people like Tartarus are already working on that16:34
Tartaruskanavin_: Ahem, patches welcome.16:35
TartarusIt's not that we're unaware of the deadline, it's that no one has volunteered to help move things along.16:35
armpitsame old story for all of use16:36
*** mckoan is now known as mckoan|away16:37
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:47
*** rewitt <rewitt!rewitt@nat/intel/x-ijppdrbivtugiyqy> has joined #yocto16:47
*** scottrif <scottrif!> has joined #yocto16:55
scottrifHi - Trying to track down Bruce Ashfield these days... anyone know where he is in #yocto or email?16:56
kanavin_scottrif, he's zeddii I think16:56
kanavin_and active in oe-core16:56
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC17:01
*** Bunio_FH <Bunio_FH!> has quit IRC17:01
aehs29khem: thers a patch to libdevmapper one meta-oe  thats breaking for me ( 3f64779ea ), I think its because it sets PACKAGES="", am I the only one that has this issue?17:03
*** learningc <learningc!~learningc@> has quit IRC17:04
*** learningc <learningc!~learningc@> has joined #yocto17:04
*** tprrt <tprrt!~tprrt@> has quit IRC17:06
Tartaruskanavin_, RP, if I build build-appliance-image on master (or warrior..) will that get me something with python==python3 or do I need something more for that?17:08
TartarusOr is there some other easy way to get myself a development system without python2, so I can see what else is hitting the fan, aside from libfdt horrors17:08
*** yates <yates!> has quit IRC17:10
kanavin_Tartarus, the way I am doing it is by mv /usr/bin/python2.7 /usr/bin/python2.7.bogus17:10
kanavin_and patching out python2 from HOSTTOOLS in bitbake.conf17:10
TartarusWhat's your starting host?17:11
khemaehs29: how does it break ? maybe carry the discussion on ml ?17:11
kanavin_Tartarus, ubuntu 18.0417:11
kanavin_then you need to adjust the recipe to not require python-native17:11
TartarusWell, I'm going to be trying to do things in U-Boot itself, just need an env17:12
kanavin_or, actually if you are not using bitbake but building u-boot directly on the host, then simply moving py2 out of the way is enough I guess17:12
TartarusI know libfdt stuff is going to crap out, which is annoying17:12
Tartarusbut I think, aside from (which 2to3 + stack overflow got me converting) it might be otherwise "just" changing python2 to python3 in some places17:13
kanavin_Tartarus, I tried PYTHON2=python3, and libfdt was happy with that, but then somewhere else failed17:13
TartarusOh? Hmm17:13
TartarusI'll see what I see soon then, thanks17:13
kanavin_because #!/usr/bin/python17:13
aehs29khem: shouldve checked the ML before my bad17:13
kanavin_at that point I gave up17:13
aehs29khem: its actually a different error, but let me check the latest patch, if its still breaking I'll reply to the ML thread17:14
*** fullstop <fullstop!~fullstop@> has joined #yocto17:33
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC17:38
*** rewitt <rewitt!rewitt@nat/intel/x-ijppdrbivtugiyqy> has quit IRC17:41
*** rewitt <rewitt!~rewitt@> has joined #yocto17:41
qschulz__angelo: yes you can, I do it. I did a shortcut. We have a new task which is addtask bar before do_rootfs and then do_bar[depends] += "foo-image:do_build". IIRC. I don;t have access to the code right now though.17:56
qschulzhave you tested each image separately to make sure they work on their own already?17:57
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:59
*** WillMiles <WillMiles!> has joined #yocto18:08
__angeloqschulz, oh thanks. Yes, images works18:19
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:20
__angeloqschulz, well, if it happens you have a code sample, even similar, would be nice18:20
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto18:31
*** rcw <rcw!~rcw@> has quit IRC18:35
*** yates <yates!> has joined #yocto18:40
*** JPEWhacker <JPEWhacker!~yaaic@2600:100a:b00d:8230:d5c9:f019:2a6:1e43> has joined #yocto18:51
*** JPEWhacker <JPEWhacker!~yaaic@2600:100a:b00d:8230:d5c9:f019:2a6:1e43> has quit IRC19:00
*** JPEWhacker <JPEWhacker!~yaaic@2605:a601:21d1:5200:8cdb:3150:46e2:5a1f> has joined #yocto19:00
zeddiiRP: unfortunately, no patches from me today. My day was derailed on not being able to reproduce things, so I just watched builds for the most part.19:01
zeddiiI'm only working a 1/2 day tomorrow, which means mid next week before any significant process can be guaranteed.19:02
zeddiiI'd suggest just dropping the whole thing from master-next, and I can resubmit when / if I can reproduce the failures.19:02
LetoThe2ndzeddii: does it mean significant beer && metal? :P19:03
zeddii:D beer at least.19:03
* zeddii sees about 200 email that he didn't read today while trying to sort this stuff. So yah, beer now!! I can't stand to dig into it at the moment19:04
* zeddii bets he'll get 'ping' email on it tomorrow and will have to not type any hasty responses ;)19:04
LetoThe2ndexactly my life these days. $CUSTOMER is bitching and so i'm currently doing funky js dev on my balcony. beer is involved @ 9pm.19:07
zeddiithis is why we all head to conferences to commiserate and do more beer :D19:07
*** thannoy <thannoy!> has joined #yocto19:07
LetoThe2ndyou @ ELCE?19:08
zeddiiI am19:08
LetoThe2ndnice. so yay for beer.19:08
zeddiimost definitely.19:08
LetoThe2ndi think so far i am the only OE member that has only be accepted under the official premise that i bring along booze to meetups.19:09
*** yann <yann!> has joined #yocto19:10
fullstopany suggestions on how to speed up "Parsing recipes" in bitbake?  I'm toying with local.conf and it takes several minutes between iterations..19:17
JPEWhackerfullstop: are you using multiconfig?19:17
fullstopconsidering that I don't know what that is, doubtful.19:18
fullstopI'm coming from buildroot, so this is all very foreign at the moment.19:18
JPEWhackerfullstop: ah. you can try removing unnecessary layers.19:19
LetoThe2ndfullstop: take out layers, get ssd, get ram, get fast cpu. in that order, probably.19:19
fullstopdang, I've already done that.19:20
fullstopwell, removed layers.  it's a ssd and fast cpu already.19:20
LetoThe2ndthen you must have an extremely rich stack of layers n use, because parsing on my desk machine takes somewhere in the 30-50sec range usually.19:21
fullstopI don't have all of these resources available to me, but I've got 96GB of memory and a 24 core X5670..19:21
fullstopanyway, I guess I'll live with it for now.19:21
JPEWhackerdoes everyone have double digits CPU cores? I feel left out19:24
fullstopthis is a server if it makes you feel any better19:24
LetoThe2ndfullstop: aw, i was sooo convinced it is your tablet :/19:25
fullstopIt wouldn't surprise me if the next generation of snapdragon cpus steps into double digits.19:26
LetoThe2ndhrhr. and with that, I'll call it a day.19:27
TartarusOK, so, kanavin_, RP, I've kicked things harder.  Where we stand is that some of our tools (binman) need some more work, but Simon Glass (author) knows/is on it.  Is a problem for some targets such as allwinner.  Another script we need, I converted today as 2to3 + stackoverflow got me there.  scripts/dtc/pylibfdt/ just needs s/python2/python3/ and that is going on upstream to maybe just be "python", but we'll do19:37
TartarusThere's a few other scripts that are python2 but aren't part of the required build, one of which I'm just killing and another needs someone that speak python to figure out19:37
yannthere seems to be a known issue with psplash images being shipped as C code without the png source (see and
*** khem <khem!~khem@unaffiliated/khem> has quit IRC19:39
yannappart from being annoying when one wants to change the theme, isn't there a problem with the GPL here, as this is clearly not "The source code for a work means the preferred form of the work for making modifications to it" ?19:39
yatesi'm confused about the INITRAMFS_IMAGE used in local.conf19:39
yatesthe docs state that setting this "Causes the OpenEmbedded build system to build an additional recipe as a dependency to your root filesystem recipe "19:40
yatesso for example, would setting INITRAMFS_IMAGE "abc" cause an actual .bb file to be generated,
yates" an initramfs image named to be created"19:42
yatesmine is set to 'INITRAMFS_IMAGE = "swupdate-image"'19:43
yateswhich i thought was running the file /sources/meta-swupdate/recipes-extended/images/swupdate-image.bb19:43
yatesis that not the case?19:45
yatesthe link local.conf.sample.extended referenced in this glossary entry is dead19:49
yatesis this thing on?19:50
yatesas i understand it, a cpio.gz file can be provided to the kernel recipe to which specifies the rootfs to use for a initramfs. i am trying to see how those rootfs files are generated so i can add my own init.d script19:53
*** nabokov <nabokov!~armand@> has quit IRC19:54
*** Bunio_FH <Bunio_FH!> has joined #yocto19:54
*** JPEWhacker <JPEWhacker!~yaaic@2605:a601:21d1:5200:8cdb:3150:46e2:5a1f> has quit IRC19:55
yatesstumped you all? ha!19:56
*** JPEWhacker <JPEWhacker!~yaaic@2600:100a:b00d:8230:d5c9:f019:2a6:1e43> has joined #yocto19:57
*** JPEWhacker <JPEWhacker!~yaaic@2600:100a:b00d:8230:d5c9:f019:2a6:1e43> has quit IRC20:01
yatesheck with linux. anyone up for some spectral esimation using minimum relative entropy?20:02
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto20:04
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto20:05
*** thannoy <thannoy!> has quit IRC20:06
kergothpretty sure there's a different variable for bundling the initramfs image into the kernel rather than just producing the image binary20:09
kergothdon't recall the name offhand. INITRAMFS something or other20:09
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC20:10
kergoththat's the one, thanks20:12
khemand you need to define initramfs image with INITRAMFS_IMAGE20:13
kergothINITRAMFS_IMAGE Just builds the initramfs. iirc you could have your bootloader make use of it instead of bundling it into the kernel?, though i don't know why, that'd be more like initrd20:13
* kergoth shrugs20:13
khembootloader just knows about kernel so that remains consistent weather you use initramfs or not20:14
yatesas i understand it, modern kernel's ALWAYS create a ram-disk-based rootfs initially:
khemkernel can then bundle an image into itself and boot into it20:14
khemwhich can then pivot into full user space rootfs20:15
khemkergoth:grub I think can specify external initrd but to me initramfs in kernel seems better approach20:16
yatesthis is all known. my question is how to customize the rootfs that is bundled into the kernel20:17
yateslike i said, i want to add my own init.d script20:17
kergothkhem: agreed20:17
kergothit's just another image recipe from bitbake's perspetive, yates. specify your own image, done20:17
kergothbut you have to use the bundle variable to get it bundled into the kernel image, and i'm not sure if wic will use the bundled image yet or not20:18
kergothlast time i looked wic didn't handle it at all20:18
yatesyes, it works. i've already built it.20:18
yatesbut i built a non-customized rootfs20:19
yatesi have my INITRAMFS_IMAGE_BUNDLE = "1"20:19
yatesi have my INITRAMFS_IMAGE = "swupdate-image"20:19
kergothso copy to your own image file and change INITRAMFS_IMAGE to match, and modify it as you would any other image in oe20:20
yatesmakes sense. right.20:24
yatesthe existing oe,, ...20:38
yatescontains a line ${@bb.utils.contains('SWUPDATE_INIT', 'tiny', 'initscripts-swupdate', 'initscripts sysvinit', d)}20:38
yateswhich currently fails loades 'initscripts sysvinit'.20:39
yatesif i just define SWUPDATE_INIT='tiny', then couldn't i j use the oe swupdate-image and put in my own initscripts?20:40
yatesno, nm20:40
yatesthat .bb already exists.20:41
yatesi'm trying to optimize yocto - bad idea...20:41
yatesjust copy the damn
yatesnew (but related) question: in my standard image recipe i have packages recipes specified in "CORE_IMAGE_EXTRA_INSTALL" but also in "IMAGE_INSTALL_append". what's the difference?20:43
kergoththe former is only obyeed in the images inheriting core-image, not just image. the latter is obeyed everywhere. the problem with the latter is it's difficult for a recipe to override (i.e. an initramfs recipe can't just set CORE_IMAGE_EXTRA_INSTALL="" to prevent those from installing, so it's more likely to affect images you don't want it to, and it's just more prone to user error. the former is an explicit hook, so doesn't require _apppend vs +=21:00
yatesok, thanks kergoth21:04
yatesi'm not sure i'm grokking all that, but thanks..21:04
*** berton <berton!~berton@> has quit IRC21:15
*** vmeson <vmeson!~rmacleod@> has quit IRC21:18
*** WillMiles <WillMiles!> has quit IRC21:31
*** dv_ <dv_!> has quit IRC21:48
*** lfa_ <lfa_!~lfa@> has joined #yocto22:02
*** dv_ <dv_!> has joined #yocto22:02
*** goliath <goliath!> has quit IRC22:03
*** lfa <lfa!~lfa@> has quit IRC22:05
RPzeddii: any patches for me to put into a new build?22:20
RPTartarus: sounds like good progress, thanks!22:20
RPTartarus: I wish I wasn't drowning in release problems or I'd offer to help :/22:20
TartarusRP, I appreciate the senitment, thanks.  We'll get this sorted before Jan 1 at least I'm pretty sure :)22:21
RPTartarus: if you do have specific problems I'm happy to look and see if it matches anything I've run into when doing the conversion for bitbake/OE22:22
khemRP: zeddii said to revert them until mid next week IIRC22:22
RPkhem: thanks, I'd missed that22:23
TartarusWill do22:24
khemI cleaned up first lot in meta-oe as well, now there are some hard nuts like klibc where the syscall stub is failing no idea why, its all perl22:24
zeddiiRP: yah. I can reproduce exactly zero of the failures here.22:25
zeddiiso I'm pretty much screwed on userspace fixes.22:25
zeddiithere's minor changes I'll send tomorrow, but I'm simply not able to do anything with the rest.22:25
zeddiiwhich doesn't surprise me, since I build all those configs before ever sending the series.22:26
RPJPEW: reproducible.ReproducibleTests.test_reproducible_builds: PASSED (7227.98s)22:26
RPJPEW: how curious22:26
RPzeddii: you even tried master-next directly?22:26
RPzeddii: this is very weird :/22:26
zeddiicleanall on neard lttng-ust eudev -> bitbake. no issues.22:27
khemwhats the issue with neard22:27
zeddiiI have to bolt, have to get supper for the kids.22:28
RPkhem: on the mpc machine, neard, eudev and lttnf-ust all failed22:28
RPkhem: and
zeddiiRP: I'm only working a half day tomorrow, and since it is the long weekend .. I won't be back sending patches until middle of next week.22:28
RPzeddii: I reran the build, same errors22:28
RPzeddii: right, ok. I'll switch to hitting other stuff and defer M3 further22:29
zeddiiI'd rather the whole series just be dropped, since I want to rebase and clean things up, since it'll be days before I get to it, and I won't be able to keep is straight.22:29
RPzeddii: can I try and keep the python2 bits?22:29
zeddiithose should be fine.22:30
zeddiiRP: and just as strange. I can reproduce my good builds on two separate machines. so it isn't some uncomitted change I have on my main dev box.22:30
zeddiilike I said, I never would have sent it if something that obvious broke here, so I have no idea what is going on.22:31
RPzeddii: I believe you!22:31
zeddiiall I did was watch builds today.22:31
RPzeddii: there is something we're missing :/22:31
RPits as if the configs don't match somehow22:31
zeddiiI'll keep trying. I won't resend without some explanation :D22:32
RPzeddii: I guess meanwhile I should see if I can reproduce locally22:32
zeddiithey actually aren't hard to fix. most upstreams have patches avaialble (or debian/gentoo)22:32
zeddiiI just need to see it, google it, import and fix. but I'm failing at step #122:33
RPzeddii: right. I was just thinking it would be good to see if someone else can reproduce or not22:33
zeddiiRP: obviously, I'll queue the kernel patches from Kevin, etc, as well, and put them in my next series, since you need my base ones for them.22:33
RPzeddii: right, I just stripped his patch out of -next22:34
zeddiiRP: I don't doubt something funky is going on. I *had* a ppc build error in August. and it was *nasty*22:34
RPzeddii: FWIW beaglebone had WARNINGS:
zeddiiit has to do with the gcd "fixincludes"22:34
zeddiigcc fixincludes that is.22:34
zeddiigcc fixes up the new uapi headers and breaks ppc22:35
zeddiiI couldn't figure out how to disable it.22:35
zeddiiand then the errors "went away"22:35
RPhmm :/22:35
RPit could definitely be related to that22:35
zeddiiI even logged my flailing.22:36
zeddiicheck this out:22:36
zeddiiif you got rid of the fixincludes variant, it built again.22:36
zeddiibut I can't see how my flailing fixed it permantely .. but I'm beginning to wonder :D22:37
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:37
zeddiias usual I'll update on the mailing list if I sort anything more out.22:38
RPzeddii: thanks. I will also reply if I can get anywhere. I need to sleep now but I'll set my builder at this in the morning22:38
RPzeddii: it spent most of today chewing on the multilib issue I mentioned in the email22:38
zeddiihopefully my breadcrumb might come in handy.22:38
RPI figured that was the one you were least likely to look at22:38
zeddiiyah. that saved me having a real panic attack today.22:39
RPzeddii: that one depended on order of files on the disk22:39
khemRP: are we including sys/socket.h in failing files ?22:39
khemif not then that could be the issue22:39
*** robbawebba <robbawebba!~rob@> has quit IRC22:39
RPkhem: not sure. I did wonder22:40
RPkhem: I've not really looked. zeddii wanted to reproduce them first22:40
khemdoes it happen on qemuppc too ?22:40
RPkhem: no22:40
RPkhem: but it did happen with qemuppc-lsb22:41
khemwhats the difference22:41
RPzeddii: which kernel version were you looking at?22:41
RPkhem: kernel version22:41
khemoh so for qemuppc its not bumped to 5.2 ?22:41
zeddiiand also 5.3 and 4.19 in my builds.22:42
zeddiihmm. or maybe not 4.19 for ppc. I wonder if that's what it was.22:42
RPIts odd that it happened for qemuppc-lsb (4.19) but not qemuppc (5.2) and yet mpc8315e-rdb  (5.2) failed22:43
khemRP: its related to kernel-headers mostly22:44
* RP should check the logs to confirm numbers22:44
RPkhem: all should be on latest 5.2 kernel headers22:44
khemso you should check linux-libc-headers22:44
RPI wonder if host headers leak through?22:44
khemhighly unlikely22:45
RPzeddii: qemuppc which worked is still using 5.0 kernel22:45
khemRP:for kernel headers too ?22:46
RPzeddii: so 5.2 kernel headers + 5.0 kernel is working22:46
RP(for qemuppc)22:46
RPit gets stranger, same versions in the lsb build failed22:47
khemwhere do I find qemuppc-lsb definition22:52
RPkhem: its basically DISTRO="poky-lsb" instead of DISTRO = "poky"22:52
RPkhem: now poky-altcfg22:53
khemi c22:53
RPkhem: config is always in the stdio log, exactly what goes into auto.conf and local.conf is unmodified from default22:53
khemso it basically use 4.19 kernel for altcfg thats the only relevant change I see22:55
khemzeddii:did it work with musl ?22:56
khemRP:to me it looks more like glibc and linux-libc-headers problem22:57
*** stephano <stephano!~stephano@> has quit IRC22:58
RPkhem: except its not using 4.19 in the logs :/22:58
RPkhem: I'm not convinced its deterministic23:00
* RP -> sleep. Will email if I get anywhere tomorrow23:00
khemRP: meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend:LINUX_VERSION_mpc8315e-rdb = "4.19.34"23:08
khemso I guess lsb and mpc8315e-rdb are using same 4.19 kernel23:08
khemwell no23:09
khemdont we need meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend as well ?23:10
*** gnac <gnac!> has joined #yocto23:37
*** vmeson <vmeson!> has joined #yocto23:51

Generated by 2.11.0 by Marius Gedminas - find it at!