**** BEGIN LOGGING AT Fri Mar 06 03:00:04 2020 Mar 06 05:07:49 xyzzy42: Are you sure the recipe really got rebuilt after you removed rm_work? If you didn't "bitbake -c cleansstate " it probably didn't rebuild, and therefore didn't leave anything in the workdir. Mar 06 07:28:25 New news from stackoverflow: Why is this ptvsd package failing to compile? Mar 06 08:08:47 Hi, Mar 06 08:10:56 Can anybody help me? I use Yocto 3.0.1 and want to build a simple rootfs. I added a layer and the confg file looks like this: DEFAULTTUNE = "cortexa7t"require conf/machine/include/tune-cortexa7.incTARGET_FPU=""IMAGE_FSTYPES += "tar.bz2 ubi"EXTRA_IMAGECMD_jffs2 = "-lnp "MKUBIFS_ARGS = " -m 2048 -e 126976 -c 12000 "UBINIZE_ARGS = " -p 16KiB -m 2048 Mar 06 08:10:56 -s 2048 "SERIAL_CONSOLE = "115200 ttyUSI0"PREFERRED_PROVIDER_libjpeg-native = "libjpeg-turbo-native"PREFERRED_PROVIDER_libjpeg = "libjpeg-turbo"make: *** .path/to/project/tmp/work-shared/ludwig-sdk/kernel-source: No such file or directory. Stop.ERROR: oe_runmake failed Mar 06 08:11:31 I always get an error, but I don't know why? Mar 06 08:28:41 New news from stackoverflow: Difficult to build sw utilities on yocto Mar 06 08:33:57 ths1234: that looks weird, and not only from the formatting. Mar 06 08:34:14 ths1234: care to put the layer in a place that we can see? Mar 06 08:52:24 The layer is very simple. It only contains the standard layer.conf and the machine config file. I tried the machine config file with only one line: Mar 06 08:52:26 DEFAULTTUNE = "cortexa7t"require conf/machine/include/tune-cortexa7.inc Mar 06 08:53:51 I always get the same error: /kernel-source: No such file or directory. I do not understand why the kernel-recipes is executed (make-mod-scripts). Can I disable build kernel? Mar 06 08:56:18 Hello guys, stupid question : I'm using an external meta-vendor but this meta is not compatible with zeus; what is the best way to fix that without edit any files in this meta ? Thx Mar 06 08:57:32 If I introduce a new, yet unused distro feature "foo" in DISTRO_FEATURES, shouldn't that (in theory at least) result in no rebuilding ? Mar 06 08:57:44 ths1234: you can. PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" Mar 06 08:58:27 kroon: nope, it will result in rebuilding because bitbake dosn't know who actually uses what from DISTRO_FEATURES Mar 06 09:01:24 LetoThe2nd, "bitbake doesn't know who uses what from DISTRO_FEATURES" ? Mar 06 09:02:54 kroon: thats at least my understanding. it can tell if a recipe looks at DISTRO_FEATURES for whatever reason, and hence "uses" it. it cannot tell in advance which parts of it are relevant. Mar 06 09:03:24 kroon: generally i think of DISTRO_FEATURES as kind of flag-array that can be used for arbitrary purposes. Mar 06 09:04:04 bb.utils.contains('DISTRO_FEATURES', 'foo', 'this', 'that'), the expression doesn't change if I introduce a new feature 'bar' Mar 06 09:04:43 kroon: it should, I suspect there is code which isn't quite right though Mar 06 09:04:49 kroon: if you actually go through the function, then you are right. Mar 06 09:04:50 kroon: how much rebuilds? Mar 06 09:05:01 RP: hehe. great minds think alike. Mar 06 09:05:15 RP, mostly target recipes.. i'll see if I can investigate Mar 06 09:05:28 LetoThe2nd: I wrote that code :) Mar 06 09:05:45 RP: i know. Mar 06 09:08:11 RP, definetley not all target recipes got rebuilt, so yeah maybe only some problematic ones that we can fix Mar 06 09:09:13 kroon: would be good to track them down, worth fixing if we can Mar 06 09:10:19 RP: s/track/hunt/g (for the fun of it) Mar 06 09:23:21 Why am I learning about nonarch_base_libdir just now /o\ Mar 06 09:26:47 qschulz: /me is delaying that even a bit more Mar 06 09:27:53 LetoThe2nd: we overrode base_libdir in firmware recipes until now /me facepalms Mar 06 09:29:22 qschulz: ah. never run into that as we actually don't ship noarch code. Mar 06 09:30:03 if we wanted to, technically a webfrontend or such could be violently declared as such but as it is all so tightly coupled we just don't bother. Mar 06 09:33:07 LetoThe2nd: it's more that base_libdir changes in case of multilib (/lib for 64b machines until lib32- is involved, in which case it's /lib64) IIRC Mar 06 09:33:41 And we unfortunately have such cases (and can't get rid of them, third party vendor......) Mar 06 09:33:59 qschulz: i'll try and take a mental note for upcoming support cases :) Mar 06 09:34:45 LetoThe2nd: I like reading the ML, you learn so many things from it :) Mar 06 09:38:40 qschulz: you do actually *READ* *THINGS*?!? Mar 06 09:38:59 * LetoThe2nd goes into full fahrenheit 451 mode and burns the ML with a flamethrower. Mar 06 09:41:24 LetoThe2nd: I'm able to read. What you write as well, unfortunately. Mar 06 09:41:28 :D Mar 06 09:43:20 qschulz: i am in fact made up of 1725 monkeys randomly hammering their keyboards and an AI that selects the (usually) least offensive outcome of said keyboard-hammering. Mar 06 09:43:47 * LetoThe2nd hereby puts this self-analysis into public domain. Mar 06 09:45:14 And I thought the 21 different personalities displayed in the movie Split were already a lot to handle. EVerything makes sense now :) Mar 06 09:46:18 see :) Mar 06 09:46:29 LetoThe2nd: its quite good output from only 1725 :) Mar 06 09:47:23 RP: we make sure to use only the best monkeys, of course. QA is very important! Mar 06 09:51:49 RP, my distro feature rebuild issue was a PEBKAC Mar 06 09:52:20 kroon: s/distro feature rebuild//g Mar 06 09:52:54 RP, I used += instead of _append on DISTRO_FEATURES, which threw away default values Mar 06 09:53:22 kroon: ah, that would do it Mar 06 09:59:05 LetoThe2nd, even more impressive with monkeys that know regexp Mar 06 10:00:58 kroon: we've got ze best AI to choose from the mokeys output! Mar 06 10:01:10 hehe Mar 06 10:04:02 you wouldn't believe how incredibly the AI training was. all the usually available models are trained for shakespeare, fake news, and such. getting one for #yocto, thats a real challenge! Mar 06 10:52:48 I'm wondering if there is any fix/workaround for my sumo/multilib issue, read-only rootfs scenario: Mar 06 10:53:01 MACHINE = "qemuarm64", IMAGE_INSTALL_append = " lib32-glib-2.0" and IMAGE_FEATURES = "read-only-rootfs" Mar 06 10:53:07 ERROR: core-image-minimal-1.0-r0 do_rootfs: The following packages could not be configured offline and rootfs is read-only: ['100-lib32-libglib-2.0-0'] Mar 06 10:59:13 New news from stackoverflow: how to add full x11 support for imx6 board in yocto krogoth Mar 06 13:14:59 Where is the best place to put some board configuration without edit conf/machine/machine.conf file ? =L Mar 06 13:16:32 PinkSnake: "depends" Mar 06 13:16:47 ;) Mar 06 13:24:40 I continue with stupid questions : is it possible to edit LAYERSERIES_COMPAT_ from outside the layer ? Mar 06 13:25:35 no. Mar 06 13:25:58 :S ok thx. Mar 06 13:28:16 LetoThe2nd: (yes :) ) Mar 06 13:29:02 The question is.... why? Mar 06 13:29:16 qschulz: ? Mar 06 13:29:59 qschulz: layer.conf is kind of pre-parsed to my understanding before anyting else happens. as far as i can tell there is no even remotely sane way to tinker with it. Mar 06 13:30:11 LetoThe2nd: I'm not saying it's sane :D Mar 06 13:31:03 In fact it's just because some meta are not set compatible with zeus :( Mar 06 13:31:05 LetoThe2nd: from my experience. bblayers.conf works and in fact, any layer.conf of any layer in bblayers.conf is fine Mar 06 13:31:36 LetoThe2nd: but, that's mainly an unwanted side effect and could disappear Mar 06 13:32:23 PinkSnake: fork and patch until they are. Mar 06 13:32:33 PinkSnake: add manually zeus to the layer LAYERSERIES_COMPAT_, build everything from that layer with all machines. If it works fine, send a PR to the meta Mar 06 13:32:42 LetoThe2nd: damn it Mar 06 13:32:47 too fast too furious Mar 06 13:35:12 qschulz already done 1 month ago ^^ Mar 06 13:37:02 PinkSnake: the PR? Mar 06 13:37:12 why don't you take your git repo for it then? Mar 06 13:37:55 qschulz because it's done fome my personnal account and don't want to fork on compagny repo Mar 06 13:41:03 LetoThe2nd: bblayers.conf is the first file parsed. Then layer.conf from layers in the order in which theya re declared in BBLAYERS. Mar 06 13:41:39 LetoThe2nd: one could technically override the LAYERSERIES_COMPAT_ from another layer's layer.conf because it's handled after all layer.conf have been parsed. Mar 06 13:41:57 https://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/cookerdata.py#n397 Mar 06 13:42:16 while the parsing is done in: https://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/cookerdata.py#n366 Mar 06 13:42:21 VERY bad IMO Mar 06 13:42:38 (to set LAYERSERIES_COMPAT_ elsewhere than the original layer) Mar 06 13:43:31 (we'll soon do it because we use meta-qt5 locked on pre-GPLv3 and I can't stand the warning message every time I call bibtake) Mar 06 13:52:21 I do this exact hack now to enable building the Alexa Auto SDK for AGL, Amazon only have rocko and thud in LAYERSERIES_COMPAT, so I append zeus on Mar 06 13:53:16 smurray: please send a PR to those projects to add zeus so that the hack is not needed :) Mar 06 13:53:24 a small patch is required to their stuff, trying to get something worked out with them to get it upstream Mar 06 13:53:41 smurray: nice Mar 06 13:53:49 qschulz: bemusingly, their layer is on github, but it's effectively a code dump, they ignore PRs Mar 06 13:55:05 qschulz: AGL is carrying some quite non-trivial bugfixes that I bbappend on, I've poked some of the Alexa folks to try and get it sorted Mar 06 13:55:38 qschulz: their stuff is a good bad example, they mix the source code and layers in one git repo Mar 06 13:55:49 smurray: cough cough Mar 06 13:56:27 heh Mar 06 14:00:41 same here, once it's been done it's hard to convince people to make some efforts to do it the "good" way, because "it works" (TM) Mar 06 14:02:48 Hey together, after I made some good progress in the last couple of days working my way through my first recipes, layers, images etc. I start to vaguely understand what I'm doing here '=D Mar 06 14:03:42 But with every question crossed off my list there is usually at least twice that number of new questions and my list is getting longer and longer ... Mar 06 14:04:50 What I wonder is if there is something like a yocto get together in northern germany or maybe Berlin where it would be possible to get in touch with you guys personally? Sometimes it's just so much more efficient to speak in person. Beer is on me ;) Mar 06 14:05:07 I checked meetup.com but didn't find anything there Mar 06 14:05:25 LetoThe2nd: FREE BEER ^ Mar 06 14:05:58 emrius: there is none as far as i know. set one up and have all the fame for the worlds first yocto meetup ALL FOR YOURSELF Mar 06 14:06:14 (i'll happily help promoting it, though) Mar 06 14:07:16 :) just looking for answers not for fame Mar 06 14:08:48 emrius: i'll try and be helpful during the usual office times as well as sometimes also in the evening. :) Mar 06 14:08:57 BUT if there is somebody here who is willing to present something on some occasion I would for sure take the effort to organize a small event Mar 06 14:09:43 emrius: make a tweet that we can relay, ask if there is interest. we'll make sure it gets some attention. Mar 06 14:09:53 LetoThe2nd: I know, you helped me quite a lot already. Mar 06 14:10:20 oh great! I'll do that over the weekend Mar 06 14:11:38 emrius: @TheYoctoJester, @yoctoproject, @OpenEmbeddedOrg :) Mar 06 14:11:50 Thanks! Mar 06 14:12:46 (Need to register on twitter first \O/ ) So don't be surprised if that comes from someone with no twitter-street-credibility ... Mar 06 14:13:52 Thats ok. If you have some other thing with "credibility", i can also do the tweet for you. Mar 06 14:23:23 > git clone git://git.yoctoproject.org/poky --depth=1 Mar 06 14:23:23 Cloning into 'poky'... Mar 06 14:23:23 fatal: read error: Connection reset by peer Mar 06 14:24:16 seeing it here as well Mar 06 14:25:54 halstead: Hello, just FYI ^^^ git clone git://git.yoctoproject.org/poky => fatal: read error: Connection reset by peer (same for https). Mar 06 14:28:06 hmm, existing clones seem to work, new ones do not Mar 06 14:28:13 autobuilder also sees it :( Mar 06 14:31:05 looks like it's working again now? or I got lucky Mar 06 14:32:45 halstead: it's back for me too. /me shrugs Mar 06 14:33:47 no, still there Mar 06 14:34:02 qschulz, There is some SYN flooding. I'm trying to fix it at the firewall. Mar 06 14:34:14 halstead: thanks for the prompt answer. Good luck! Mar 06 14:35:57 qschulz, dl9pf, smurray: Any change for you now? Mar 06 14:36:16 halstead: working here now Mar 06 14:36:25 halstead: both git and https seem ok now Mar 06 14:36:30 trying Mar 06 14:45:08 Tnx! Mar 06 15:26:23 i'm trying to uprev libvirt to v6.0.0, the do_configure fails saying "configure: error: "rst2html5/rst2html is required to build libvirt"", i find that rst2html is in python3-docutils, i add that to the DEPENDS variable in the libvirt recipe and i still get the error. is there something that i'm missing? Mar 06 15:28:32 ssajal: you probably need the -native incarnation of it, as it is most likely something that has to be run on the host, at build time. Mar 06 15:36:46 LetoThe2nd: i tried pytho3-docutils-native as well, -native breaks the do_compile with "/bin/bash: access/viraccessapicheck[qemu/lxc].h/.c: No such file or directory" Mar 06 15:37:31 ssajal: then you are in for some fun. either finding a way to build without that thing, or finding a way to provide it for the host. Mar 06 15:40:18 ssajal: generall this sound like it is only needed for building docs anyways, so that maybe can be disabled in the configuration stage Mar 06 15:40:58 LetoThe2nd: yes they are used for docs and man pages, i beleive. thanks for your suggestions!! Mar 06 16:46:18 LetoThe2nd: removed libvirt-doc from the PACKAGES variable in an attempt to stop building the docs, still end up with the do_configure failure Mar 06 16:49:00 ssajal: PACKAGES is not used until do_package or something. Definitely *after* do_configure Mar 06 16:50:07 and if what I'm saying isn't accurate, AFAIK PACKAGES has absolutely no impact on do_configure. PACKAGE_CONFIG, EXTRA_OEMAKE/EXTRA_OECONF etc... do. Maybe you need a patch to disable the docs building directly from the sources Mar 06 17:02:54 qschulz: thank you for your input. I'm considering if not building docs as part of the package is a good idea or not, since users might want to have a look at them. Mar 06 17:03:59 ssajal: I'd say it's a good step to make it work without the docs if the docs are really an issue and then work on that part. Mar 06 17:08:45 qschulz: sounds like a plan, i'll follow your direction and see how far i go Mar 06 17:10:49 ssajal: good luck! Mar 06 18:00:26 Would it make sense to create a new tune for specifically ivy bridge cpus? Because we need the avx instruction set and tune-corei7 doesn't provide it. Mar 06 19:54:38 Is there any HOWTOs out there for developing recipes to apply PREEMPT_RT to an existing hardware-specific BSP? Digging into it, it just seems like a colossal task and I'm not clear on how to begin. I'm trying to do this on the Pine64 kernels (sopine-a64 specifically); the Raspberry Pi RT kernels just pull down a pre-patched git branch, but I don't have that for the pine64. :( Mar 06 19:55:51 I'm thinking I need to devtool the post-patched A64 virtual/kernel, then massage PREEMPT_RT into it. But getting from that into a .bb or .bbappend is not at all clear Mar 06 19:57:46 I'm hoping that this road has been traveled, but if not I'll keep my head down until I figure it out. Mar 06 19:58:11 sheelba: in a nutshell, its complicated. you're usually better off if you set up a tree specifically for this use case and just refer to it in a recipe, instead of carrying humongeous patches in the layers. Mar 06 19:59:00 I agree-- I started my own tree but that has its own level of ginormous complexity. But I've only been at Yocto for a few months. I'll keep at it until it clicks. Mar 06 20:01:33 sheelba: taking care of the kernel by itself really is the simplest way. the yocto integration boils down to a pretty standard linux-yocto-custom recipe then, which basically just carries your defconfig. Mar 06 20:02:47 sheelba: i think there are a lot of pointers in the kernel manual, as well as bits and pieces in one of the livecoding sessions. but of course it is and will always be more complicated than just packaging some userland thing. Mar 06 20:03:16 OK, thanks! I'll steer in that direction. My goal is a true machine-independent RT-enabled yocto tree that I can use for any of this zoo of prototypes I've got, but that may be wishful thinking. *looks scornfully at the half-dozen yocto roots in my work directory* Mar 06 20:03:43 Yeah, I know I'm not doing it right. :) Mar 06 20:04:02 at least given the current state of kernel code, "machine independent rt-enabled" is just not going to happen. Mar 06 20:04:22 out of curiosity, what kernel version are you using ? and are there a lot of non mainline pine64 patches ? Mar 06 20:04:43 for the closest thing that exists, look at https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto Mar 06 20:05:08 (which on the other hand is considerably more effort to maintain, though, than just a kernel repo + simple recipe) Mar 06 20:05:34 zeddii: yeah, all the cool bits should be in anyways, right? Mar 06 20:06:28 yah, since if so, you can flip it around and just use one of the rt branches I always have in linux-yocto, and apply the BSP patches, instead of the other way around. But the kernel versions have to align, etc. Mar 06 20:06:49 zeddii: good option indeed. Mar 06 20:07:31 meta-pine64 supports up to 5.5 actually, but I've been hammering on 5.3. For the RPi they don't seem to be able to get further than 4.19. Mar 06 20:09:00 The pine64 patches may be avoidable; one is for wireless but I'm wired (and eventually not network-enabled) so I still have some hope left for linux-yocto-rt. Just need to find a proper defconfig to move forward. Mar 06 20:11:58 To be really perverse I could pull the RPi PREEMPT_RT git sources as the pre-patch target for the pine64 kernel recipe. But that way lies madness I'm sure. Best just make my own. Mar 06 20:12:30 zeddii: But yeah, good idea. I'll try it the other way Mar 06 20:12:41 sheelba: cue: https://youtu.be/Kvqr366Op3k Mar 06 20:38:46 zeddii: "v5.4/standard/preempt-rt/base" Exactly what I was looking for. I think I have the way forward with that, thanks! Mar 06 22:13:26 I'm trying to get ssh host keys to persist across software updates (which reflash the rootfs). It looks like the poky script sshd_check_keys will generate the keys in SYSCONFDIR. However, it doesn't seem that opensshd cares one bit about that variable, and will always look in /etc/ssh unless its config file is edited. Mar 06 22:15:14 It seems like setting SYSCONFDIR is quite useless. The key location needs to be in sshd_config. Mar 06 22:35:25 xyzzy42: There is some support for alternate locations (although it might not be very good). Look at the read-only-rootfs IMAGE_FEATURE Mar 06 22:36:46 I believe that makes it look for the keys in /var/run/ssh/ (which, we redirect to non-temp storage with a volatiles file) Mar 06 22:37:57 * RP watches buildtools tarball fall over with crypt.h issues. Looks like we need a new build from master Mar 06 22:40:48 Hmm, can I manually add a variable to the basehash? Mar 06 22:42:33 JPEW: vardeps ? Mar 06 22:42:53 JPEW: do_XXX[vardeps] += "YYY" ? Mar 06 22:44:29 Not quite what I need. More specifically, I've append a new string to MACHINEOVERRIDES (I think appending makes it higher priority?), but it still seems to be pulling the old sstate object Mar 06 22:45:01 e.g. MACHINEOVERRIDES .= ":foo" should make "foo" more preferred than "${MACHINE}" ? Mar 06 22:51:38 JPEW: I can never remember the ordering :/ Mar 06 22:51:53 JPEW: it should notice any values changing that would affect a given task Mar 07 00:21:53 LetoThe2nd: zeddii: Following up on earlier, I got it done! I now have a single Yocto tree that builds both RPi and Pine64 PREEMPT_RT kernels. Thanks zeddii, I interleaved the linux-pine64 and linux-yocto-rt recipes together and wiggled the pine64 patches into the preempt kernel... Unbelievably it works, although not completely automatically. Mar 07 00:26:45 nice! **** ENDING LOGGING AT Sat Mar 07 03:03:04 2020