**** BEGIN LOGGING AT Wed Jan 31 03:00:03 2018 Jan 31 04:57:59 New news from stackoverflow: PHP in Yocto using Apache2 Jan 31 11:34:18 hello, is there any guide or recommendtations of what tools to use and what packages to include for proper power management (sleep, suspend-to-RAM, automated shutdown, automated wakeup from sleep) for an embedded Linux system? Jan 31 11:35:15 so that I may avoid some kind of handcrafted scripts that do stuff with sysfs Jan 31 11:45:44 eduardas_m: you really want to clarify what hardware you're talking about Jan 31 11:46:53 rburton: i.MX6 Quad, now doing a prototype on the Variscite DART-MX6 SoM Jan 31 11:47:10 rburton: handheld device with screen Jan 31 11:48:05 so the screen backlight is a major power draw of course Jan 31 11:50:11 so I should disable the screen and its backlight after some time and make the device go to sleep Jan 31 11:51:25 I am not sure whether this should be handled by systemd somehow or some other component should be used Jan 31 11:52:43 X can handle screen for you, assuming you're using that Jan 31 11:54:14 rburton: I am not using X11 and am not going to... decided to go with a single Qt application with eglfs backend Jan 31 11:54:48 so there has to be some other way Jan 31 11:55:06 Qt with eglfs is what my SoM vendor recommended Jan 31 11:55:13 simple enough to monitor activity and sleep in your app Jan 31 11:55:30 presumably qt exposes an idle timer Jan 31 11:56:05 X has an idle alarm, you tell it you want to be told after N seconds of idle, and you get a message Jan 31 11:56:56 considering qt is a platform to itself, presumably it has something similar Jan 31 11:58:21 rburton: never considered the possibility of qt having a solution for that, honestly Jan 31 12:00:06 never used it, no idea. Jan 31 12:02:31 rburton: what really sounds complicated to achieve is something like the following: going into suspend to RAM for a while and if no wakeup is performed via GPIO, then the device should do an actual poweroff Jan 31 12:02:53 I actually have a request for this kind of feature Jan 31 12:04:42 I am not sure whether an automatic wakeup from suspend to RAM can be done after a while because I expect an actual poweroff to only be achievable from normal state Jan 31 12:06:25 the kernel can arrange most of that cant it? Jan 31 12:06:52 then again, when I think about that kind of feature, perhaps that's entirely hardware platform - specific Jan 31 12:07:37 rburton: I am not aware of what can actually do an automated wakeup from Suspend-to-RAM via a specified time Jan 31 12:15:49 https://wiki.archlinux.org/index.php/Power_management#Delayed_hibernation_service_file is literally what you want Jan 31 12:23:32 rburton: thank you, I was not aware of that... will try to implement something similar then Jan 31 14:52:02 hi, folks! Can i add new recipe with newer package version to another layer? I need to update some packets without touching a layer with this packets. Is it possible? Jan 31 14:53:23 i thought it works like that: bitbake scans all layers and get newer recipe (by version). But it seems like i was wrong Jan 31 14:54:42 andrey_: it does, unless something explicitly selects an older version Jan 31 14:56:03 i had placed recipe with newer version in my layer, but i got my recipe SKIPPED. I even tried to use PREFERRED_VERSION, but bitbake even doesn't see my recipe. So, it just uses older version of package. Jan 31 14:56:46 andrey_: and you are sure that the name etc. matches exactly? Jan 31 14:57:06 LetoThe2nd: yep. i am. Jan 31 14:57:27 andrey_: and the layer is functional? e.g., another recipe in the same directory works? Jan 31 14:58:04 i have custom linux kernel in my layer and it does work Jan 31 14:59:43 i mean kernel recipe Jan 31 14:59:53 New news from stackoverflow: Jenkins job hangs after big build Jan 31 15:01:41 andrey_: layers with higher priority win, so you probably are hitting that. note that meta-oe has an oddly high priority. Jan 31 15:01:46 ok, and which package you are trying tooverride? Jan 31 15:01:51 rburton: good point. Jan 31 15:01:52 andrey_: preferred version will still work though Jan 31 15:01:59 so maybe your layer.conf is broken Jan 31 15:02:44 "bitbake-layers show-overlayed" should list both the version you don't want and the version you added Jan 31 15:02:51 if it doesn't then your layer/recipe is the problem Jan 31 15:03:31 preferred version doesn't work. I got warning like: NOTE: preferred version 4.7.0 of samba not available (for item samba-dsdb-modules) Jan 31 15:03:34 NOTE: versions of samba available: 4.6.7 Jan 31 15:03:46 right so it can't see your recipe Jan 31 15:03:52 so either your recipe or your layer is broken Jan 31 15:04:24 yes, i think it is a layer.conf problem Jan 31 15:04:40 the usual problem is that BBFILES in layer.conf doesn't actually match where you put the recipe Jan 31 15:06:00 i got it. But i think there is another problem. Please, look at my local.conf: Jan 31 15:06:04 https://paste.gnome.org/pqeozzhst Jan 31 15:07:25 oh, ignore extra line numbers. it just because i copied it from vim Jan 31 15:08:58 my recipe is here: LAYERNAME/recipes-connectivity/samba Jan 31 15:10:29 even more, i can use 'bitbake-layers show-recipes' to see my recipe with SKIPPED status Jan 31 15:10:44 i am out of ideas Jan 31 15:52:23 Is there any way to override a IMAGE_FEATURES_remove="package-management" in a .bbappend or a included recipe where the remove statement is present? Jan 31 15:53:43 sveinse: write a new image recipe, and set image features as you please Jan 31 15:54:10 sveinse: or fix the original file Jan 31 15:54:39 kanavin: ok. not what I hoped for. I just need a development image based on the production image that have some extra features, such as package-management Jan 31 15:55:06 nope, can't undo a _remove yet, which is why you need to be careful when it's used Jan 31 15:55:13 or use an intermediate varaible Jan 31 15:55:34 sveinse: you simply need to rearrange the files that define the images: image-production.bb has the _remove, and everything else goes to .inc Jan 31 15:55:34 i.e. BAR_REMOVE = "blah"; BAR_remove = "${BAR_REMOVE}" Jan 31 15:55:43 sveinse: that .inc is also included by image-development.bb Jan 31 15:55:47 yeah, that'd be one option Jan 31 15:55:49 and the production image is also layered on top of a system image, which uses package-management, hence the _remove Jan 31 15:56:08 i have a prototype somewhere that uses bbclassextend to implement image variants that you might find interesting Jan 31 15:56:11 sveinse: don't base the development image on top of production image simply :) Jan 31 15:56:18 ie.. it adds prod and dev variants of every image Jan 31 15:56:44 kanavin: why? Jan 31 15:57:38 a dev image = a production image + a few extra packages. Otherwise same deployment Jan 31 15:57:58 sveinse: + different image features Jan 31 15:58:12 sveinse: so just put the common bits into .inc, and derive various images from that Jan 31 15:58:30 sveinse: copy/paste the system image instead of layering it Jan 31 15:58:44 this obsession with layering images is crazy imho Jan 31 15:59:10 it is strange how reluctant folks are to create their own images Jan 31 15:59:21 especially when system image is making policy decisions you want to control Jan 31 15:59:28 rburton: Yeah, I know you'd say that, but it isn't that easy in pratice. Especially when we have a vendor that is responsible for the low-level system, so we must build on top of theirs Jan 31 15:59:32 i was thinking the other day it'd be nice to append to the conf-notes, so new layers could list their images without having to set TEMPLATECONF Jan 31 15:59:33 copy/paste Jan 31 16:00:04 We only want to focus on the application, not the system. But we make the image, since we layer a few things on top of it Jan 31 16:00:06 sveinse: copy/paste *and* moan at them to make them produce packagegroups so their images are just pulling a few packagegroups together Jan 31 16:00:24 i have literally no idea why their image is doing IMAGE_FEATURES_remove Jan 31 16:00:42 that doesn't solve anything, just causes problems Jan 31 16:00:43 The layering is what sold us to Yocto in the first place, so I'm not that surprised that this is something that people are confused about Jan 31 16:02:38 sveinse: basically you're describing to us why their image is broken... tell them, not us. :) they're *forcing* users of the image to not have package mangement, even if they wanted to use it. Jan 31 16:02:41 copy/paste implies having multiple copies of essentially the same code. .inc is probably the way to go here Jan 31 16:03:02 sveinse: sure copy/paste the sane bits into an inc, or copy/paste to a base image that actually works Jan 31 16:03:30 if dev image is prod image + package-management + dev-pkgs, then that's just an include base.bb and IMAGE_FEATURES+= away from working Jan 31 16:03:42 rburton: Well, being the responsible for our yocto layer, I'm also having a hard time understanding what should go where. E.g. how to make a sensible separation between machine and distro and images Jan 31 16:04:07 so I'm often left with making the most naïve apporach, yet the wrong one :( Jan 31 16:05:19 so pardon me for sounding insistive, I'm trying as best I can Jan 31 16:05:21 https://www.dropbox.com/s/gxb6uxlputaupmj/OpenEmbedded%20-%20Metadata%20Structure%20-%20Distro%2C%20Machine%2C%20Image.txt?dl=0 not 100%, needs work, and you can ignore the user features bits, but it's a start Jan 31 16:05:34 sveinse: it sounds like you just need to talk your vnedor into making a sane image :) Jan 31 16:05:40 beyond that, copy it Jan 31 16:06:01 technically it's possible to undo a _remove, but only through poking into bitbake internals, and I won't tell you how to do it, since it's evil Jan 31 16:06:11 :) Jan 31 16:06:32 kergoth: do be honest, I don't think they know either. They're a HW vendor. It's not like their upstream SoC images are any better with that respect either Jan 31 16:06:32 haha Jan 31 16:06:52 the haha was actually to kergoth but it works as a response to sveinse too Jan 31 16:07:02 hah Jan 31 16:07:17 :D Jan 31 16:07:48 hey there it is, https://gist.github.com/kergoth/fa967c354a8ce4538b8456bd6b99a9d8 - never did do anything with it, was just to see if it'd work Jan 31 16:13:32 There is one thing I'm curious about: Yocto encourages having separate meta and software? Why is that? What about use cases where the meta and the software is developed together? Ala. so-called native packages in Debian Jan 31 16:16:16 sveinse: then put the sources in the layer, if you want. some examples of that in oe-core... Jan 31 16:17:23 I've also put the recipe for a project inside its local source tree before, and then managed fetching it outside of bitbake, the way i fetch layers. didn't do much with it, ended up being more trouble than it was worth, but it's possible.. the issue is bitbake can't fetch and then parse after the fetch, so bitbake can't fetch/unpack/patch the sources in that case Jan 31 16:21:23 we have a mono-repo for the project, which contains various software packages for various recipes. I started out having a separate meta layer for yocto, but it soon died, as I was difficult for the devs to keep this updated with the main code repo. And that the repo was used by multiple recipes created a lot of parallel checkouts Jan 31 16:22:07 there are advantages and disadvantages to having the metadata out of band Jan 31 16:22:14 tradeoffs either way Jan 31 16:25:03 So I have ended up with a construct like this: https://bpaste.net/show/84482b5cbabf Jan 31 16:26:03 But some hacks were required, such as having to set SP_BASEDIR := "${LAYERDIR}/.." since the layerdir is surprisingly not available in recipes Jan 31 16:28:51 what is the difference from including an .inc vs using a .bbclass? Jan 31 16:29:16 classes can do a lot more, but if an inc is enough... Jan 31 16:29:31 bbclass implicitly assumes classes/.bbclass, supports EXPORT_FUNCTIONS to implement basic inheritence, etc Jan 31 16:29:37 depends on the requirements Jan 31 16:29:50 friends don't tell friends about EXPORT_FUNCTIONS Jan 31 16:31:14 heh, I was about to say that I'm probably completely failing in Yocto 101. EXPORT_FUNCTION? Never used it on bbclass... Jan 31 16:31:19 good Jan 31 16:31:22 haha. it made sense when we wrote it, but given inheritence is almost always flat, rather than nested, it's cleaner to just write custom functions and call them as needed, i.e. oe_runmake, rather than calling the base function, i.e. base_do_compile, particularly since we don't generally pass along arguments with it Jan 31 16:31:45 so some kind of declaration scheme then? Jan 31 16:32:03 kergoth: yeah i'm 99% sure early bitbake design was done in a pub Jan 31 16:32:18 lol :D Jan 31 16:32:31 but considering its age its done surprisingly well :) Jan 31 16:32:40 it was just a way to rename a function and automatically create a wrapper, i.e. it'd create _ and define to run _, making it easier to overwrite and still be able to call the original function Jan 31 16:32:58 but we have _prepend/_append, so 90% of the time it's unneeded, and the rest of the time we want to pass arguments, so.. Jan 31 16:33:11 the defacto rules to everything makes yocto and bitbake hard thou Jan 31 16:33:29 but i.e. you could do do_configure () { some_stuff; base_do_configure; some_other_stuff; } if base.bbclass did EXPORT_FUNCTIONS do_configure Jan 31 16:33:54 well, we prioritize flexibility, which has allowed for a lot of the features that made the project what it is today, but the downside is there are lots of ways of doing things Jan 31 16:34:10 it's like the python vs perl philosophy, one way to do it or multiple ways to do it Jan 31 16:34:14 more tradeoffs Jan 31 16:35:42 yup, and some deliberate scope limitations. Such as that there is no CM responsibility in yocto, putting this over to the users. Jan 31 16:36:25 There is nothing wrong with that, but it does create a spread of solutions across seemingly similar systems Jan 31 16:36:44 yeah, not providing an official way to manage/fetch the layers / repositories was a bit of a mistake, i think.. upside is not every tool for managing such things meets all needs, but downside is it leads to confusion and inconsistency amongst the userbase in that regard Jan 31 16:37:31 sveinse: if you propose an official CM solution, we'll gladly take it Jan 31 16:37:50 sveinse: it's not a deliberate scope limitation, it's more of a 'only 24 hours in a day' situation Jan 31 16:40:46 kanavin: yeah, *that* I do understand. Well, we do have built our own custom CM on top of Yocto. We build the same image for three machines, which in turn is aggregated into a common installer image. The latter has been somewhat a challenge, since it crosesses MACHINES (and before multiconfig) Jan 31 16:41:43 Would it be interesting with a showdown of how it works? The flow from setting up the CM to getting the artifacts? Jan 31 16:42:01 sveinse: on the openembedded-architecture list, certainly Jan 31 16:43:17 kanavin: sure, thanks. Jan 31 16:53:37 rburton: With regards to package groups: It's not always easy: Use packagegroups, yeah? Remember the other chat the other day about not using packagegroup-base-ext2 because of it's age? Not easy being in the other end knowing what to use and what not to :D ;) Jan 31 16:58:17 Thanks guys. I find these discussions interesting and educational Jan 31 17:05:17 kergoth: What is the difference between using += and _append? E.g. I see a *lot* of ROOTFS_POSTPROCESS_COMMAND_append and IMAGE_INSTALL_append_machine rather than using += ? Why is that? Bad pratice by everyone involved? Jan 31 17:05:40 +=/=+ and .=/=. are immediate, _append and _prepend are lazy Jan 31 17:06:10 if a local.conf uses += on something that isn't defined until later, either that value will be overridden, or if the recipe uses ?=, it'll override that instead Jan 31 17:06:50 _append_machine is also the only way to conditionally append based on an override, +=/.=/=+/=. don't provide a conditional operation Jan 31 17:07:13 best practice is to use immediate operations wherever possible, and use the others only when necessary Jan 31 17:07:30 see also the bitbake user manual, which covers the file format Jan 31 17:08:40 kergoth: thanks. I think that has to be the most misused best pratice then :D Jan 31 17:09:00 people like to copy and paste without understanding what it is or why they need it Jan 31 17:10:21 tell me about it. copy pasting is the only way I can really learn what I need to have to make it work, yet it not setting a good example evidently Jan 31 17:11:53 kergoth: not to be confused with immediate expansion which you should ideally never use :) Jan 31 17:11:59 indeed Jan 31 17:12:25 nothing wrong with copying stuff, especially if it's good stuff, but it's best to understand what it is Jan 31 17:13:02 RP: I use it... To set SP_BASEDIR := "${LAYERDIR}/.." Jan 31 17:13:21 that's not needed, if it's in layer.conf Jan 31 17:13:26 LAYERDIR is specially handled Jan 31 17:13:31 not in recipes Jan 31 17:13:40 bitbake expands LAYERDIR after layer.conf is parsed Jan 31 17:13:44 so := is redundant Jan 31 17:15:16 right. Second is this construct BASEVERSION := "${@read_baseversion(d)}" to avoid calling this function every time this variable is used Jan 31 17:15:56 dealing with external files is one of the rare cases that := can be useful, but it's important to realize using := there doesn't mean it'll only be run once, depending on where it's defined Jan 31 17:16:25 kergoth: no it does not. I think it's run 3 or 4 times during a build IIRC Jan 31 17:16:26 i.e. recipe files are re-parsed when the task is run, so it's actually run for each task, if it's defined in the recipe Jan 31 17:16:29 * kergoth nods Jan 31 17:16:47 can be confusing if someone adds a warning to such a function without knowing that :) Jan 31 17:16:54 sveinse: I didn't say never use it, I said ideally never :) Jan 31 17:17:02 sveinse: sadly the world isn't ideal Jan 31 17:17:24 Yeah, true Jan 31 17:17:40 sveinse: there are some places we have to use it for various reasons but I do think we should try and minimise them and you don't see many uses in OE-Core Jan 31 17:17:42 I wanted to show to see if there are some defacto methods here too :D Jan 31 17:19:04 := for that reason can be a case of premature optimization, depending on how often it's actually expanded Jan 31 17:19:11 can be a good thing to actually test Jan 31 17:20:59 grepping my recipies I found FILESEXTRAPATHS_prepend := "${R}:". Probably those under the written-on-a-bar category by yours truly :P Jan 31 17:24:35 FILESEXTRAPATHS is a case where it's needed, as FILE/FILE_DIRNAME/THISDIR is defined based on the current file being parsed Jan 31 17:24:42 if you dont' use :=, that'll be the path to the recipe rather than the bbappend Jan 31 17:25:13 We have a central service generating corporate-wide build IDs. I quickly learned that plugging this into yocto was surpisingly hard. Either because it ran multiple times or that it was cached and just ran once. Jan 31 17:25:38 This is how I learned that := is run multiple times :D Jan 31 17:25:43 sveinse: you do have to be careful how you wire in something like that Jan 31 17:26:19 sometimes youer' better off doing that outside of bitbake,b efore the build stars, or with an event handler Jan 31 17:26:21 case by case Jan 31 17:26:23 So I build the system for that outside of bitbake. We are also building multiple MACHINES (which yocto didn't support at the time) Jan 31 17:26:26 sveinse: BuildStarted events are usually good although even there you can get one event per multiconfig Jan 31 17:26:35 :) Jan 31 17:27:42 But with the unfortunate effect that the layer on top of yocto gets thicker Jan 31 17:30:49 * sveinse has started on a document "Things I've learned about Yocto and bitbake" Jan 31 17:32:10 Are there any syntatical rules to version numbers in OE? I counldn't find any about it in the manuals Jan 31 17:32:29 Any character class rules? Jan 31 17:43:06 One example of confusion from the bitbake manual: "An advantage of the override style operations "_append", "_prepend", and "_remove" as compared to the "+=" and "=+" operators is that the override style operators provide guaranteed operations." Jan 31 17:43:40 The sveinse short interpretation of that is: "Use _append, _prepend and _remove" :P Jan 31 17:44:23 Not a word about why one should avoid or limit the use of them Jan 31 18:00:35 New news from stackoverflow: Disable Mender in Yocto Rocko for Beaglebone Black Install Jan 31 18:34:31 sveinse: sharing that would be interesting! Jan 31 18:35:16 sveinse: there's a regex buried for versions but basically its rpm's rule (as they're stricter than dpkg). or was it the other way around... Jan 31 19:05:09 rburton: if youre still around, the ninja update applied cleanly on top of master to me Jan 31 19:05:25 rburton: did you want me to rebase it on master-next or something? Jan 31 19:08:24 rburton: I just saw the patchtest email but this isnt making any sense to me Jan 31 20:36:01 oof, meta-ti, meta-fsl-ppc, and meta-oe all need to catch up on not using base_conditional Jan 31 20:36:04 didn't realize it was removed Jan 31 20:36:53 how do i open the manuals? tried opening mega-manual.xml but there is an error in the file, COPYRIGHTYEAR missing or something Jan 31 20:37:06 meta-selinux was broken by the removal of oe_filter_out too Jan 31 20:37:21 zarzar: do you not want to read it in your browser, or are you trying to modify the docs? Jan 31 20:37:31 read in browser Jan 31 20:38:04 https://pastebin.com/JPmZPckx Jan 31 20:38:50 all the docs are available at yoctoproject.org Jan 31 20:38:54 so.. **** ENDING LOGGING AT Thu Feb 01 03:00:03 2018