**** BEGIN LOGGING AT Fri Oct 25 03:00:04 2019 Oct 25 07:23:54 RP: ok, thanks. Does opkg clean up old kernel versions automatically when a new one is installed? Oct 25 07:44:57 lpapp: since they have different names, no Oct 25 07:56:08 I have a question about the environment-setup-* script in the created SDKs. For some reason a lot of the compiler flags end up in CC/CXX/CPP variables instead of CFLAGS/CXXFLAGS/CPPFLAGS. This works well if I do builds from someplace that uses CC/CXX/CPP for choosing compiler, but if I try to e.g. set up a Kit in QtCreator I have to make sure that those flags are copied from CC to CFLAGS etc in order to build Oct 25 07:56:14 properly. So does anyone know why this is split between CC and CFLAGS? Is it to make sure that projects overriding e.g CFLAGS don't accidentally remove flags required by target? Oct 25 07:56:43 RP: oh, ok, so if we change out kernel PN, it will be just fine? Oct 25 07:57:02 otherwise, what would you recommend? Post-install maintainer script to clean up? We are very limited on resource, so we cannot afford multiple versions. Oct 25 07:57:13 lpapp: it will be removed if you do that, yes Oct 25 08:00:01 RP: thanks - we probably still need some cleanup code now that we have deployed PN's with the version in it... so even if going forward, we only have name in the PN, where should I put the tidying functionality, in the kernel's post install script? Oct 25 08:08:25 Anybody tried putting the yocto setup and the source code for your custom application in the same repository? Oct 25 08:08:33 Any disadvantages? Oct 25 08:10:31 source code for custom application? Oct 25 08:10:42 yes, externalsrc is broken if /path/to/app is your custom app source code location and /path/to/app/yocto is where you build things for Yocto Oct 25 08:10:44 we do not put source code into any yocto about custom applications. Oct 25 08:10:51 do you mean the recipe for building that custom application? Oct 25 08:11:04 but that's unrelated to having it in the same repo Oct 25 08:12:35 I mean having both the recipe and the source code in the same repo Oct 25 08:13:15 The recipe could check out its own repo if necessary Oct 25 08:13:42 I would not put the same in same repo. Tight coupling is rarely a good idea. Oct 25 08:13:46 them* Oct 25 08:14:25 what people seem to do is having their own layers for their stack Oct 25 08:14:44 even if it is a very thin layer Oct 25 08:15:39 But if you are building firmware for an embedded system, it is a hassle to have two repos for building a single product Oct 25 08:15:55 how so? Every company I know has two layers Oct 25 08:16:08 one for the source code and for the build rules as a layer on top of whichever Yocto layer. Oct 25 08:16:21 A separate layer sure, but the same repo Oct 25 08:16:27 no Oct 25 08:16:39 there can be people developing the app having to know nothing about how the software is built Oct 25 08:17:02 Not in this case Oct 25 08:17:05 Yocto is essentially build rules Oct 25 08:17:17 it is not an umbrella repo for all sorts of source code Oct 25 08:17:26 you can do it, but it is a bit of an anti-pattern Oct 25 08:17:53 farnerup: it depends. the problem is often that you get intermigled commit logs of the applicaton and its corresponding metadata. but it really depends on your workflow and team setup. rules that make sense for 100+X employee companies might not suit a small team or even single developer Oct 25 08:18:08 or a stubborn developer :) Oct 25 08:18:56 it is also not really future proof Oct 25 08:19:22 it is "ok" today, but very well might be inadequate later and then you end of with the nonsensical history later Oct 25 08:19:30 up* Oct 25 08:19:34 (been there, done that) Oct 25 08:20:35 it is just really two entirely different things - source code and building with a specific a platform for a specific target, etc. Oct 25 08:20:44 specific platform* Oct 25 08:20:54 farnerup: we have this here and while it's rather useful to not care about sync two repos (we use externalsrc so we can't use git hashes from recipes) Oct 25 08:21:11 farnerup: all in all, it depends. Oct 25 08:21:36 OK. I think I'm gonna try. Oct 25 08:21:59 farnerup: I wouldn't Oct 25 08:22:05 Having two or more repos makes it difficult to work with gerrit and jenkins. Oct 25 08:22:39 how so? you would have a recipe checking out a git repo Oct 25 08:22:45 that's the whole principle of Yocto :) Oct 25 08:22:55 If you don't use externalsrc, separate things Oct 25 08:23:11 yeah, gerrit and jenkins are no-arguments in my opinion Oct 25 08:23:35 Also, it is pointless to self-clone even in that case as you can safely use paths instead. Oct 25 08:24:02 we work nicely with Jenkins and many more than two repos :) Oct 25 08:24:08 maybe, you are just not used to it yet Oct 25 08:24:26 farnerup: what is your worry with "building firmware for an embedded system, it is a hassle to have two repos for building a single product"? Oct 25 08:24:30 in gerrit, you can have multiple projects as well no problem Oct 25 08:24:36 has been using that as well for many years now Oct 25 08:24:48 If you make change in code and change the recipe, the recipe won't even build until the code gets approved. Oct 25 08:25:03 I have also been doing this for years Oct 25 08:25:29 you mean it will build, just not the latest Oct 25 08:25:30 farnerup: you obviously should not bump the recipe until the untlying code has been approved. which.. makes sense. Oct 25 08:25:54 but how does one repo solve this problem anyway? Oct 25 08:26:31 You change code and recipe in one commit, push it, bam! Oct 25 08:27:39 farnerup: that requires the application developer to also be maintaining the recipe. which is often not true. and even worse, it intermingles commit payload (recipe and applicaiton). so that pretty much a bad idea, IMHO Oct 25 08:28:34 Here they are always the same developer. OS and application are not two separate things. It is just "firmware". Oct 25 08:29:22 like i said, it depends on your mindset and workflow. things that might suit nobody else in the world might work well for you. Oct 25 08:30:05 given the setup you described i would opt for two repos, but that explicitly an opnion. Oct 25 08:30:06 farnerup: bam in what sense? You still need to approve the code Oct 25 08:30:10 until that the recipe will not run Oct 25 08:30:26 and as soon as the code is approved in the repos, the recipe will immediately build as well Oct 25 08:30:29 I do not get it. Oct 25 08:30:41 lpapp: Well, with externalsrc, it would, wouldn't it? Oct 25 08:30:59 yes, it would Oct 25 08:31:20 also, you can make dependencies Oct 25 08:31:26 farnerup: don't do it, externalsrc is the plague to me :D Oct 25 08:31:30 or just raw comments and text to review the two at the same time Oct 25 08:31:31 here, any commit including anything externalsrc would immediately be declined Oct 25 08:31:34 The recipe will not build automatically if jenkins has already tried to build it, it will need to be retriggered manually. Oct 25 08:31:40 its a crutch for local developmen. Oct 25 08:31:49 farnerup: why? Oct 25 08:31:55 git has added hooks ages ago Oct 25 08:32:03 I think you are looking for excuses, not solution :) Oct 25 08:32:15 basically, one repo is committed, jenkins can trigger a build no problem Oct 25 08:32:18 it does not have to be manual Oct 25 08:33:43 farnerup: if you're scared about local dev, make your devs use devtool or provide them an SDK. If you're scared about having to bump the SRCREV during heavy development, you can use AUTOREV at the beginning of the project. (though, please think twice before using it for longer term, it breaks the principle of reproducibility) Oct 25 08:36:15 that's my opinion. I work in a company where they do what you want to do. It's a fucking nightmare for integrators for different clients. They want this feature or that thing from the FW, not the whole thing. They have changes in their local FW build etc. They are not Yocto-savyy. Every time they have conflicts in FW (fine that's the part they are comfortable with) or in Yocto (they don't know about it, Oct 25 08:36:21 they don't want to know about it). Oct 25 08:36:23 it breaks almost every time Oct 25 08:37:39 Everyone has to be Yocto-savvy here. Nobody is going to update your recipe for you. Oct 25 08:37:53 Don't get me wrong, I get the "I don't want to sync repos" or whatever. But that's giving potentially a very hard time to devs because you don't want to handle a little bit of complexity or documentation for releases Oct 25 08:38:02 I'll just try it and see how it goes, unless my colleagues object. Oct 25 08:38:03 updating a recipe is far from being Yocto-savvy Oct 25 08:38:12 automated scripts do that simplicity for us Oct 25 08:38:30 also, that means tying your FW to Yocto... If you need to change one day, ugly git history :) Oct 25 08:38:42 yes, he has been warned multiple times Oct 25 08:38:57 yes thank you Oct 25 08:39:00 farnerup: good luck :) Oct 25 08:39:27 sometimes, people study the hard way ... burning their hands. Oct 25 08:39:48 lpapp: might work for him, we never know Oct 25 08:40:07 yes, 1-5% :) Oct 25 08:40:22 I wish I did not have a Yocto repo with crap history ... some person checked in gigabytes of binary Oct 25 08:40:34 ahahahahah Oct 25 08:40:39 a yocto repo clone should be only a few megabytes really at maximum since it is just text based recipes Oct 25 08:40:51 and many other things learnt the hard way Oct 25 08:41:09 I wish I could revert all that crap or anyone has told these things before in advance to me or us. Oct 25 08:41:25 anyway, I do not see any problem he solves with one repo :) Oct 25 08:41:39 that is why it is bugging me. If there was a genuine use case, I would say, ok, you are different from the rest. Oct 25 08:41:51 I told you why Oct 25 08:42:01 Hello all. I need some help with yocto. I've just rebase all my layers on warrior branch, and when i launch image build, i have this error with glib-2.0 configure step : Oct 25 08:42:05 you told Jenkins and I told you have git hooks Oct 25 08:42:09 you do not have to trigger anything manually Oct 25 08:42:12 ERROR: Cross info file must have either host or a target machine. Oct 25 08:42:17 you have not replied to that, so I assume you do not know about it Oct 25 08:42:29 once you explore, you realise, you do not need manual jenkins triggers, single repo, etc Oct 25 08:42:33 I have not heard a valid point just yet :) Oct 25 08:44:14 lpapp: A build is triggered when I push to gerrit. If it fails, it needs to retriggered manually. Oct 25 08:46:26 yes, that is wrong and easily fixable - see above. Oct 25 08:57:25 RP: I thought about it briefly... maybe another idea is for the new kernel without the version provide kernel with previous versions Oct 25 08:57:41 so on upgrade, they will be removed (replaced) automatically by opkg without any maintainer script. Oct 25 08:58:47 find somethin strange in run.do_configure ... --cross-file is used twice. Point to meson.cross (which contain host and target parts) and glib-meson.cross (which only contains properties part). Is it normal ? Oct 25 09:00:16 and this on the same line when launching meson in meson_do_configure() {} function Oct 25 09:06:12 is it inherit kernel setting my PN? Oct 25 09:06:42 I do not explicitly specify that in my recipe and my recipe name is linux-polatis_3.2.1.bb, so not sure how the version gets into the name of the corresponding ipk files? Oct 25 09:13:35 can you use glob in RREPLACE/RCONFLICTS/RREPLACES? Oct 25 09:19:24 I've a reciepe that only produce a foobar-dev package. However that package is still depending on foobar that doesn't exists. Is there a way in the package split to remove dependencies on empty packages? Oct 25 09:21:57 fredrigu: first thing, why -dev package only? Oct 25 09:23:58 fredrigu: there are some defaults defined in bitbake.conf among which RDEPENDS for packages: c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n321 Oct 25 09:24:57 lpapp: no, doesn't support globs as far as I know Oct 25 09:27:15 qschulz: the package only contains two header files Oct 25 09:27:27 so that's why it's a -dev only package Oct 25 09:47:04 fredrigu: PACKAGES = "${PN}-dev" and then RDEPENDS_${pn}-dev = "" that's seomthing you could try Oct 25 10:08:16 hi guys. Do you think the "qca9377 qca6174" use in this MACHINE_FEATURES is correct? It's not in the list in the manual: https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-features-machine and I can find other references is meta-freescale layer Oct 25 10:08:34 *I can't find other references Oct 25 10:42:17 hello, hello... is someone familiar with ubifs? Oct 25 10:42:30 I get "Error: min. I/O unit was not specified" Oct 25 10:43:12 well do what the message says. specify the minimal i/o unit :) Oct 25 10:43:27 that is the pages size, correct? Oct 25 10:44:28 probably. see also https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image_types.bbclass#n206 Oct 25 10:46:21 a,yes.I only saw the image.bbclase.ok thank you leto Oct 25 11:01:56 qschulz: thanks, it seems to work! :) Oct 25 11:15:32 fredrigu: happy to help Oct 25 11:55:43 Is Mark Hatle over here? There seems to be a weird problem with his mail :/ **** BEGIN LOGGING AT Fri Oct 25 12:27:43 2019 Oct 25 12:45:54 I just discovered that some packages can report progress during do_compile ! Oct 25 12:46:41 why and how does this work? I don't find it in the recipe sourcecode! Oct 25 12:47:53 litb: i think it's a feature of cmake, that bitbake is simply allowing to "show through" Oct 25 12:48:27 it shows up in the bitbake ' %' progressbar. so it appears to specifically parse for cmake output Oct 25 13:08:45 tlwoerner: I got a build to pass today with libcap-ng-0.7.10, but I did get a bad checksum warning still. Have you tried it again? Oct 25 13:09:24 tgamblin: all of my "last night" builds failed again, i haven't looked into them yet (reading the LTS proposal...) Oct 25 13:11:17 tgamblin: on the surface, it looks like the same error i was getting yesterday Oct 25 13:11:33 tgamblin: on what host are you running your builds? Oct 25 13:11:45 it feels like i'm missing a host package :-S Oct 25 13:12:09 I'm on Ubuntu 18.04.3 LTS Oct 25 13:12:51 also tried on Fedora 30 Server Oct 25 13:14:01 and yet, just as I say that I have another build I'm working on die with that same error message... Oct 25 13:14:04 can mfgtools upload from the board's NAND to some binary to the host? I wonder if I can have a backup from the vendor's image that works on the board Oct 25 13:14:22 okay, i'm on openSUSE 15.1 Oct 25 13:14:47 tgamblin: update the email thread, seems we're not alone :-) Oct 25 13:30:48 I also found that the poppler recipe misses a "DEPENDS" to glib-2.0-native. Oct 25 13:42:38 RP: Is 5ba152e55688b27c745a787a5ca968bb058ebf25 in your local git tree? That was the most recent SHA-1 to break with perl Oct 25 13:46:21 JPEW: no, which is odd Oct 25 13:46:49 Weird. Let me look for another Oct 25 13:47:34 RP: Just to make sure, this is the failed AB job: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/450 maybe I didn't tell you the correct SHA1? Oct 25 13:49:03 JPEW: that is the helper revision, you want 81714c6c7c16ea19c124c35572669932237754af Oct 25 13:49:12 I have that Oct 25 13:49:40 RP: Ok, can you push it to poky-contrib and I'll rebase my branch on that? Oct 25 13:50:40 JPEW: done as rpurdie/forjpew Oct 25 13:50:50 RP: excellent Oct 25 13:55:02 RP: Ok, my jpew/ab-reproducible-test branch is updated and ready to be tried on the AB Oct 25 13:58:53 JPEW: running, thanks Oct 25 14:10:11 RP: ok, thanks Oct 25 14:18:54 RP, my manager allowed me to upload my changes to github, to make mingw work as a target machine. I think the best way forward is to merge my changes with meta-mingw? Oct 25 14:19:13 litb: Progress bar is set as a "progress" var flag on a task: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/build.py#n320 as an example: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/waf.bbclass#n56 Oct 25 14:19:43 other things, like replacing .so.* with ${SOLIBS} should be merged directly with oe-core and meta-openembedded, I think Oct 25 14:19:47 litb: you need to talk with the layer maintainer (JPEW) Oct 25 14:20:12 RP, ah, I see Oct 25 14:20:13 litb: partly this depends on whether we want to officially support what you're trying to do. It will complicate things for others Oct 25 14:20:38 RP, hm, I see, makes sense! rburton appeared to be very interested in it Oct 25 14:21:33 RP, I suspect it's not necessary to support specific machines in the core layer. like, currently the core layer only needs to support qemu machines. Oct 25 14:22:11 and specific BSP layers don't need to support every package of oe-core, and not every package of oe-core needs to support every BSP layer Oct 25 14:29:11 RP, would it make sense to ask on the mailing list whether people would use it? Oct 25 14:35:12 litb: definitely post things and gauge interest Oct 25 14:35:43 litb: for example though, will I need to start asking submitters referencing *.so in patches to switch Oct 25 14:38:00 RP, a lot of recipes already avoid .so.* and instead use ${SOLIBS}. so that state of affairs is at least inconsistent and fixing it seems desirable Oct 25 14:42:38 litb: the irony being I was the one who wrote a lot of those patches Oct 25 14:43:39 litb: the context is most submitters won't care about windows and won't want to care so it will put work onto the maintainers. I get jittery about more work for some reason... Oct 25 14:44:50 hm I understand. so I think it'll just push the layer on github (I didn't need to patch anything of yocto.. it's possible entirely by .bbapend and overlaying) and tell people about it Oct 25 14:51:18 litb: I would like to see how much of an impact the changes would have Oct 25 14:51:47 litb: I just want to set expectations correctly too, these things can be tricky :/ Oct 25 14:53:41 so it Ross gone for the weekend? Oct 25 14:58:00 rp, did you say there are some fixes in master for the AB build failures? Oct 25 15:05:12 armpit: I'd say so. Not seen him for a few days Oct 25 15:05:18 armpit: which failures? Oct 25 15:05:47 the list you sent via email. I thought you mentioned you has some fixes Oct 25 15:06:17 armpit: no :( Oct 25 15:06:19 just looking to backport to zues while we find a Maintainer Oct 25 15:06:22 k Oct 25 15:07:07 plan on trying to get a zues build started before my flight to Lyon Oct 25 15:07:31 armpit: how soon? I'm about to submit that other CVE fix for binutils Oct 25 15:07:55 2-3 hours Oct 25 15:08:09 if not, I can wait when I get to the hotel Oct 25 15:08:18 just pulling in changes Oct 25 15:08:36 should be done within the hour on my end Oct 25 15:08:43 more likely 10 min Oct 25 15:08:55 do I hear 5?? Oct 25 15:09:11 i'll do it in 2, capn Oct 25 15:18:28 JPEW: succeeded :/ Oct 25 15:18:47 RP: Hrm. That's annoying Oct 25 15:19:28 JPEW: yes :( Oct 25 15:20:09 JPEW: I liked the theory :/ Oct 25 15:20:22 RP: Ya. Maybe keep the patches in master-next for a bit? Oct 25 15:20:28 JPEW: yes, will do Oct 25 16:17:10 RP, warriors qemu 3.1 has a bug fix update to 3.1.1.1 which I am pull in to see if that helps Oct 25 16:18:50 needs more .1's Oct 25 16:20:41 next update ; ) Oct 25 16:25:30 armpit: sounds good Oct 25 16:25:38 worth a shot Oct 25 16:41:36 started a-quick zeus build Oct 25 16:46:34 * JaMa finally reproduced the autobuilder issue with deploy artifacts 'IMAGE_FSTYPES_append = ' wic wic.bmap'' added in https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/1141/steps/8/logs/stdio was the important part Oct 25 18:04:47 * JaMa running testimage task for first time and it failed: Oct 25 18:04:49 WARNING: core-image-sato-sdk-ptest-1.0-r0 do_testimage: Qemu ended unexpectedly, dump data from host is in /OE/build/oe-core/tmp/log/runtime-hostdump/201910251802_qemu Oct 25 18:04:52 ERROR: Task (/OE/build/oe-core/openembedded-core/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb:do_testimage) failed with exit code '1' Oct 25 18:06:34 not so surprising when running in headless docker, but should it warn when some host tools are missing or is this acceptable result when aren't available? Oct 25 18:06:38 grep " command not found" /OE/build/oe-core/tmp/log/runtime-hostdump/201910251802_qemu/host_00_* Oct 25 18:06:42 /OE/build/oe-core/tmp/log/runtime-hostdump/201910251802_qemu/host_00_df:/bin/sh: df: command not found Oct 25 18:06:45 /OE/build/oe-core/tmp/log/runtime-hostdump/201910251802_qemu/host_00_free:/bin/sh: free: command not found Oct 25 18:06:48 /OE/build/oe-core/tmp/log/runtime-hostdump/201910251802_qemu/host_00_iostat:/bin/sh: iostat: command not found Oct 25 18:06:51 /OE/build/oe-core/tmp/log/runtime-hostdump/201910251802_qemu/host_00_memstat:/bin/sh: memstat: command not found Oct 25 18:06:54 /OE/build/oe-core/tmp/log/runtime-hostdump/201910251802_qemu/host_00_netstat:/bin/sh: netstat: command not found Oct 25 18:06:57 /OE/build/oe-core/tmp/log/runtime-hostdump/201910251802_qemu/host_00_top:/bin/sh: top: command not found Oct 25 18:18:06 I think we need a way to for a recipe to declare a host dependency... something expected from the host.. (same for tests) Oct 25 18:18:33 hte prolem is adding all of these things to the general required causes normal use-cases to failed unnecessarily.. but if you want/use those features you really want to know ASAP **** BEGIN LOGGING AT Fri Oct 25 20:50:59 2019 Oct 25 21:19:30 that'd be useful. REQUIRED_HOSTTOOLS ala the required distro features, just skippackage if it's MIA Oct 25 21:19:38 course that'd only help with binaries Oct 25 21:19:59 could easily make parts conditional on packageconfig Oct 25 21:20:07 skip if XYZ is missing if XYZ is in PACKAGECONFIG Oct 25 21:20:33 * kergoth fights meta-external-toolchain.. something is wrong with the headers extracted Oct 25 21:56:24 New news from stackoverflow: what is __anonymous class in python? Oct 26 01:57:16 so my build is failing at recipes-graphics/cairo Oct 26 01:57:24 but i'm not sure why it's even being built Oct 26 01:57:34 can i check the dependency chain between two targets with bitbake? Oct 26 02:18:51 * wbn is reading about the `-g` argument to bitbake. **** ENDING LOGGING AT Sat Oct 26 02:59:57 2019