| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 00:06 | |
| *** Dvorkin <Dvorkin!~Dvorkin@176.114.204.12> has quit IRC | 00:11 | |
| zeddii | RP: bugger! will send an updated patch. | 00:11 |
|---|---|---|
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 00:16 | |
| *** stew-dw <stew-dw!~stew-dw@207.242.234.14> has quit IRC | 00:42 | |
| *** stew-dw <stew-dw!~stew-dw@207.242.234.14> has joined #yocto | 00:42 | |
| *** micka <micka!~micka@reverse-75.fdn.fr> has quit IRC | 01:05 | |
| *** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto | 01:05 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:e5a5:4b94:b3b5:f092> has joined #yocto | 01:22 | |
| *** kaspter <kaspter!~Instantbi@183.128.184.135> has joined #yocto | 01:55 | |
| *** kaspter <kaspter!~Instantbi@183.128.184.135> has quit IRC | 02:00 | |
| *** kaspter <kaspter!~Instantbi@183.128.184.135> has joined #yocto | 02:00 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 03:17 | |
| *** gattuso <gattuso!~gattuso@pompel.me> has quit IRC | 03:58 | |
| *** gattuso <gattuso!~gattuso@pompel.me> has joined #yocto | 04:00 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:25 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:29 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:33 | |
| nrossi | RP: i am here now, I am on UTC+10 so i just missed your message | 04:42 |
| khem | zeddii: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 https://git.openembedded.org/openembedded-core-contrib/commit/?h=yoe/mut&id=547ace04c06e0bddf0ff2d9bc78e49b5eeec5b4f | 04:59 |
| *** frsc <frsc!~frsc@109.250.133.72> has joined #yocto | 05:18 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:33 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 05:35 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 05:37 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 05:41 | |
| *** Dracos-Carazza_ is now known as Dracos-Carazza | 05:52 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 06:03 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:04 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 06:27 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 06:33 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 06:49 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-mjppmdfpmpjwiwen> has joined #yocto | 06:50 | |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 06:54 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 07:09 | |
| *** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 07:13 | |
| *** yann <yann!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has quit IRC | 07:14 | |
| *** chakie <chakie!~jekholm@212.213.16.13> has joined #yocto | 07:30 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 07:30 | |
| chakie | hi folks! | 07:30 |
| jwwww | hi chakie . | 07:31 |
| chakie | i'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 fine | 07:32 |
| chakie | Now immediately when I start the bitbake for the image I get: "ERROR: Nothing PROVIDES 'cpio-native'." | 07:33 |
| chakie | While googling for the error I saw that there was some talk about it here last year, but I saw no solution. | 07:33 |
| chakie | I 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 |
| erbo | chakie: it's provided by poky/meta/recipes-extended/cpio/cpio_2.12.bb | 07:37 |
| chakie | That 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 generated | 07:37 |
| chakie | I 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 |
| chakie | I 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 |
| erbo | chakie: could you try "bitbake-layers show-recipes cpio-native"? | 07:40 |
| chakie | yes | 07:40 |
| chakie | NOTE: Starting bitbake server... | 07:41 |
| chakie | WARNING: 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 |
| chakie | Loading cache: 100% |######################################################################################################################################################################################################################################| Time: 0:00:00 | 07:41 |
| chakie | Loaded 3327 entries from dependency cache. | 07:41 |
| chakie | Parsing recipes: 100% |####################################################################################################################################################################################################################################| Time: 0:00:02 | 07:41 |
| chakie | Parsing of 2244 .bb files complete (2243 cached, 1 parsed). 3328 targets, 340 skipped, 0 masked, 0 errors. | 07:41 |
| chakie | Hm, that was a bit ugly. But it really shows nothing at all except for the normal "parsing recipes". | 07:41 |
| erbo | chakie: no "=== Matching recipes: ===" section at the end? | 07:42 |
| chakie | No, that's all | 07:42 |
| chakie | Just a: | 07:42 |
| chakie | Summary: There was 1 WARNING message shown. | 07:42 |
| chakie | (about the distro) | 07:42 |
| erbo | do "bitbake-layers show-layers" list the "meta" layer? | 07:43 |
| chakie | Yes | 07:43 |
| chakie | Trying the show-recipes for "cpio" gives: | 07:43 |
| chakie | === Matching recipes: === | 07:44 |
| chakie | cpio: | 07:44 |
| chakie | meta 2.12 | 07:44 |
| jofr | Thanks for those progress bars. I will save those for later. *tongue-in-cheek* :p | 07:44 |
| chakie | sorry... | 07:44 |
| erbo | :) | 07:44 |
| chakie | To my defense I haven't been on IRC for 10 years. | 07:44 |
| erbo | and poky/meta/recipes-extended/cpio/cpio_2.12.bb has BBCLASSEXTEND = "native" at the bottom? | 07:44 |
| chakie | Let me see | 07:45 |
| chakie | find chugs along | 07:46 |
| LetoThe2nd | chakie: pro tip: use ag (a.k.a. the silver searcher) instead of grep and fd instead of find. | 07:47 |
| chakie | yes, it ends with: | 07:47 |
| chakie | BBCLASSEXTEND = "native" | 07:47 |
| erbo | Then I don't really know what's going on. :( | 07:48 |
| chakie | What would be a good variable to add the dependency to? | 07:50 |
| chakie | EXTRA_IMAGEDEPENDS? | 07:50 |
| erbo | I would try to find what's causing this weird stuff instead of finding some way to make it work anyway | 07:51 |
| LetoThe2nd | chakie: my suggestion would rather be to find out what pulls it in and trace from there backwards. | 07:52 |
| erbo | cpio-native should be there, you shouldn't need to use ASSUME_PROVIDED | 07:52 |
| chakie | yeah, it's a pretty fundamental thing | 07:52 |
| chakie | we do (for some reason I don't know) have a cpio_%.bbappend that contains BBCLASSEXTEND = "nativesdk" | 07:53 |
| chakie | ha! | 07:53 |
| chakie | that of course clobbers the "native" in the actual recipe | 07:53 |
| chakie | yeah... | 07:54 |
| chakie | ffs | 07:54 |
| erbo | Er, right :) | 07:55 |
| erbo | Maybe use BBCLASSEXTEND_append = " nativesdk" instead | 07:55 |
| chakie | Yes. | 07:55 |
| chakie | I never noticed that before | 07:55 |
| chakie | I've cursed at this for a while now. Thank you for guiding me to finding the problem | 07:56 |
| chakie | LeoThe2nd: it got pulled in by the script that builds final images. | 07:57 |
| LetoThe2nd | chakie: :-) glad you found it | 07:58 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 07:58 | |
| chakie | LeoThe2nd: damn ag is fast... | 08:01 |
| LetoThe2nd | chakie: i know. | 08:01 |
| LetoThe2nd | hence the tip :) | 08:01 |
| qschulz | LetoThe2nd: I didn't know about fd, I'll try this one :) | 08:02 |
| chakie | thanks for that too. recursive grep is so slooow | 08:03 |
| LetoThe2nd | qschulz: have fun! | 08:03 |
| qschulz | when you can't install ag (non-root etc..) git grep is already A BIG step forward :) | 08:03 |
| LetoThe2nd | qschulz: "non-root"? what does this mean? :P | 08:05 |
| qschulz | LetoThe2nd: while we're at it. I can't connect over ssh without using mosh now. SO convenient. | 08:11 |
| LetoThe2nd | qschulz: yeah i know about mosh, but i usually just stick to standard ssh-into-shell-with-tmux | 08:11 |
| qschulz | it 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@82.150.214.1> has joined #yocto | 08:13 | |
| LetoThe2nd | maybe need to try it again some time! | 08:13 |
| qschulz | only 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 time | 08:15 |
| *** behanw <behanw!uid110099@gateway/web/irccloud.com/x-nenwfdfuirgvjmtt> has quit IRC | 08:18 | |
| *** mckoan|away is now known as mckoan | 08:18 | |
| chakie | ag did a search through my build directory in 30s while i'm building an image. pretty impressive, considering this is some laptop garbage ssd | 08:18 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 08:19 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 08:19 | |
| LetoThe2nd | chakie: 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@80.214.75.89> has joined #yocto | 08:22 | |
| *** marka <marka!~marka@184.175.21.100> has quit IRC | 08:35 | |
| *** yacar_ <yacar_!~yacar@80.214.75.89> has quit IRC | 08:39 | |
| *** yacar_ <yacar_!~yacar@80.214.75.89> has joined #yocto | 09:07 | |
| RP | nrossi: I thought timezones may be tricky | 09:15 |
| RP | nrossi: it was just to follow up on the email discussion and see how best to move forward | 09:15 |
| *** soderstrom <soderstrom!~soderstro@gateway/shell/xzibition.com/x-zguplajregxmlvcv> has quit IRC | 09:38 | |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 09:39 | |
| nrossi | RP: was just having dinner, you still around? | 09:55 |
| RP | nrossi: yes | 09:56 |
| RP | nrossi: I'm still trying to wake up, caffeine isn't working today :/ | 09:56 |
| nrossi | RP: 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 recipe | 09:57 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 09:58 | |
| nrossi | with the binutils-cross recipe stashing the build directory like gcc-cross/gcc-runtime does | 09:58 |
| RP | nrossi: ok, I think we'll probably need to do that. "target" dependencies cause huge problems for the cross recipes | 10:00 |
| RP | nrossi: I'm relieved the gcc runtime part works! | 10:00 |
| nrossi | RP: 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 |
| RP | nrossi: probably not, no. I think there was a recent patch related to that? | 10:01 |
| nrossi | RP: 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 time | 10:03 |
| RP | nrossi: I'm probably thinking of http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1dc2823d62b253a6f7d05f71426f77925523de49 as there were comments made about plugins at the time too | 10:05 |
| RP | nrossi: I've not heard of a configargs issue before | 10:05 |
| nrossi | RP: interesting... essentially its the value you get when you run gcc -v | 10:06 |
| nrossi | RP: I haven't checked the gcc code itself, but it appears to sanity check that vs what the plugin was built against | 10:06 |
| RP | nrossi: I suspect there are build reproducibility issues in here too | 10:08 |
| nrossi | RP: 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 distro | 10:09 |
| RP | nrossi: yes, sounds like a plan, either target paths, or paths with placeholders for the OE build path | 10:10 |
| nrossi | RP: ok, I will look into getting a patch for that. | 10:11 |
| RP | nrossi: did you understand the issue with the oeqa result logging? | 10:11 |
| RP | nrossi: still not 100% sure I have a good solution to that :/ | 10:11 |
| nrossi | RP: sort of, that was the next questions i have | 10:11 |
| nrossi | RP: 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@80.214.75.89> has quit IRC | 10:12 | |
| RP | nrossi: I've been giving it a bit more thought and realised we do already have some selftests we run on a per machine basis | 10:12 |
| *** iceaway2 <iceaway2!~pelle@37.233.78.69> has joined #yocto | 10:12 | |
| RP | nrossi: here: https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/975/steps/8/logs/step3d | 10:13 |
| nrossi | RP: i did initial mimic the gotoolchain.py testcase... i assume that is one of the selftest cases that are machine dependent? | 10:13 |
| RP | nrossi: we've kind of sleepwalked into this :/ | 10:13 |
| RP | nrossi: the two we run as machine specific are runqemu and meta_ide. You're right and go should be on that list though | 10:14 |
| nrossi | RP: so what stops them from being run in default oe-selftest builder? | 10:16 |
| RP | nrossi: I'm now wondering if we split these into two classes, or mark the tests up somehow or quite what to do | 10:16 |
| RP | nrossi: nothing. As I said, we just kind of accidentally ended up here without thinking | 10:17 |
| RP | nrossi: I'm just realising we need to do something about this rather than a hardcoded list in the autobuilder config | 10:17 |
| nrossi | RP: ok, just making sure im not overlooking big pieces of config :). | 10:18 |
| RP | nrossi: A lot time ago we did talk about "tagging" tests, e.g. "fast" or "slow" or in this case "target" | 10:18 |
| RP | nrossi: Perhaps we should create some decorators for the tests and do that this way? | 10:18 |
| nrossi | RP: that is exactly along the line of what i was thinking | 10:18 |
| RP | nrossi: that would make your tests work as is and just need some extra code to get access to the markup from the commandline | 10:19 |
| nrossi | RP: unfortunately the base unittest in python does not have a test category function. But not hard to implement | 10:19 |
| *** frsc <frsc!~frsc@109.250.133.72> has quit IRC | 10:20 | |
| RP | nrossi: wouldn't be the first time we've had to extend it :/ | 10:21 |
| nrossi | RP: 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 |
| RP | nrossi: yes | 10:23 |
| iceaway2 | I 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 |
| nrossi | RP: 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 them | 10:27 |
| nrossi | iceaway2: only the parts you image specifies generally | 10:28 |
| *** iceaway2 is now known as iceway | 10:28 | |
| *** iceway is now known as iceaway2 | 10:28 | |
| *** iceaway2 is now known as iceaway | 10:29 | |
| RP | nrossi: I thought I'd said the results injection was fine? | 10:29 |
| RP | nrossi: my main thoughts now would be on the namespaces so we can make best use of the current result handling | 10:30 |
| nrossi | RP: by namespaces are you referring to putting the subtest results into a nested results hierarchy of some sort? | 10:32 |
| *** frsc <frsc!~frsc@200116b824f63b0050e9c5fb01d437cf.dip.versatel-1u1.de> has joined #yocto | 10:33 | |
| RP | nrossi: we generate these reports from the results: https://autobuilder.yocto.io/pub/non-release/20190828-6/testresults/testresult-report.txt | 10:34 |
| RP | nrossi: so if for example we injected as a pretend ptest, it would show up in the ptest table | 10:34 |
| RP | nrossi: I'm not sure that is a good or a bad idea, just thinking what makes sense right now | 10:35 |
| RP | nrossi: we could inject that as ptestresult.gcc-cross for example | 10:36 |
| RP | nrossi: when we implement better refgression analysis in resulttool, it would then work for these "for free" | 10:37 |
| nrossi | RP: ok, makes sense, putting them under ptest is fine? not going to cause too much confusion? | 10:37 |
| nrossi | RP: also should it seperate the suites, e.g. "gcc", "g++", "libatomic"... "gas", "ld".... | 10:38 |
| *** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has joined #yocto | 10:38 | |
| nrossi | RP: and if so, should they be just the suite or e.g. "gcc.gcc", "gcc.libatomic" | 10:38 |
| RP | nrossi: I think we want to separate the suites where we can as the results are more meaningful | 10:39 |
| RP | nrossi: it may need to become gcc-libatomic as I'm not sure we support nesting that namespace to sublevels | 10:40 |
| RP | or just libatomic I guess | 10:40 |
| nrossi | RP: 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 |
| nrossi | RP: 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 |
| RP | nrossi: good question, not sure I looked closely at that :/ | 10:44 |
| nrossi | RP: 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 now | 10:46 |
| RP | nrossi: Looks basically good to me. I just don';t like the BUILD_TEST_ namespace | 10:47 |
| nrossi | RP: i think TEST_* is what the testimage class uses, does that make more sense? | 10:48 |
| RP | nrossi: these are used by glibc, gcc, anything else? | 10:48 |
| nrossi | RP: they are just used in the recipe for glibc-testsuite and gcc*. They can be any prefix really | 10:49 |
| RP | nrossi: I'm tempted to suggest TOOLCHAIN_TEST_ | 10:50 |
| RP | nrossi: 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 problems | 10:51 |
| nrossi | RP: ok, will change them to that :). | 10:51 |
| RP | nrossi: running the selftest sstate sigs tests would show that up | 10:51 |
| nrossi | RP: the gcc-common change is needed so that the extracted builddir has the right paths... | 10:52 |
| RP | nrossi: ok, I wondered if that was the case | 10:52 |
| RP | nrossi: we'll need to run the sigs tests, see if they do show issues | 10:53 |
| nrossi | RP: 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@177.41.192.182> has joined #yocto | 10:58 | |
| RP | nrossi: oe-selftest -r sstatetests | 10:59 |
| RP | nrossi: lets see if there is a problem or not | 10:59 |
| *** BobPungartnik <BobPungartnik!~BobPungar@177.41.192.182> has quit IRC | 11:02 | |
| *** weltling <weltling!~toll@klapt.com> has joined #yocto | 11:07 | |
| RP | zeddii: I have the multilib ca-certs issue figured out FWIW, that one isn't kernel | 11:09 |
| chakie | Hm, I rebuilt everything from scratch but still got no u-boot.img or boot.bin images | 11:11 |
| chakie | Have the image names changed since sumo? | 11:11 |
| chakie | In 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.img | 11:15 |
| chakie | Same for boot.bin and others. Now no files with those names. | 11:15 |
| *** yacar_ <yacar_!~yacar@80.214.75.89> has joined #yocto | 11:23 | |
| iceaway | I 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 packages | 11:33 |
| iceaway | that 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@181.220.83.67> has joined #yocto | 11:39 | |
| tgoodwin | Does 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|work | We will take either | 11:43 |
| Crofton|work | preferably in a free format ;) | 11:43 |
| Crofton|work | but we can deal | 11:44 |
| tgoodwin | lol | 11:44 |
| tgoodwin | understood :) | 11:44 |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 11:44 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:46 | |
| chakie | Meh, figuring out where the boot and fs images would come from and why they don't come from there isn't trivial at all | 11:49 |
| tgoodwin | chakie: 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 |
| chakie | zedboard-zynq7 | 11:53 |
| chakie | This 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 bsp | 11:55 |
| chakie | "xilinx" | 11:55 |
| tgoodwin | chakie: 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 |
| mckoan | iceaway: if you are not using GUI I'd switch to Poky distro | 11:57 |
| tgoodwin | chakie: are the boot.bin, etc. in your deploy directory, but not on the SD card (assuming you're using MMC)? | 11:57 |
| chakie | I see "IMAGE_BOOT_FILES += "boot.bin uEnv.txt ${KERNEL_IMAGETYPE}-zynq-zed.dtb"" | 11:57 |
| chakie | goodwin: they are nowhere in my entire tree. | 11:58 |
| chakie | goodwin: 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 deployed | 11:59 |
| tgoodwin | chakie: 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 |
| tgoodwin | Have 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 |
| chakie | Let me see | 12:05 |
| chakie | I looked at "bitbake -e" to see if it referenced "u-boot.img" at all and found: | 12:05 |
| chakie | IMAGE_BOOT_FILES="uImage zImage u-boot.img zynq-zed.dtb boot.bin uEnv.txt uImage-zynq-zed.dtb" | 12:05 |
| chakie | UBOOT_BINARY="u-boot.img" | 12:05 |
| chakie | So the environment "knows" about what it should produce | 12:06 |
| *** Chrusel <Chrusel!c1669b04@193.102.155.4> has joined #yocto | 12:06 | |
| chakie | goodwin: huh, doing "bitbake virtual/boot-bin" started fetching/building u-boot stuff | 12:07 |
| tgoodwin | Sure, but if nothing is depending (RDEPENDS) on the package that provides those files, then they won't be available at runtime. | 12:07 |
| chakie | So something is now broken in out setup | 12:07 |
| chakie | "our" | 12:07 |
| tgoodwin | Did you modify EXTRA_IMAGEDEPENDS at all? | 12:07 |
| tgoodwin | The machine has that defined with "virtual/boot-bin", so once you build an image, it should have also built that package. | 12:08 |
| chakie | sounds logical | 12:08 |
| tgoodwin | (also has virtual/bootloader, FWIW) | 12:09 |
| chakie | There is "EXTRA_IMAGEDEPENDS_remove = "u-boot-zynq-uenv"" | 12:09 |
| chakie | A 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 #yocto | 12:11 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 12:12 | |
| tgoodwin | That 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 |
| chakie | ok, so that's not what makes the real images? | 12:13 |
| tgoodwin | That'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 |
| tgoodwin | If you have a pastebin of your -e output, I would be happy to look at it. | 12:15 |
| chakie | It's 1.4MB | 12:16 |
| chakie | Let me upload it somewhere | 12:18 |
| *** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC | 12:21 | |
| chakie | I have lots to learn about debugging this stuff... | 12:22 |
| iceaway | mckoan: 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 make | 12:23 |
| iceaway | it 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 | |
| zeddii | nice. | 12:24 |
| tgoodwin | chakie: Did you modify the zedboard-zynq7.conf? Your environment says it only adds u-boot-zynq-uenv vs. the other lines I see here: https://github.com/Xilinx/meta-xilinx/blob/warrior/meta-xilinx-bsp/conf/machine/zedboard-zynq7.conf#L22 | 12:25 |
| zeddii | RP: I see your email. A lot of history here, so I'll go from what you have in the email., | 12:26 |
| chakie | goodwin: yes, it has been changed a bit | 12:28 |
| chakie | goodwin: but those extra dependencies have not been removed though. | 12:29 |
| chakie | perhaps something in the xilinx layer has changed that just happened to make us depend on those before. | 12:30 |
| tgoodwin | chakie: alright, well from your log, it's only adding that one recipe to that variable and nothing is attempting to remove anything. | 12:30 |
| tgoodwin | If 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 |
| tgoodwin | BTW if you copied the machine to your new layer (rpd?), you should probably rename it. | 12:32 |
| chakie | I 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 |
| chakie | That is perhaps a wise way to go | 12:33 |
| tgoodwin | I understand. That log is showing that it's pulling in meta-rpd/conf/machine/zedboard-zynq7.conf vs. the meta-xilinx-bsp one | 12:33 |
| chakie | And to actually understand what happens... | 12:33 |
| chakie | goodwin: but you mean that this is never actually executed: EXTRA_IMAGEDEPENDS_remove = "u-boot-zynq-uenv" | 12:35 |
| tgoodwin | Where is it written? | 12:36 |
| chakie | I also saw in that environment that it was only added to | 12:36 |
| tgoodwin | (and no, according to your log it never gets picked up) | 12:36 |
| chakie | it's in the root recipe that we build | 12:36 |
| chakie | a "rpd-base-image.bb" | 12:37 |
| zeddii | ahaha. RP. now I know why I didn't see the eudev build issue. | 12:37 |
| zeddii | ERROR: Nothing PROVIDES 'eudev' | 12:37 |
| zeddii | eudev was skipped: conflicting distro feature 'systemd' (in DISTRO_FEATURES) | 12:37 |
| chakie | It basically inherits core-image, adds some extra packages and removes some unwanted ones | 12:38 |
| tgoodwin | chakie: ah. Well if you ran "bitbake -e rpd-base-image", I would expect to see the _remove show up. | 12:39 |
| tgoodwin | chakie: also, I'm not sure that making changes to that variable in an image definition is really fitting with the intent of that variable: https://www.yoctoproject.org/docs/2.6.2/mega-manual/mega-manual.html#var-EXTRA_IMAGEDEPENDS | 12:41 |
| tgoodwin | It's a list of packages that are not needed for the rootfs (vs. the image defining what goes in the rootfs) | 12:41 |
| zeddii | RP: but yet lttng-ust build here for qemuppc. hmm. I'll dig more. | 12:42 |
| chakie | goodwin: yeah, now I see the remove and it's left empty | 12:42 |
| chakie | From 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't | 12:44 |
| chakie | Which means we build an assload of packages that never get used anywhere. :) | 12:45 |
| *** Chrusel <Chrusel!c1669b04@193.102.155.4> has quit IRC | 12:47 | |
| tgoodwin | chakie: 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 |
| RP | zeddii: that is odd :/ | 12:48 |
| RP | zeddii: note it was the mpc, not qemuppc | 12:48 |
| zeddii | I 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 can | 12:49 |
| * zeddii builds @ home with two servers in his basement, so no corporate build power unfortunately. | 12:50 | |
| chakie | goodwin: 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 years | 12:51 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 12:52 | |
| *** cpo <cpo!~cpo@helix.mybll.net> has quit IRC | 12:52 | |
| zeddii | RP: 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@194.145.151.3> has joined #yocto | 12:53 | |
| RP | zeddii: its possible its some other patch in -next :/ | 12:53 |
| RP | zeddii: it sounds kernel related though | 12:53 |
| RP | zeddii: btw, I think I missed qemumips issues from that email :/ | 12:53 |
| zeddii | agreed. starting with the kernel is the right thing. | 12:53 |
| tgoodwin | hmm. 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 http://git.yoctoproject.org/cgit.cgi/poky/diff/meta/conf/machine/qemuarm.conf?h=master-next&id=e097cdcadc6a6a5afdbd799ce3f9c65b5bacf780 | 12:54 |
| zeddii | bugger. I build qemumips/mips64 for all the images I could think of. | 12:54 |
| kanavin_ | still, as far as | 12:54 |
| tgoodwin | It's that or you'll have to manually build virtual/boot-bin and virtual/bootloader ahead of building your image(s). | 12:54 |
| RP | lib64-packagegroup-core-device-devel-1.0-r1 do_populate_lic - 2h53m1s (pid 8842) | 12:54 |
| RP | that sounds wrong | 12:54 |
| tgoodwin | (so that the files will exist in the deploydir) | 12:54 |
| zeddii | RP: 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 |
| chakie | goodwin: yeah, I added them to EXTRA_IMAGEDEPENDS and building right now | 12:55 |
| zeddii | s/eee/see/ | 12: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 explicitly | 12:55 |
| kanavin_ | yeah, maybe the missing drm-bochs bit also plays a role | 12:55 |
| zeddii | I'll deal with the root cause of me dropping that, once we are green with 5.2. | 12:55 |
| RP | zeddii: ok, are you going to send some more patches and we can retest? | 12:56 |
| chakie | goodwin: ok, now I got all the image files except a uImage-zynq-zed.dtb | 12:56 |
| zeddii | RP: yes. do you want new versions or follow on patches. I can easily do either flow. | 12:56 |
| *** yacar_ <yacar_!~yacar@80.214.75.89> has quit IRC | 12:56 | |
| RP | zeddii: may as well do follow on and let me know if anything should be squashed | 12:57 |
| RP | zeddii: I have Kevin's BSP uprev to add in the next round which may help mpc | 12:57 |
| *** nabokov <nabokov!~armand@67.218.223.154> has joined #yocto | 12:57 | |
| tgoodwin | chakie: 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 machine-xilinx-default.inc according to your env file). | 12:59 |
| tgoodwin | chakie: Do you have a package that installs uImage-zynq-zed.dtb to the deploydir? | 13:00 |
| zeddii | RP: 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 well | 13:01 | |
| *** jeanba <jeanba!~jbl@77.243.63.34> has joined #yocto | 13:01 | |
| *** jeanba <jeanba!~jbl@77.243.63.34> has left #yocto | 13:02 | |
| chakie | goodwin: to build/tmp/deploy/images/zedboard-zynq7? | 13:02 |
| tgoodwin | chakie: 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 |
| tgoodwin | chakie: 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 |
| jwessel | RP: I tracked down the getty fast fail problem. systemd is ever changing... | 13:05 |
| jwessel | It only happened on a first boot. | 13:05 |
| zeddii | love those kind of ones. means constantly copying images or rebuilding new ones. | 13:05 |
| jwessel | And even then, not all the time, as it is a udev/systemd race. | 13:05 |
| RP | jwessel: ah. Glad we're not imagining it then :) | 13:05 |
| jwessel | That is why I copied the image the one time I saw it. | 13:06 |
| chakie | goodwin: our scripts that grab the built files seem to expect that dtb file. | 13:06 |
| RP | zeddii: qemu can do COW | 13:06 |
| jwessel | I figured it must be something super odd. | 13:06 |
| RP | jwessel: runqemu should only ever work off a copy and hence be a first boot | 13:06 |
| jwessel | I am reading the latest systemd foo in order to figure out a different way to use it, hopefully without patching the code. | 13:06 |
| RP | jwessel: hence the 100% autobuilder hit | 13:06 |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 13:06 | |
| neverpanic | ~. | 13:07 |
| jwessel | But runqemu makes a copy only the first time. Statistically autobuilder was going to hit it more often because of that. | 13:07 |
| jwessel | second boot, as far as I can tell never will hit it, because udev is running much earlier. | 13:07 |
| jwessel | In the systemd in thud, it was fine to use the BindsTo=... | 13:10 |
| jwessel | Now it has to work like this: | 13:10 |
| jwessel | PartOf=dev-%i.device | 13:10 |
| jwessel | ConditionPathExists=/dev/%i | 13:10 |
| jwessel | After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service | 13:10 |
| jwessel | So for the ttyUSB0 transient device case we get: | 13:10 |
| jwessel | Aug 29 13:09:05 qemux86-64 systemd[1]: Condition check resulted in Serial Getty on ttyUSB0 being skipped. | 13:10 |
| nrossi | chakie: tgoodwin: zynq-zed.dtb is the proper name for the dtb, uImage-...dtb is no longer produced by the kernel see (http://git.openembedded.org/openembedded-core/commit/?id=1860d9d3c62e2e94cd68a809385873ffd8270b6d) | 13:12 |
| jwessel | At least we didn't have to patch systemd... | 13:12 |
| tgoodwin | chakie: 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 |
| tgoodwin | nrossi: beat me to it. | 13:13 |
| tgoodwin | thanks ;) | 13:13 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 13:14 | |
| tgoodwin | chakie: 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 |
| tgoodwin | https://github.com/Xilinx/meta-xilinx/commit/f20fc414f30803c126bea4222d9fb2bb73c2b07f#diff-ac06f14aea5b3b57632e015f5cd3821e | 13:16 |
| chakie | goodwin: aha, our scripts expected the image type to be prefixed. | 13:16 |
| chakie | No worries there, easy fix as zynq-zed.dtb is generated just fine. | 13:17 |
| tgoodwin | chakie: yeah, at least we've identified you don't have some other package providing that other name :) | 13:17 |
| yocti | New news from stackoverflow: updating nodejs on linux (yocto) using npm <https://stackoverflow.com/questions/57710749/updating-nodejs-on-linux-yocto-using-npm> | 13:17 |
| chakie | goodwin: no, but we do have a small mess that has seen some bit rot :) | 13:20 |
| chakie | goodwin: I would never have figured this out without your help... Thank you so much! | 13:22 |
| tgoodwin | chakie: you're welcome :) | 13:25 |
| *** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC | 13:27 | |
| *** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto | 13:27 | |
| *** stefandxm <stefandxm!~stefan@deusexmachinae.se> has quit IRC | 13:29 | |
| *** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC | 13:30 | |
| *** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has quit IRC | 13:31 | |
| *** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto | 13:33 | |
| RP | JPEW: reproducibility tests ran on the autobuilder, it wasn't so good :/ | 13:38 |
| RP | JPEW: https://paste.debian.net/1097867/ | 13:38 |
| RP | JPEW: I might have found the ca-certs one | 13:39 |
| JPEW | RP: Yep, those look like the usual suspects | 13:49 |
| JPEW | Well, except for the kernel module | 13:49 |
| *** marka <marka!~marka@184.175.21.100> has joined #yocto | 13:51 | |
| mckoan | iceaway: yes, you are right | 13:51 |
| zeddii | RP: gah. on my builder the ppc neard issues doesn't show up. that's two now that I can't reproduce. | 13:52 |
| zeddii | I was using musl in that config. but really, that should hurt, not help. | 13:52 |
| zeddii | TARGET_SYS = "powerpc-poky-linux-musl" | 13:53 |
| zeddii | MACHINE = "mpc8315e-rdb" | 13:53 |
| zeddii | DISTRO = "poky" | 13:53 |
| zeddii | aaaaaand eudev just built for the mpc as well. | 13:53 |
| *** tsjsieb <tsjsieb!~quassel@103.214.7.25> has joined #yocto | 13:54 | |
| RP | zeddii: could be a musl vs glibc difference? :/ | 13:54 |
| RP | JPEW: so they're known issues? | 13:55 |
| zeddii | I just switched to glibc and started again. I'll know soon. | 13:55 |
| *** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-egukgjvugvrilfbf> has quit IRC | 13:55 | |
| *** kaspter <kaspter!~Instantbi@183.128.184.135> has quit IRC | 13:55 | |
| JPEW | RP: 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 |
| jwessel | RP, thanks for the information from the autobuilder. | 13:58 |
| jwessel | I sent a new v2 of the getty fast-fail patch, which is tested specifically against u-dev race that was found. | 13:58 |
| JPEW | RP: The doc ones are almost certainly because of pod2man in HOSTTOOLS | 13:59 |
| jwessel | I 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/matrix.org/x-zccymghjpfkhfkal> has joined #yocto | 14:01 | |
| JPEW | RP: 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@128.224.252.2> has quit IRC | 14:03 | |
| *** bisbarn <bisbarn!~bisbarn@p5DF59D90.dip0.t-ipconnect.de> has joined #yocto | 14:07 | |
| *** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has joined #yocto | 14:09 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 14:09 | |
| yates | this is my swupdate-image.bb file: https://paste.fedoraproject.org/paste/f7mqdGibVsaBCWGXwFmyIQ | 14:10 |
| yates | what is the "bb.utils.contains" function on line 13? | 14:10 |
| qschulz | if SWUPDATE_INIT contains tiny then initscripts-swupdate else initscripts sysvinit | 14:12 |
| *** sgw <sgw!~sgw@134.134.139.75> has quit IRC | 14:12 | |
| qschulz | https://github.com/openembedded/bitbake/blob/master/lib/bb/utils.py#L963 | 14:13 |
| khem | zeddii: meta-openembedded also shows some failures with 5.2 headers see https://errors.yoctoproject.org/Errors/Build/87788/ | 14:13 |
| khem | klibc linux-atm can-util qtserialbus qtwebengine | 14:14 |
| zeddii | khem: 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 |
| khem | error: use of undeclared identifier 'MAP_PRIVATE' | 14:15 |
| zeddii | RP: I can reproduce none of the autobuilder failures. | 14:15 |
| zeddii | I just built lttng-ust, neard and eudev for the fsl_mpc | 14:15 |
| khem | is MAP_PRIVATE gone ? | 14:15 |
| zeddii | it may have moved. /me goes to check. | 14:16 |
| yates | ha ha. /me | 14:16 |
| khem | other issue is error: use of undeclared identifier 'SIOCGSTAMP' which is trivial to fix | 14:16 |
| yates | qschulz: thanks! | 14:16 |
| zeddii | yah. that was was littered in a few packages. | 14:17 |
| zeddii | I just have NFI how I can be building the packages fine that the autobuilder couldnt | 14:18 |
| yates | no financial information? | 14:18 |
| RP | zeddii: not good :( | 14:19 |
| zeddii | I'm switching to your master-next with none of my local changes and will try that. | 14:19 |
| zeddii | I'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@192.198.146.173> has joined #yocto | 14:22 | |
| khem | zeddii:btw. musl version in oe-core does have 5.2 fixes so it is possible that something will build with musl but not glibc | 14:22 |
| *** chinhuat6 <chinhuat6!~chinhuat@192.198.146.171> has quit IRC | 14:23 | |
| *** stephano <stephano!~stephano@134.134.139.83> has joined #yocto | 14:24 | |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 14:25 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 14:25 | |
| *** Crofton|mini <Crofton|mini!~Crofton@2601:5c0:c100:b84:3d3f:64d6:2ba1:780b> has quit IRC | 14:28 | |
| *** sgw <sgw!~sgw@134.134.139.76> has joined #yocto | 14:31 | |
| *** yacar_ <yacar_!~yacar@80.215.174.21> has joined #yocto | 14:33 | |
| bisbarn | Goodday, 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 inherits | 14:35 |
| bisbarn | from devicetree. Within this recipe I build the base devicetree and all the overlays (I can overrite DTC_FLAGS which is used by devicetree.bb). I was wondering if there might be a better solution to that problem ;) | 14:35 |
| bisbarn | A soluition that would work with KERNEL_DEVICETREE | 14:36 |
| __angelo | hi :) have an image with a DEPENDS += "another_image" but seems the build of "another_image" is not triggered | 14:38 |
| *** learningc <learningc!~learningc@121.122.92.156> has joined #yocto | 14:42 | |
| ykrons | Hi all, I'm trying to build a node.js package with Yocto (rocko) according to https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM. 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@80.215.174.21> has quit IRC | 14:45 | |
| qschulz | bisbarn: when I manually compiled the kernel for DT overlays, I made those two patches: https://github.com/QSchulz/linux-at91/commit/deff47fd469863f301b452a6c853fb803af7170d https://github.com/QSchulz/linux-at91/commit/c1ddbd31090bc8d82d5df38af2a12e8c053bb01f | 14:49 |
| qschulz | maybe you can apply those to your kernel | 14:49 |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 14:51 | |
| qschulz | __angelo: here we have do_rootfs[depends] += "foo-image:do_build" | 14:52 |
| __angelo | qschulz, oh thanks | 14:53 |
| bisbarn | qschulz: 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 |
| qschulz | Honestly I don't know, they have changed already a few times the format of device trees,nothing's fixed yet AFAIR | 14:54 |
| qschulz | might not even be -@ anymore | 14:54 |
| bisbarn | well atleast with 4.9.13 it still is ;) | 14:55 |
| qschulz | and you need dtc > 1.14 from what I recall, directly in the kernel sources | 14:55 |
| bisbarn | yeah | 14:55 |
| bisbarn | but I guess 4.9.13 should come with dtc 1.14 ;) | 14:56 |
| *** Bunio_FH <Bunio_FH!~bunio@84.red-213-0-2.staticip.rima-tde.net> has joined #yocto | 14:56 | |
| mckoan | __angelo: of course a dependency from an image can make sense only as runtime so it should be a kind of RDEPENDS | 14:56 |
| qschulz | well, the patch I sent you is for 4.9 (I don't know the dot) | 14:57 |
| qschulz | mckoan: it's a bit trickier I think. There is a task dependency behind DEPENDS and RDEPENDS | 14:58 |
| qschulz | image recipes are different and i honstely don't know if they have those tasks or if something is done in there | 14:58 |
| qschulz | so one task depends on a task which is empty or never executed or so, basically a no-op | 14:59 |
| qschulz | e.g. https://www.yoctoproject.org/docs/2.6.3/ref-manual/ref-manual.html#var-RDEPENDS: 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@80.215.174.21> has joined #yocto | 15:01 | |
| qschulz | bisbarn: FYI, only since 4.11 | 15:08 |
| __angelo | mckoan, tested also RDEPENDS, not working for mw | 15:09 |
| *** frsc <frsc!~frsc@200116b824f63b0050e9c5fb01d437cf.dip.versatel-1u1.de> has quit IRC | 15:09 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 15:10 | |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 15:12 | |
| __angelo | qschulz, oh, seems do_rootfs[depends] is also not working. Shoudl i cleanall ? | 15:19 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:24 | |
| armpit | YP bug triage over | 15:24 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 15:25 | |
| *** florian__ is now known as florian | 15:29 | |
| nrossi | RP: no sstatetests failures with the gcc-common change | 15:31 |
| RP | nrossi: ok, great. I'm surprised but that is good | 15:31 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 15:31 | |
| JPEW | RP: Sent clean build patch for reproducible OEQA test | 15:31 |
| RP | JPEW: thanks, I'll rerun it with that | 15:31 |
| nrossi | RP: 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 tests | 15:32 |
| nrossi | RP: the runner filters cases that match the tag | 15:33 |
| mckoan | __angelo: of course, I didn't say to use RDEPENDS | 15:33 |
| zeddii | RP: I just can't break any of the packages that blew up for you. | 15:33 |
| RP | nrossi: oh. Do we use that anywhere? Could we add a match option I wonder? | 15:34 |
| nrossi | RP: it did not appear anywhere in oe-core/meta. So it could just be reversed | 15:34 |
| mckoan | __angelo: AFAIK is not possble to depend on an image though | 15:35 |
| zeddii | https://pastebin.com/v7Zesf6r | 15:35 |
| RP | nrossi: very tempted to do that... | 15:35 |
| nrossi | RP: i will look at doing that then, see if it can work. anyways I am off to bed, will likely have updates for you tomorrow | 15:38 |
| RP | nrossi: thanks, sleep well! | 15:40 |
| *** yacar_ <yacar_!~yacar@80.215.174.21> has quit IRC | 15:49 | |
| __angelo | mckoan, ooh, so it is not possible to trigger another image from the current ? | 15:54 |
| __angelo | ok :( | 15:55 |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 15:58 | |
| zeddii | heh. 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 build | 16:01 |
| kanavin_ | I wonder if we can apply pressure for them to get on with it somehow | 16:02 |
| yocti | New news from stackoverflow: YOCTO : Where can I find my Linux kernel source directory? <https://stackoverflow.com/questions/57713797/yocto-where-can-i-find-my-linux-kernel-source-directory> | 16:18 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:31 | |
| RP | kanavin_: I think people like Tartarus are already working on that | 16:34 |
| Tartarus | kanavin_: Ahem, patches welcome. | 16:35 |
| Tartarus | It's not that we're unaware of the deadline, it's that no one has volunteered to help move things along. | 16:35 |
| armpit | same old story for all of use | 16:36 |
| Tartarus | Indeed. | 16:36 |
| *** mckoan is now known as mckoan|away | 16:37 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:47 | |
| *** rewitt <rewitt!rewitt@nat/intel/x-ijppdrbivtugiyqy> has joined #yocto | 16:47 | |
| *** scottrif <scottrif!~scottrif@71-80-205-53.dhcp.mdfd.or.charter.com> has joined #yocto | 16:55 | |
| scottrif | Hi - 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 think | 16:56 |
| armpit | yep | 16:56 |
| kanavin_ | and active in oe-core | 16:56 |
| kanavin_ | bruce.ashfield@gmail.com | 16:56 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 17:01 | |
| *** Bunio_FH <Bunio_FH!~bunio@84.red-213-0-2.staticip.rima-tde.net> has quit IRC | 17:01 | |
| aehs29 | khem: 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@121.122.92.156> has quit IRC | 17:04 | |
| *** learningc <learningc!~learningc@121.122.92.156> has joined #yocto | 17:04 | |
| scottrif | Thanks! | 17:06 |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 17:06 | |
| Tartarus | kanavin_, 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 |
| Tartarus | Or 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 horrors | 17:08 |
| *** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has quit IRC | 17:10 | |
| kanavin_ | Tartarus, the way I am doing it is by mv /usr/bin/python2.7 /usr/bin/python2.7.bogus | 17:10 |
| kanavin_ | and patching out python2 from HOSTTOOLS in bitbake.conf | 17:10 |
| Tartarus | What's your starting host? | 17:11 |
| khem | aehs29: how does it break ? maybe carry the discussion on ml ? | 17:11 |
| kanavin_ | Tartarus, ubuntu 18.04 | 17:11 |
| Tartarus | OK | 17:11 |
| Tartarus | thanks | 17:11 |
| kanavin_ | then you need to adjust the recipe to not require python-native | 17:11 |
| Tartarus | Well, I'm going to be trying to do things in U-Boot itself, just need an env | 17: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 guess | 17:12 |
| Tartarus | I know libfdt stuff is going to crap out, which is annoying | 17:12 |
| Tartarus | but I think, aside from genboardscfg.py (which 2to3 + stack overflow got me converting) it might be otherwise "just" changing python2 to python3 in some places | 17:13 |
| kanavin_ | Tartarus, I tried PYTHON2=python3, and libfdt was happy with that, but then somewhere else failed | 17:13 |
| Tartarus | Oh? Hmm | 17:13 |
| Tartarus | I'll see what I see soon then, thanks | 17:13 |
| kanavin_ | because #!/usr/bin/python | 17:13 |
| aehs29 | khem: shouldve checked the ML before my bad | 17:13 |
| kanavin_ | at that point I gave up | 17:13 |
| aehs29 | khem: its actually a different error, but let me check the latest patch, if its still breaking I'll reply to the ML thread | 17:14 |
| *** fullstop <fullstop!~fullstop@162.243.42.48> has joined #yocto | 17:33 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-mjppmdfpmpjwiwen> has quit IRC | 17:38 | |
| *** rewitt <rewitt!rewitt@nat/intel/x-ijppdrbivtugiyqy> has quit IRC | 17:41 | |
| *** rewitt <rewitt!~rewitt@134.134.139.74> has joined #yocto | 17: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 |
| qschulz | have 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 #yocto | 17:59 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 18:08 | |
| __angelo | qschulz, oh thanks. Yes, images works | 18:19 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 18:20 | |
| __angelo | qschulz, well, if it happens you have a code sample, even similar, would be nice | 18:20 |
| *** behanw <behanw!uid110099@gateway/web/irccloud.com/x-yfcfahcpgfajeakm> has joined #yocto | 18:31 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 18:35 | |
| *** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has joined #yocto | 18:40 | |
| *** JPEWhacker <JPEWhacker!~yaaic@2600:100a:b00d:8230:d5c9:f019:2a6:1e43> has joined #yocto | 18:51 | |
| *** JPEWhacker <JPEWhacker!~yaaic@2600:100a:b00d:8230:d5c9:f019:2a6:1e43> has quit IRC | 19:00 | |
| *** JPEWhacker <JPEWhacker!~yaaic@2605:a601:21d1:5200:8cdb:3150:46e2:5a1f> has joined #yocto | 19:00 | |
| zeddii | RP: 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 |
| zeddii | I'm only working a 1/2 day tomorrow, which means mid next week before any significant process can be guaranteed. | 19:02 |
| zeddii | I'd suggest just dropping the whole thing from master-next, and I can resubmit when / if I can reproduce the failures. | 19:02 |
| LetoThe2nd | zeddii: does it mean significant beer && metal? :P | 19:03 |
| zeddii | :D beer at least. | 19:03 |
| LetoThe2nd | \m/ | 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 moment | 19:04 | |
| * zeddii bets he'll get 'ping' email on it tomorrow and will have to not type any hasty responses ;) | 19:04 | |
| LetoThe2nd | exactly 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 |
| zeddii | this is why we all head to conferences to commiserate and do more beer :D | 19:07 |
| *** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has joined #yocto | 19:07 | |
| LetoThe2nd | \m/ | 19:08 |
| LetoThe2nd | you @ ELCE? | 19:08 |
| zeddii | I am | 19:08 |
| LetoThe2nd | nice. so yay for beer. | 19:08 |
| zeddii | most definitely. | 19:08 |
| LetoThe2nd | i 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!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has joined #yocto | 19:10 | |
| fullstop | any 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 |
| JPEWhacker | fullstop: are you using multiconfig? | 19:17 |
| fullstop | considering that I don't know what that is, doubtful. | 19:18 |
| fullstop | I'm coming from buildroot, so this is all very foreign at the moment. | 19:18 |
| JPEWhacker | fullstop: ah. you can try removing unnecessary layers. | 19:19 |
| LetoThe2nd | fullstop: take out layers, get ssd, get ram, get fast cpu. in that order, probably. | 19:19 |
| fullstop | dang, I've already done that. | 19:20 |
| fullstop | well, removed layers. it's a ssd and fast cpu already. | 19:20 |
| LetoThe2nd | then 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 |
| fullstop | I don't have all of these resources available to me, but I've got 96GB of memory and a 24 core X5670.. | 19:21 |
| fullstop | anyway, I guess I'll live with it for now. | 19:21 |
| JPEWhacker | does everyone have double digits CPU cores? I feel left out | 19:24 |
| fullstop | this is a server if it makes you feel any better | 19:24 |
| LetoThe2nd | fullstop: aw, i was sooo convinced it is your tablet :/ | 19:25 |
| fullstop | It wouldn't surprise me if the next generation of snapdragon cpus steps into double digits. | 19:26 |
| LetoThe2nd | hrhr. and with that, I'll call it a day. | 19:27 |
| Tartarus | OK, 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 do | 19:37 |
| Tartarus | something. | 19:37 |
| Tartarus | There'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 out | 19:37 |
| yann | there seems to be a known issue with psplash images being shipped as C code without the png source (see http://lists.openembedded.org/pipermail/openembedded-devel/2010-August/144301.html and https://github.com/AsteroidOS/meta-asteroid/blob/master/recipes-core/psplash/psplash_git.bbappend) | 19:38 |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 19:39 | |
| yann | appart 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 |
| yates | i'm confused about the INITRAMFS_IMAGE used in local.conf | 19:39 |
| yates | the 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 |
| yates | so for example, would setting INITRAMFS_IMAGE "abc" cause an actual .bb file to be generated, abc.bb? | 19:41 |
| yates | "...in an initramfs image named core-image-sato-initramfs.bb to be created" | 19:42 |
| yates | mine is set to 'INITRAMFS_IMAGE = "swupdate-image"' | 19:43 |
| yates | which i thought was running the swupdate-image.bb file /sources/meta-swupdate/recipes-extended/images/swupdate-image.bb | 19:43 |
| yates | is that not the case? | 19:45 |
| yates | the link local.conf.sample.extended referenced in this glossary entry is dead | 19:49 |
| yates | https://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html | 19:49 |
| yates | hello? | 19:50 |
| yates | is this thing on? | 19:50 |
| yates | as 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 script | 19:53 |
| *** nabokov <nabokov!~armand@67.218.223.154> has quit IRC | 19:54 | |
| *** Bunio_FH <Bunio_FH!~bunio@84.red-213-0-2.staticip.rima-tde.net> has joined #yocto | 19:54 | |
| *** JPEWhacker <JPEWhacker!~yaaic@2605:a601:21d1:5200:8cdb:3150:46e2:5a1f> has quit IRC | 19:55 | |
| yates | stumped you all? ha! | 19:56 |
| *** JPEWhacker <JPEWhacker!~yaaic@2600:100a:b00d:8230:d5c9:f019:2a6:1e43> has joined #yocto | 19:57 | |
| *** JPEWhacker <JPEWhacker!~yaaic@2600:100a:b00d:8230:d5c9:f019:2a6:1e43> has quit IRC | 20:01 | |
| yates | heck with linux. anyone up for some spectral esimation using minimum relative entropy? | 20:02 |
| yates | estimation | 20:02 |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 20:04 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 20:05 | |
| *** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has quit IRC | 20:06 | |
| kergoth | pretty sure there's a different variable for bundling the initramfs image into the kernel rather than just producing the image binary | 20:09 |
| kergoth | don't recall the name offhand. INITRAMFS something or other | 20:09 |
| yates | INITRAMFS_IMAGE? | 20:09 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 20:10 | |
| khem | kergoth:INITRAMFS_IMAGE_BUNDLE | 20:12 |
| kergoth | that's the one, thanks | 20:12 |
| khem | and you need to define initramfs image with INITRAMFS_IMAGE | 20:13 |
| kergoth | INITRAMFS_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 initrd | 20:13 |
| * kergoth shrugs | 20:13 | |
| khem | hmm | 20:13 |
| khem | bootloader just knows about kernel so that remains consistent weather you use initramfs or not | 20:14 |
| yates | as i understand it, modern kernel's ALWAYS create a ram-disk-based rootfs initially: https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt | 20:14 |
| yates | s/kernel's/kernels/ | 20:14 |
| khem | kernel can then bundle an image into itself and boot into it | 20:14 |
| khem | which can then pivot into full user space rootfs | 20:15 |
| khem | kergoth:grub I think can specify external initrd but to me initramfs in kernel seems better approach | 20:16 |
| yates | this is all known. my question is how to customize the rootfs that is bundled into the kernel | 20:17 |
| yates | like i said, i want to add my own init.d script | 20:17 |
| kergoth | khem: agreed | 20:17 |
| kergoth | it's just another image recipe from bitbake's perspetive, yates. specify your own image, done | 20:17 |
| kergoth | but 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 not | 20:18 |
| kergoth | last time i looked wic didn't handle it at all | 20:18 |
| yates | wic? | 20:18 |
| yates | yes, it works. i've already built it. | 20:18 |
| yates | but i built a non-customized rootfs | 20:19 |
| yates | i have my INITRAMFS_IMAGE_BUNDLE = "1" | 20:19 |
| yates | i have my INITRAMFS_IMAGE = "swupdate-image" | 20:19 |
| kergoth | so copy swupdate-image.bb to your own image file and change INITRAMFS_IMAGE to match, and modify it as you would any other image in oe | 20:20 |
| yates | makes sense. right. | 20:24 |
| yates | the existing oe swupdate-image.bb, https://paste.fedoraproject.org/paste/TVvTGPH46ThER9LU6qXsGQ, ... | 20:38 |
| yates | contains a line ${@bb.utils.contains('SWUPDATE_INIT', 'tiny', 'initscripts-swupdate', 'initscripts sysvinit', d)} | 20:38 |
| yates | which currently fails loades 'initscripts sysvinit'. | 20:39 |
| yates | if i just define SWUPDATE_INIT='tiny', then couldn't i j use the oe swupdate-image and put in my own initscripts? | 20:40 |
| yates | via initscripts-swupdate.bb? | 20:40 |
| yates | no, nm | 20:40 |
| yates | that .bb already exists. | 20:41 |
| yates | i'm trying to optimize yocto - bad idea... | 20:41 |
| yates | just copy the damn swupdate-image.bb... | 20:41 |
| yates | new (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 |
| kergoth | the 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 |
| yates | ok, thanks kergoth | 21:04 |
| yates | i'm not sure i'm grokking all that, but thanks.. | 21:04 |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 21:15 | |
| *** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC | 21:18 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21:31 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 21:48 | |
| *** lfa_ <lfa_!~lfa@217.19.35.51> has joined #yocto | 22:02 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 22:02 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 22:03 | |
| *** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 22:05 | |
| RP | zeddii: any patches for me to put into a new build? | 22:20 |
| RP | Tartarus: sounds like good progress, thanks! | 22:20 |
| RP | Tartarus: I wish I wasn't drowning in release problems or I'd offer to help :/ | 22:20 |
| Tartarus | RP, I appreciate the senitment, thanks. We'll get this sorted before Jan 1 at least I'm pretty sure :) | 22:21 |
| RP | Tartarus: 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/OE | 22:22 |
| khem | RP: zeddii said to revert them until mid next week IIRC | 22:22 |
| RP | khem: thanks, I'd missed that | 22:23 |
| Tartarus | Will do | 22:24 |
| khem | I 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 perl | 22:24 |
| zeddii | RP: yah. I can reproduce exactly zero of the failures here. | 22:25 |
| zeddii | so I'm pretty much screwed on userspace fixes. | 22:25 |
| zeddii | there's minor changes I'll send tomorrow, but I'm simply not able to do anything with the rest. | 22:25 |
| zeddii | which doesn't surprise me, since I build all those configs before ever sending the series. | 22:26 |
| RP | JPEW: reproducible.ReproducibleTests.test_reproducible_builds: PASSED (7227.98s) | 22:26 |
| RP | JPEW: how curious | 22:26 |
| RP | zeddii: you even tried master-next directly? | 22:26 |
| zeddii | yup | 22:26 |
| RP | zeddii: this is very weird :/ | 22:26 |
| zeddii | cleanall on neard lttng-ust eudev -> bitbake. no issues. | 22:27 |
| khem | whats the issue with neard | 22:27 |
| zeddii | I have to bolt, have to get supper for the kids. | 22:28 |
| RP | khem: on the mpc machine, neard, eudev and lttnf-ust all failed | 22:28 |
| RP | khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/70/builds/976 and https://autobuilder.yoctoproject.org/typhoon/#/builders/70/builds/977 | 22:28 |
| zeddii | RP: 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 |
| RP | zeddii: I reran the build, same errors | 22:28 |
| RP | zeddii: right, ok. I'll switch to hitting other stuff and defer M3 further | 22:29 |
| zeddii | I'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 |
| RP | zeddii: can I try and keep the python2 bits? | 22:29 |
| zeddii | those should be fine. | 22:30 |
| zeddii | RP: 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 |
| zeddii | like 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 |
| RP | zeddii: I believe you! | 22:31 |
| zeddii | all I did was watch builds today. | 22:31 |
| RP | zeddii: there is something we're missing :/ | 22:31 |
| RP | its as if the configs don't match somehow | 22:31 |
| zeddii | I'll keep trying. I won't resend without some explanation :D | 22:32 |
| RP | zeddii: I guess meanwhile I should see if I can reproduce locally | 22:32 |
| zeddii | they actually aren't hard to fix. most upstreams have patches avaialble (or debian/gentoo) | 22:32 |
| zeddii | I just need to see it, google it, import and fix. but I'm failing at step #1 | 22:33 |
| RP | zeddii: right. I was just thinking it would be good to see if someone else can reproduce or not | 22:33 |
| zeddii | RP: 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 |
| RP | zeddii: right, I just stripped his patch out of -next | 22:34 |
| zeddii | RP: I don't doubt something funky is going on. I *had* a ppc build error in August. and it was *nasty* | 22:34 |
| RP | zeddii: FWIW beaglebone had WARNINGS: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/990/steps/8/logs/warnings | 22:34 |
| zeddii | it has to do with the gcd "fixincludes" | 22:34 |
| zeddii | gcc fixincludes that is. | 22:34 |
| zeddii | gcc fixes up the new uapi headers and breaks ppc | 22:35 |
| zeddii | I couldn't figure out how to disable it. | 22:35 |
| zeddii | and then the errors "went away" | 22:35 |
| RP | hmm :/ | 22:35 |
| RP | it could definitely be related to that | 22:35 |
| zeddii | I even logged my flailing. | 22:36 |
| zeddii | check this out: | 22:36 |
| zeddii | https://pastebin.com/r1Tzjt4w | 22:36 |
| zeddii | if you got rid of the fixincludes variant, it built again. | 22:36 |
| zeddii | but I can't see how my flailing fixed it permantely .. but I'm beginning to wonder :D | 22:37 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 22:37 | |
| zeddii | as usual I'll update on the mailing list if I sort anything more out. | 22:38 |
| RP | zeddii: 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 morning | 22:38 |
| RP | zeddii: it spent most of today chewing on the multilib issue I mentioned in the email | 22:38 |
| zeddii | hopefully my breadcrumb might come in handy. | 22:38 |
| RP | I figured that was the one you were least likely to look at | 22:38 |
| zeddii | yah. that saved me having a real panic attack today. | 22:39 |
| RP | zeddii: that one depended on order of files on the disk | 22:39 |
| khem | RP: are we including sys/socket.h in failing files ? | 22:39 |
| khem | if not then that could be the issue | 22:39 |
| *** robbawebba <robbawebba!~rob@47.180.176.91> has quit IRC | 22:39 | |
| RP | khem: not sure. I did wonder | 22:40 |
| RP | khem: I've not really looked. zeddii wanted to reproduce them first | 22:40 |
| khem | does it happen on qemuppc too ? | 22:40 |
| RP | khem: no | 22:40 |
| RP | khem: but it did happen with qemuppc-lsb | 22:41 |
| khem | whats the difference | 22:41 |
| RP | zeddii: which kernel version were you looking at? | 22:41 |
| RP | khem: kernel version | 22:41 |
| khem | oh so for qemuppc its not bumped to 5.2 ? | 22:41 |
| zeddii | 5.2 | 22:42 |
| zeddii | and also 5.3 and 4.19 in my builds. | 22:42 |
| zeddii | hmm. or maybe not 4.19 for ppc. I wonder if that's what it was. | 22:42 |
| RP | Its odd that it happened for qemuppc-lsb (4.19) but not qemuppc (5.2) and yet mpc8315e-rdb (5.2) failed | 22:43 |
| khem | RP: its related to kernel-headers mostly | 22:44 |
| * RP should check the logs to confirm numbers | 22:44 | |
| RP | khem: all should be on latest 5.2 kernel headers | 22:44 |
| khem | so you should check linux-libc-headers | 22:44 |
| RP | I wonder if host headers leak through? | 22:44 |
| khem | highly unlikely | 22:45 |
| RP | zeddii: qemuppc which worked is still using 5.0 kernel | 22:45 |
| khem | RP:for kernel headers too ? | 22:46 |
| RP | zeddii: so 5.2 kernel headers + 5.0 kernel is working | 22:46 |
| RP | (for qemuppc) | 22:46 |
| RP | it gets stranger, same versions in the lsb build failed | 22:47 |
| khem | where do I find qemuppc-lsb definition | 22:52 |
| RP | khem: its basically DISTRO="poky-lsb" instead of DISTRO = "poky" | 22:52 |
| RP | khem: now poky-altcfg | 22:53 |
| khem | i c | 22:53 |
| RP | khem: config is always in the stdio log, exactly what goes into auto.conf and local.conf is unmodified from default | 22:53 |
| khem | so it basically use 4.19 kernel for altcfg thats the only relevant change I see | 22:55 |
| khem | zeddii:did it work with musl ? | 22:56 |
| khem | RP:to me it looks more like glibc and linux-libc-headers problem | 22:57 |
| *** stephano <stephano!~stephano@134.134.139.83> has quit IRC | 22:58 | |
| RP | khem: except its not using 4.19 in the logs :/ | 22:58 |
| RP | khem: I'm not convinced its deterministic | 23:00 |
| * RP -> sleep. Will email if I get anywhere tomorrow | 23:00 | |
| khem | RP: meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend:LINUX_VERSION_mpc8315e-rdb = "4.19.34" | 23:08 |
| khem | so I guess lsb and mpc8315e-rdb are using same 4.19 kernel | 23:08 |
| khem | well no | 23:09 |
| khem | dont we need meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend as well ? | 23:10 |
| *** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has joined #yocto | 23:37 | |
| *** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto | 23:51 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!