**** BEGIN LOGGING AT Mon May 18 02:59:57 2020 May 18 04:00:00 I'm starting to build images with your awesome documentation May 18 04:00:02 but I can't figure out how to allow a user to set a static IP address to be persistent after reboot May 18 04:00:04 what are my options? May 18 06:14:36 DammitJim: the answer is as usual "it depends" May 18 06:16:01 DammitJim: basically its just like any other linux system too. use whatever ways the network management software of your choice uses, like systemd-networkd, ifupdown, network-manager (to name a ew)+ May 18 06:43:45 good morning May 18 06:43:57 mckoan: mostly such, yes. May 18 06:49:01 Letothe2nd: first day of freedom after lockdown here May 18 06:49:33 mckoan: metal & beer, hookers & blow as they say? May 18 06:49:36 May 18 06:50:08 but that indeed qualifies as a VERY GOOD morning then, indeed. May 18 06:50:59 Letothe2nd: definitely! and it's sunny too \o/ May 18 06:52:24 mckoan: here you go: https://youtu.be/bD1gjk6mrOQ May 18 06:53:32 Letothe2nd: LOL, although I play 4 strings only May 18 06:53:57 mckoan, Italy ? May 18 06:54:05 mckoan: :) just to make you feel good. May 18 06:54:16 kroon: yes, precisely Bergamo, Lombardy May 18 06:55:48 mckoan, ah nice May 18 06:58:22 khem: My use case is as follows May 18 06:58:28 I'm trying to build midori May 18 06:58:48 which for building uses: May 18 06:58:48 cmake + ninja, valac and gcc May 18 06:59:06 cmake tests if valac is working as a preparatory stage May 18 07:00:54 lukma: shuoldn't that be just a standard dependency on valac-native then? May 18 07:01:35 it runs execute_process with valac which is placed in sysroot-recipe sysroot May 18 07:02:08 Letothe2nd: I've tried to pass --cc to valac May 18 07:02:13 but this is not working May 18 07:02:38 lukma: it is very well possible that either the cmakelists or valac or both have issues with crosscompiling and need patching. May 18 07:02:44 and I still do see the issue with missing /lib/ld-linux-armhf.so.3 May 18 07:03:06 What I do expect is that I could have May 18 07:03:07 cmake May 18 07:03:11 with valac-native May 18 07:03:26 and then pass the --cc switch with arm-linux-gnueabi to valac-native May 18 07:03:44 But this is not working May 18 07:04:04 I've poked around and vala-0.42 has patches to allow cross compiling May 18 07:04:13 the joys of yet another thing cramemd into the build process. hooray. May 18 07:04:15 and also it supports the webkit for building May 18 07:07:39 Letothe2nd: But there is still the missing /lib/ld-linux-armhf.so.3 missing May 18 07:08:11 which is strange as valac is called from the recipe-sysroot May 18 07:08:29 which also has the ld-linux-armhf* in /lib May 18 07:08:39 lukma: sounds very much like you're just in the wrong sysrott, if something running on your build host is looking for an armhf loader. May 18 07:08:59 for that reason I wanted to pass LD_PRELOAD_PATH to cmake's execute_process May 18 07:09:51 that seriously sounds all horribly complicated to work around some crap in the build process instead of fixing the process, sorry. May 18 07:10:23 Letothe2nd: cmake + vala+ gcc :) May 18 07:10:53 lukma: thats not what i mean. May 18 07:11:19 Letothe2nd: Could you be more specific then? May 18 07:11:34 lukma: i mean that if something scripted in the cmakelists.txt is going wrongm then its better to patch it instead of doing dirty tricks. May 18 07:12:11 But the cmakelists.txt is not doing any bad things..... May 18 07:12:23 it just breaks when valac --version is called May 18 07:12:50 then its time to fix valac's crosscompilation facilities, probably. May 18 07:13:31 as valac --version invocation points to valac from recipe-sysroot , not recipe-sysroot-native May 18 07:14:09 I'm just not sure if valac-native will work correctly for cross compilation May 18 07:14:36 lukma: anything not native will certainly not work. May 18 07:15:36 Letothe2nd: Ok, thanks for clarification May 18 07:16:17 So I shall have cmake looking for valac in recipe-sysroot-native May 18 07:16:22 lukma: yes. May 18 07:16:39 lukma: the rule is "it is has to run at build time, it has to be -native" May 18 07:16:43 and then tune valac with --cc switch to generate code tuned for cross compilation May 18 07:17:07 Ok. May 18 07:17:19 I was confused with it May 18 07:18:07 * Letothe2nd makes note. the -native topic might be interesting for a livecoding session indeed. May 18 09:22:24 Hi May 18 09:30:23 ykrons: hello there May 18 09:30:55 I need some feedbacks on the different/right way to keep a Yocto based product secured for several years (at least 10-15 years). We have two products very similar (one on Morty, the other on Thud) and both via Toradex BSP. I don't think we are very exposed (mainly http and ssh server) so I wonder if we have to just update the vulnerable components or regulary update to newer Toradex BSP or move out of Toradex BSP to directly follow Yocto. May 18 09:32:22 I guess to follow Yocto directly require more knowledge and time, but I'm not sure if updating single component is really easily feasible on long term? May 18 09:34:26 ykrons: Morty? openssl1.0 then, which in itself is already an issue. It depends how complex your system is and how many hacks you already have in place. I'm an updateaholic so I'd say to keep updating it if you have the time to do it (because technically, you should pass all the integration test for every new update) May 18 09:34:39 ykrons: simple option: $(INSERTCOIN) into $(OSV) who offers that service. May 18 09:35:26 ykrons: not so simple option: revamp your product to CI/CD and stay right on top of master. May 18 09:36:14 ykrons: hard option: set up a security response team and backport each and every upcoming fart... erm. "annoyance" for 15 years to your ancient thing. May 18 09:37:17 with option #2 being basically what qschulz suggested) May 18 09:38:03 Letothe2nd: and having CI/CD is never a bad thing anyway :) May 18 09:38:33 qschulz: ayup May 18 09:39:28 The other option is to update to dunfell now and then update again in just under 2 years, following the stable branch in the meantime. You should internally test on master regularly to ensure that once-every-2-years upgrade doesn't become horribly painful though May 18 09:40:43 paulbarker: yes, good point. the lts is not yet fully stuck on top of my head. May 18 09:40:46 qschulz: for sure the morty one have probably to be migrated. May 18 09:42:05 I'd also do a review on what you can do to isolate the services that are exposed to minimise the risks if they do get compromised. Switch to SSH keys if you're using passwords, etc. May 18 09:42:16 Letothe2nd: coins to vendor could be a good option. We probably have to align our product on the same BSP first May 18 09:42:29 ykrons: that can be solved with more coins for sure. May 18 09:42:51 but coins are always a problem ... May 18 09:43:56 LTS with master in parallel can be nice also May 18 09:44:02 ykrons: the least pain inducing option is probably what paulbarker said, with the backoffice having CI/CD trackiong master. May 18 09:44:52 I have a CI but it has to be improved, but it is worth the effort May 18 09:47:09 What a jewel: https://dev.gentoo.org/~mgorny/articles/portability-of-tar-features.html May 18 09:47:46 sagner: is there a TLDR? May 18 09:49:51 And what about the intermedate BSP layer from Toradex? It is good to have it to have some additional features included or better to get rid of it to better match Yocto and simplify migration? May 18 09:50:26 Letothe2nd: nice writeup on what tar implementations support which features. May 18 09:54:53 ykrons: depends on the state and shape of it. maybe ask them if they are going to align with some form of LTS? another option would be to extract the relevant things for you, pour into an own layer for easier forwarding. May 18 09:58:48 RP: there's been a patch of mine for adding times to test results lingering in master-next for some time now - I thought it's relatively straightforward? May 18 10:05:45 Letothe2nd: I will check with Toradex, the main problem is that I don't know what we really use from the Toradex BSP and what comes from Angstrom, Yocto. A good first step is probably to do a quick portage to Yocto only to see what is missing .. May 18 10:11:07 ykrons: thats pretty much a classic approach, yes. May 18 10:11:56 Thanks all for your feedback. Just have now to find money, improve a CI and migrate several products ;) No revolution, but the different options are clearer now. May 18 10:13:36 ykrons: I do work at Toradex (in the TorizonCore team). We did drop Angstrom, and provide a pure OE BSP (that is since Toradex BSP 3.0, OE thud). We currently work on our first release for zeus (Toradex 4.0), and consider switching to dunfell quite quickly (due to LTS...). May 18 10:15:04 ykrons: but I suggest to use our official channels as well, and state what you would prefer from a Toradex BSP to make your life easier. May 18 10:15:31 <[Sno]> otavio: do I need to do anything else to get 5.4.y+qoriq branches being took into linux-fslc? May 18 10:20:32 sagner: good news I don't know 4.0 is based on Zeus and you plan to follow LTS. For sure, I will go through official channel, but I want to also have a "not influenced" opinion on the fact to use or not the Toradex BSP layer. May 18 10:40:27 Hello ! I use yocto-warrior for a TQ Freescale Solution. It worked on a Ubuntu 16.04 and created an Image. Now I have to put the whole thing into azure devops. For That I got a new LinuxServer as an Agent 18.04. I checked in all the Yocto Layers and also the Conf directory. oe-init-build-env worked and started the bitbake. Started, but the gave me May 18 10:40:27 some bad mistakes. "Exception: ModuleNotFoundError: No module named 'oe.patch'" or later 'oe.gpg_sign' and similar. In libs/oe/ they are all there. Only thing I hat to change it all to relative paths. (Perhaps if it helps some Warnings at the beginning : Unable to get checksum for .. oe-find-native-sysroot: file not found)) May 18 10:44:39 ykrons: sure. Many of our machines are also supported in the meta-freescale-3rdparty layer, only using this layer instead of meta-toradex-* might be an option too. May 18 11:10:11 schu-r: checked in the layers and the conf directory? what do you mean by that? May 18 11:17:05 git add, git commit, pit push May 18 11:17:09 git push May 18 11:18:02 Letothe2nd: Hab deine Videos über yocto auf youtube durchgeschaut. Danke. Hat mir sehr geholfen einen Überblick zu bekommen. May 18 11:19:35 schu-r: why would one add a config to a repo? May 18 11:19:46 layers, of course. May 18 11:19:53 configs? almost never. May 18 11:21:35 Our company wants to provide 10-30 years of support. So everything needed for building has to go to into a Git repo in our Devops. Later on even the Downloaded Packages. Dont know if we well bi able to get them in the exact version in 20 Years May 18 11:22:19 schu-r: that sounds very much like non-thought through. May 18 11:23:00 schu-r: and just "sticking everything into git" with no respect for the ways things work is just gonna make it more difficult on top. May 18 11:23:31 I know. But its not up to my decision. Im just the one who has to implement it that way. May 18 11:24:08 But back to the original Problem. Any ideas? May 18 11:25:19 schu-r: while it might sound a bit rough, i tend to not invest a lot of time it things that i consider as stupid. and as my gut feeling now is that your problem is completely homegrown due to randomly moving bits and pieces around without a workflow that actually enables reproducible build, i feel not very much inclined to follow up. sorry. May 18 11:25:37 schu-r: wait until next thrusday where i will actually speak about that very topic. May 18 11:26:02 where. Looking forward for this. May 18 11:27:16 schu-r: https://twitter.com/TheYoctoJester/status/1260293009909915653 May 18 11:27:35 schu-r: for the waiting time, you might want to look at both kas and what the linux-cip project does. May 18 11:31:10 schu-r: as well as https://www.linkedin.com/events/yoctolivecoding/ if you happen to favor linkedin May 18 11:38:21 Letothe2nd: registered now on Twitch. Thanx May 18 11:40:02 schu-r: have fun then respectively good luck, and see you at least next week :) May 18 12:11:42 any idea why qemu-native is failing to build on dunfell https://pastebin.com/TRFTNxSf May 18 12:11:58 Hi, I tried to find some example of recipe which will pack some files in my recipe directory and store them in tmp/build/images as a build artifact May 18 12:12:15 building with meta-intel for intel-corei7-x64 May 18 12:13:16 rokm: look in the dev-manual, search for packaging externally produced binaries or similar. May 18 12:17:08 rokm: are you trying to use the deploy task by any chance? May 18 12:17:47 I'm at the beginning May 18 12:18:42 basically want to pack my script files and copy this file to build dir May 18 12:19:18 rokm: which build dir? May 18 12:19:40 tmp/deploy/images// May 18 12:19:54 rokm: seriously, there is a paragraph that describes exactly what you are talking about. May 18 12:21:49 like I wrote, I'm checking this right now -> Packaging externally produced binaries May 18 12:22:21 rokm: it's a do_deploy task you want and write in the deploydir (which isn't directly tmp/deploy/images... but some necessary intermediate dir so that the sstate-cache can work). May 18 12:23:08 rokm: also... I hope you're not trying to use the deploydir as a shared directory between recipes :) May 18 12:28:02 Letothe2nd, thanks for answering my question earlier... what is the default, though? May 18 12:28:02 or how do I find out what my system is currently using? I looked for /etc/network/interfaces as well as a network config through systemd, but couldn't find anything :( May 18 12:29:13 DammitJim: because the default is: "none" May 18 12:29:24 oh May 18 12:29:40 so, the system doesn't have a particular config and it just works with dhcp out of the box May 18 12:30:04 but if one needs to set up a static IP, one needs to add that to be able to make it persistent? May 18 12:30:46 you just making that statement at least helps me believe I'm not crazy ;) May 18 12:32:19 DammitJim: if it works with dhcp out of the box, then there is something. but i cannot tell what, because it is not a yocto default (like building core-image-minimal for qemu or such) May 18 12:32:26 @Letothe2nd: regarding the out-of-tree kernel module development, any new ideas? May 18 12:32:56 nucatus: i didn't have look yet, as i didn't know if you're around. May 18 12:33:41 no worries! I've also posted a message on the mailing list: https://lists.yoctoproject.org/g/yocto/topic/best_practice_for_kernel/74249707?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,74249707 May 18 12:35:28 probably it would the best if you can put your response there, for posterity ;) May 18 12:37:12 oh, thanks for clarifying that, Letothe2nd May 18 12:37:22 so, at this point, this is probably a question in the networking channgel May 18 12:38:12 nucatus: a particular reason why not the esdk which has all the fancy magic included? May 18 12:39:41 DammitJim: no, its more like a question what your distro sets. because you probably are building for a specific board, using some bsp. and thats where it is probably being decided. May 18 12:40:04 Hi, Letothe2nd :) May 18 12:40:31 yeah, in this case it's ubuntu 14.04 May 18 12:40:35 Letothe2nd: we thought this would be the next thing to investigate. Just built an eSDK and tried to see if that works. However, didn't find any reference in the documentation to this aspect, and this is why we started with the SDK. May 18 12:40:39 awesome. you guys are great! May 18 12:40:39 DammitJim: no May 18 12:40:45 DammitJim: thats your build host. May 18 12:40:51 oh.. oops May 18 12:41:02 oh ok, so for this versalogic board May 18 12:41:08 I'd have to go look at their documentation, right? May 18 12:41:35 nucatus: well to be honest, i wouldn't jump through the (e)sdk hoops unless you really got seperate teams of board suppport and application developers. May 18 12:41:58 DammitJim: either that, or at the layers they provided. May 18 12:44:52 I can work with that, thanks May 18 12:47:23 Again, sorry if I miss something in the documentation.We thought this is a quite common use case, thus a best practice should be in place. I might be wrong :) May 18 12:52:40 nucatus: hum, not exactly. May 18 12:52:42 nucatus: well.. using a build system for distributions to develop a kernel module.. it feels to me it's one unnecessary intermediate "dependency" for building something for which you only need the kernel. May 18 12:53:23 nucatus: kernel modules are usually really close to the board support, so are mostly done by folks close the core. the sdks are most like meant for application developers. May 18 12:54:58 OK. I see the point now. That, indeed makes more sense to me now. May 18 12:55:46 qschulz: the kernel module is a prerequisite of the application layer. Without it, the application can't work. May 18 12:58:24 nucatus: hence, I usually would develop the module using the full blown build system approach, and be done. May 18 13:00:10 Letothe2nd: yes, this was our fallback scenario. Just wanted to check what the more experienced people would do in this case. Thanks for your opinion! May 18 13:00:26 nucatus: YW May 18 13:30:46 denix: Do you think the optee pycrypto/pycryptodome can wait for after the meta-arm dunfell release? May 18 14:21:43 Hi im having a issue with building qemu im getting /qemu-3.0.0/block/gluster.c:12:10: fatal error: glusterfs/api/glfs.h: No such file or directory May 18 14:22:48 hmw1: native or for target? new error or never worked before? May 18 14:23:13 its in the work/x86_64-linux/qemu-native/ folder May 18 14:24:54 hmw1: and since when? May 18 14:26:21 hmw1, I think I had that once upon a time. Think its been fixed since https://github.com/openembedded/openembedded-core/commit/f5ffd6ce6e7431b17a291980843752e2d2fb0b44 May 18 14:26:30 sinds i setup a new yocto enviroment. i stil have the old 1 ( same "os version") if i do a cleanall and a build of qemu it works May 18 14:28:36 kroon: tnx trying the patch May 18 14:33:02 kroon: its on do_install so it looks like its working May 18 14:33:21 kroon: tnx man May 18 16:34:06 Hey guys, was wondering what you'd recommend for configuring a postgresql install / database instance during image build? I'd like to have the `postgres` user modifed, add a user, and then perform a seed/migration (currently done using knex). Is this possible during the image build? May 18 16:56:15 Also running into an issue that the database isn't initialized during build, trying to get around that as well May 18 17:16:45 where do I get more information about meta-openembedded meta-networking May 18 17:17:10 I think that's the layer my versalogic is using for networking and I need to be able to set up a static ip address and be persistent May 18 17:22:23 Actually, yeah there's a bunch of weirdness. Don't even have `psql` May 18 17:28:51 where can I find the preinst and postinst files in Yocto for init-ifupdown? Or is it autogenerated during the build? May 18 17:29:17 jonmason: not sure, let's ask JPEW May 18 17:38:22 Looks like there's no /usr/pg-xxxx directory, so no psql or anything. Plus the database init isn't working. guess it might be worth checking how up to date the layer is May 18 17:43:13 kanavin_home: https://autobuilder.yoctoproject.org/typhoon/#/builders/112/builds/2 failed but I think sent mail anyway? May 18 17:43:27 kanavin_home: I just want to check something on that patch May 18 17:43:36 keep forgetting, sorry May 18 17:45:22 kanavin_home: 15 hour runtime is better than 3 days :) May 18 17:48:21 RP: I think it 'failed' because of devtool upgrade failures, so it wasn't really a failure? May 18 17:48:57 otherwise looks decent, my AUH run finished a bit earlier, so there's two of everything now May 18 17:59:30 hello May 18 18:06:53 how can I modify the postinst script to add prints to it to debug it? May 18 18:06:59 why the code in it has no effect? May 18 18:07:35 i know I can use ar x on the ipk file and then tar to look infot control.tar.gz, but I do not know how to pack it back if I modify it? May 18 18:07:41 or if there is a better via a recipe? May 18 18:11:44 i'd just modify the recipe. but you can always use opkg-build to build an ipk May 18 18:12:07 ERROR: Failed to spawn fakeroot worker to run .../oe-core/meta/recipes-core/images/core-image-minimal-initramfs.bb:do_image_create_sdcard_symlink: [Errno 2] No such file or directory: '.../build/tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo' May 18 18:12:14 wtf. has anyone seen this before? May 18 18:15:22 ah, it's a task from meta-imx.. May 18 18:18:32 jonmason, denix: I don't need it on dunfell FWIW May 18 18:18:38 master is fine for me May 18 18:19:34 Cool, I'll cut the release then May 18 18:20:58 JPEW, jonmason: well, I guess I can leave with meta-python dependency in dunfell for a while... :) May 18 18:31:06 gonna try building from source on the target since the recipe isn't working May 18 18:36:51 how would you modify the recipe? May 18 18:37:16 basically, after the upgrade of init-ifupdown, the network interface does not come back, but if I start the networking service manually, it comes back. May 18 18:37:44 this is when I invoke the install from my C programme. If I do it from command line, it is all fine. It is the postinst script that should bring it back up, I believe. May 18 18:40:27 kergoth: ^# May 18 18:52:20 so, it seems the system is using systemd, but for my life I can't figure out what file to edit to set the static ip address May 18 18:53:39 So If I build postgresql from source on the target, it works perfectly fine. Using the `dunfell` recipe I get the postgres user but the database isn't initialized. I'm thinking maybe it has something to do with disabling sysinitv in place of systemd. Though the recipe seems to take account of this, as well as the inclusion of openssl May 18 18:59:32 kanavin_home: right, we may need to tweak the scripts if we don't want to see "Failures" like that. its good they worked and sent out the same things :) May 18 19:02:54 Anyone have an idea why the `meta-oe` postgresql recipe might be messing up? May 18 20:08:27 JPEW: have you tried optee with gcc10? I'm seeing undefined reference to __getauxval now in master May 18 20:08:37 khem: ^^^ May 18 20:13:34 denix: which package ? May 18 20:13:41 ah optee May 18 20:14:07 khem: optee-os May 18 20:14:40 denix: best course of action is to disable outline-atomics May 18 20:15:08 add -mno-outline-atomics to CFLAGS May 18 20:15:32 or provide a local impl of __getauxval May 18 20:17:17 khem: thanks, let me try that May 18 20:19:13 I am also getting convinced that I should perhaps just disable it gcc configure itself May 18 20:19:25 but did not want to do it as much as we can May 18 20:20:27 We use proper -mcpu options unlike some of desktop/server distros like fedora and its ilk so we wont lose much with performance if we were to just shut it May 18 20:21:05 it matters to them because they tune to least common denominator and expect it to work on latest armv8 socs May 18 20:21:11 with some performance May 18 20:40:15 denix, khem: Yes I was just looking into that! May 18 20:40:19 khem: what would you take off from the configure? May 18 20:41:05 khem: what you say makes sense I just dont know which configure option you want to disable May 18 20:45:42 kergoth: can you help me a bit to see why that package upgrade leaves the interface down? May 18 20:46:10 I would assume that preinst bring it down based on its content, but for some reason, postinst does not bring it back. May 18 20:53:16 khem, denix: I can't seem to get it to take a __getauxval() stub I've written. I'm not quite sure why May 18 20:55:20 khem, denix: Of course, I say that and it works :) It's messy though because you have to specify the new object file after libgcc.a, which the makefiles aren't setup to do (linking with --as-needed probably) May 18 21:00:49 JPEW: is it required to add the stub? have you tried disabling outline-atomics, as khem suggested above? May 18 21:04:16 denix: No, I haven't tried that yet May 18 21:58:26 you would infact add it to specs file May 18 22:23:04 Hello any help with toaster getting on dunfell: if p.pattern.regex.pattern == '^' + modulename + '/': AttributeError: 'RegexURLResolver' object has no attribute 'pattern' **** ENDING LOGGING AT Tue May 19 02:59:57 2020