**** BEGIN LOGGING AT Thu Jun 07 03:00:04 2018
Jun 07 08:19:08 <eduardas_m> hello, I was wondering: what is the usual solution for getting battery level in a GUI on an embedded system? I am currently using upower and its d-bus interface, but perhaps there is a better solution?
Jun 07 08:23:47 <rburton> that sounds fine to me
Jun 07 08:23:56 <rburton> usual is a funny word in embedded
Jun 07 08:24:18 <rburton> if you know that you'll only have a single battery type etc etc then your UI can just read it directly
Jun 07 08:26:57 <eduardas_m> rburton: my problem with upower currently is that it does not seem to respect the CriticalPowerAction=PowerOff setting in UPower.conf for some reason, i.e. system does not power down after having reached the charge threshold I set
Jun 07 08:30:00 <eduardas_m> rburton: also, the only alternative middleware to upower I have found so far is the Mer Project (Sailfish OS) abstraction on top of sysfs and libudev the developers called statefs
Jun 07 08:30:27 <eduardas_m> which is basically undocumented
Jun 07 08:30:38 <rburton> i'd either debug the upower interaction to see why its not powering off, or just hit the sysfs directly from my UI
Jun 07 08:39:27 <eduardas_m> rburton: yes, direct interaction does come to mind... however, I sometimes wish there was some kind of hardware reference design + distribution that fully implements a handheld battery-powered touch-enabled device with a display...
Jun 07 08:39:32 <eduardas_m> because I am often confused what "best practices" mean for such a case in the embedded Linux space and what components/solutions should be used
Jun 07 08:40:07 <rburton> agreed, many years ago we had this (and poky/sato is the remnants, imagine that running on a sharp zaurus with full PIM suite and hardware integration)
Jun 07 08:59:13 <Saur> RP, kanavin_home, fray: Thanks for solving the mystery of the broken rpm yesterday. (Btw, yesterday was our national holiday here in Sweden.)
Jun 07 09:03:25 <RP> Saur: was an interesting puzzle...
Jun 07 09:05:15 <RP> rburton: I merged -next since we finally got the issues narrowed down. Have gcc8 in there for testing along with Bruce's kernel patches. Just some questions about the arm tunings :/
Jun 07 09:38:01 <rburton> RP: cool.  will rebase mut and sort it out, it's looking like a warzone right now
Jun 07 09:40:13 <RP> rburton: right, I'll try and focus on gcc 8. Looks like we have mpc8315e-rdb issues but its looking not too bad
Jun 07 10:51:30 <interruptguy_> Hello
Jun 07 10:52:02 <interruptguy_> how can I have a recipe task hash depending on a file content hash?
Jun 07 10:53:12 <RP> interruptguy_: put it in SRC_URI?
Jun 07 10:53:23 <interruptguy_> it is there
Jun 07 10:54:22 <interruptguy_> if I use bitbake-dumpsig .../recipe.sigdata.. do_install
Jun 07 10:54:54 <interruptguy_> I get this "This task depends on the checksums of files: []"
Jun 07 10:55:40 <RP> interruptguy_: have a look at do_fetch
Jun 07 10:55:51 <interruptguy_> ok
Jun 07 10:55:51 <RP> do_install depends on do_fetch
Jun 07 10:55:57 <RP> (indirectly)
Jun 07 10:56:09 <interruptguy_> you mean log?
Jun 07 10:56:19 <interruptguy_> ok
Jun 07 10:56:34 <RP> I mean run bitbake-dumpsig on the do_fetch sigdata instead of do_install
Jun 07 10:58:33 <interruptguy_> ok
Jun 07 10:58:35 <interruptguy_> let me check
Jun 07 11:00:22 <interruptguy_> doesn't seems so
Jun 07 11:00:46 <interruptguy_> "Hash for dependent task.. do_compile"
Jun 07 11:01:30 <interruptguy_> but also here the file checksum is missing
Jun 07 11:01:50 <RP> interruptguy_: what command did you run exactly?
Jun 07 11:03:33 <interruptguy_> bitbake-dumpsig tmp/stamps/cortexa9hf-neon-.../{recipe_name}/5.4.1-r12.0.do_fetch.sigdata.xxxxxx
Jun 07 11:04:59 <interruptguy_> wait I might made a mistake
Jun 07 11:05:01 <interruptguy_> jsut a sec
Jun 07 11:06:39 <dark-h> all: yocto package management has a version restriction (for shared libraries) that kills backward compatibility. This seems counter intuitive. Any insights and workaround?
Jun 07 11:07:02 <interruptguy_> RP, ok I can see the file signature there
Jun 07 11:11:20 <dark-h> bluelightning: hi, can you help with getting around version restriction in the IPKs?
Jun 07 11:14:12 <interruptguy_> RP, I can see that do_fetch.sigdata doesn't have a comment like "Task dependent....". I do see that do_unpack.sigdata contains a line "This task depends on do_fetch"
Jun 07 11:15:23 <RP> interruptguy_: that sounds right
Jun 07 11:15:36 <interruptguy_> However changing the configuration file (then one that the contents I want to be evaluated) doesn't trigger any re-checksum. do_fetch reports the same hash for the file
Jun 07 11:15:50 <interruptguy_> RP, ok. so where can the problem be?
Jun 07 11:17:27 <rburton> dark-h: how does it kill backwards compatibility?
Jun 07 11:18:14 <rburton> if a binary links to libfoo 1.2 then it depends on libfoo >= 1.2
Jun 07 11:18:46 <interruptguy_> RP, i did force an install signature invalidation "bitbake recipe -C install", but nothing happend
Jun 07 11:19:27 <rburton> success \o/
Jun 07 11:20:19 <interruptguy_> RP, uuu...I just realize that i'm using devtool to get the source files localy..and I think that's the reason
Jun 07 11:23:00 <RP> rburton: that makes a nice change! :)
Jun 07 11:23:31 <RP> rburton: so if we uprev the bsps and fix the mingw thing, we're nearly there with gcc8
Jun 07 11:23:38 <rburton> woo
Jun 07 11:23:51 <RP> I am wondering what to do about JaMa's tune concerns though :/
Jun 07 11:29:42 <dark-h> rburton: the auto-generated deps restrict it to '>=' to compile time version of e.g. a shared library
Jun 07 11:29:54 <rburton> yes
Jun 07 11:30:01 <rburton> as does every other linux distribution
Jun 07 11:30:12 <dark-h> rburton: in standard linux / libtool philosophy, that is not always the case
Jun 07 11:31:44 <rburton> oh right you mean how eg debian lets libraries say 'i may be 1.2.3 but my abi is 1.2.0 so use that in the depends'
Jun 07 11:32:14 <dark-h> rburton: exaclty
Jun 07 11:34:29 <rburton> dark-h: patches welcome :)  the shlib mojo is in package.bbclass, 'just' needs a way of overriding the version
Jun 07 11:34:46 <dark-h> rburton: here's a use case, I built an executable against a shared library 1.2.3, on my target I have 1.2.0 of the same library. I then try to upgrade the executable on target and it fails
Jun 07 11:35:19 <rburton> sure, if you can make the assertion that 1.2.x is ABI compatible then you'd like to clamp the dependency to >1.2.0
Jun 07 11:35:53 <rburton> a lot of our design is inspired by debian so no doubt how debian handles it would slip in nicely
Jun 07 11:38:04 <dark-h> rburton: thanks for the background. I will seee if I can help. I suspect the problem is more subtle for shared libraries due the to libtool style of versioning
Jun 07 11:38:17 <rburton> its basically manual work
Jun 07 11:39:05 <dark-h> rburton: at the moment, package.bbclass only looks at the recipe version rather than library version which may or may not be the same
Jun 07 11:39:47 <rburton> debian solves it like this: https://salsa.debian.org/gnome-team/cairo/blob/debian/master/debian/rules
Jun 07 11:40:07 <rburton> last three lines say that 1.14.0 is sufficient for abi compatibility
Jun 07 11:40:17 <rburton> and that overrides the version field in depends
Jun 07 11:40:32 <rburton> libtool version etc is mostly irrelevant, you just care about package version
Jun 07 11:41:49 <dark-h> rburton: i see - will try it out and create a patch
Jun 07 11:41:58 <dark-h> rburton: many thanks
Jun 07 11:44:13 <rburton> RP: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/3ce3e27f044935f19e93e80c43ca695262d484e1/
Jun 07 11:44:44 <rburton> there's quite a few gcc8 fixes, i wonder if they'll be releasing soon
Jun 07 11:46:12 <rburton> RP: patching now, will re-fire the qa-extras builder shortly
Jun 07 11:59:03 <rburton> oh there's also a 5.0.4 mingw to upgrade to
Jun 07 11:59:38 <rburton> of course some brave fool needs to make some automated qa for meta-mingw
Jun 07 12:02:00 <JaMa> RP: I don't want to block gcc8 just because of those tune concerns, but still feels wrong to change tunes, just because the special case which we have in gcc-runtime
Jun 07 12:02:44 <JaMa> and I agree with your concern that having to use _remove in oe-core also isn't the right way of resolving this
Jun 07 12:04:56 <JaMa> rburton: thanks for finishing those qemu bits and dropping the last change from you :)
Jun 07 12:05:09 <rburton> JaMa: :)
Jun 07 12:05:21 <rburton> JaMa: one recipe away from dropping libsdl1 from oe-core ;)
Jun 07 12:05:40 <rburton> (and its one that build with just a s/SDL/SDL2/ in configure.ac)
Jun 07 12:39:57 <syd> Hi! is this the right place to ask about bitbake use-related questions? :)
Jun 07 12:41:40 <LetoThe2nd> syd: its certainly not a very wrong place to start at :)
Jun 07 12:42:03 <syd> haha
Jun 07 12:43:07 <syd> well, i use bitbake to compile 2 images for an embedded system - regular and recovery
Jun 07 12:43:29 <LetoThe2nd> sounds like a common usecase :)
Jun 07 12:43:48 <syd> i added support for selinux by adding the meta-selinux metadata and adding "selinux" for distro features
Jun 07 12:43:59 <rburton> RP: fixed mingw locally, fired https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/1063
Jun 07 12:44:16 <syd> but i dont use selinux for my recovery image, and want to disable selinux for it
Jun 07 12:44:44 <LetoThe2nd> syd: sooooo your question is, actually?
Jun 07 12:45:04 <syd> i figured i cannot override distro features for one image (recovery) - (this is correct?)
Jun 07 12:45:31 <syd> so i tried to "downgrade" selinux to image-based feature - i.e. IMAGE_FEATURE
Jun 07 12:45:49 <LetoThe2nd> syd: thats correct. the reasoning is that a recipe (.bb, which your image is) cannot set things that are globally visible (DISTRO_FEATURES, for example)
Jun 07 12:45:52 <syd> but this is not trasferred on from my image recipe to all the dependent recipes
Jun 07 12:46:27 <rburton> syd: can you not have it enabled in your distro but just turn it off in the recovery bootloader?
Jun 07 12:46:37 <rburton> (and not install the policy etc)
Jun 07 12:46:40 <syd> so i guess the question is how can i get IMAGE_FEATURES of my recovery.bb image recipe to all the other dependet recipes?
Jun 07 12:46:58 <syd> nope
Jun 07 12:47:03 <LetoThe2nd> syd: basically it sounds very much like you want two distros
Jun 07 12:47:22 <syd> the biggest issue is busybox
Jun 07 12:47:31 <rburton> syd: two distros then
Jun 07 12:47:49 <syd> which compiles ones for both images, and requires all the libraries of selinux
Jun 07 12:47:51 <syd> hm
Jun 07 12:47:52 <syd> ok
Jun 07 12:48:03 <rburton> well options are 1) fix stuff so you can have selinux configured but disabled in your recovery or 2) two distros
Jun 07 12:48:12 <LetoThe2nd> who can share a big common chunk that they both include as a base conf file, and eacj just adds some minor tweaks
Jun 07 12:48:47 <syd> is it even possible for 2 images under same distro to compile twice the same recipe with 2 different configurations?
Jun 07 12:49:25 <RP> rburton: cool :)
Jun 07 12:50:57 <LetoThe2nd> syd: nope
Jun 07 12:51:12 <LetoThe2nd> syd: an image is a recipe, and cannot affect what happens in another recipe
Jun 07 12:51:35 <syd> thanks
Jun 07 12:52:09 <syd> letothe2nd,rburton: thanks, you guys helped a lot
Jun 07 12:52:36 <LetoThe2nd> syd: have fun
Jun 07 13:11:16 <yocti> New news from stackoverflow: Adding OpenCV to Yocto SDK for Host QtCreator <https://stackoverflow.com/questions/50741802/adding-opencv-to-yocto-sdk-for-host-qtcreator>
Jun 07 13:12:42 <mrk377> Using openembedded/webservers, what are recommendations in using either apache, cherokee, hiawatha, monkey, nginx, nostromo, or sthttpd?  I was wanting to use meteor and is there a recipe for meteor?
Jun 07 13:13:54 <LetoThe2nd> mrk377: for the first part of the question, it entirely depends on your usecase. for the secondary part, ask https://layers.openembedded.org/
Jun 07 13:14:13 <jof> nrossi: Have you ever come across a problem where a non-working boot.bin is generated for some reason?
Jun 07 13:14:44 <mrk377> First question:  I need to server just a few configuration web pages, and interact with PHP only.
Jun 07 13:15:00 <mrk377> I need to serve (oops)
Jun 07 13:15:32 <jof> nrossi: I was just preparing an SD-card to boot from, put the appropriate files on the first (FAT16) partition, but it doesn't boot. However, if I copy a boot.bin from another build that was previously working, then it works fine..?
Jun 07 13:16:08 <mrk377> It does not require a large footprint with 1000 of users.  I prefer one process/thread.
Jun 07 13:16:43 <jof> nrossi: And when I say "another build", I mean a different target. But that target has the same processor.
Jun 07 13:18:31 <LetoThe2nd> mrc3: it still just depends. if you are familiar with apache and can make it work easily and quickly, its a totally valid choice, we cannot judge your boackground and the whole of the usecase in discussion
Jun 07 13:18:44 <LetoThe2nd> mrk377: ^^^^^^
Jun 07 13:19:46 <LetoThe2nd> mrk377: and, the second answer is part of the first one. look at the layer index to see what server packages already exists. anything not in the layerindex (and to be honest, anything not either in poky or meta-openembedded) should be ruled out unless you have very specific needs.
Jun 07 13:20:05 <LetoThe2nd> mrk377: unless you either want to do the packaging and/or maintenance yourself
Jun 07 13:21:12 <kanavin> LetoThe2nd: I would suggest to start with lighttpd as it is readily available in oe-core
Jun 07 13:21:18 <kanavin> mrk377: ^^^^
Jun 07 13:22:07 <LetoThe2nd> kanavin: no objections from my side :-)
Jun 07 13:22:30 <mrk377> Thanks letothe2nd.
Jun 07 13:42:04 <nrossi> jof: ps7_init, that is board specific and is required to make a functional spl/boot.bin
Jun 07 13:43:40 <jof> nrossi: That's what I thought
Jun 07 13:44:59 <nrossi> jof: you can usually tell if its missing by the size of the boot.bin, if one is noticeably smaller, its missing that ps7_init code
Jun 07 13:47:52 * Crofton just spent yesterday morning buried in ps7 land
Jun 07 13:54:28 <jof> nrossi: They approx. same size. I may have messed up my ps7_init files the last time I updated.
Jun 07 13:54:51 <jof> nrossi: But thanks! Now I know I'm in the right track, i.e. checking my ps7_init files.
Jun 07 13:58:38 <armpit> RP or rburton, do you need the AB this evening ?
Jun 07 14:00:51 <rburton> armpit: i don't as i'll be in meetings all evening
Jun 07 14:01:05 <armpit> k
Jun 07 14:01:17 <luneff> hey guys! could someone suggest a tablet that does 4g and gps and is compatible with yocto at the same time?
Jun 07 14:03:50 <RP> armpit: only if we have new gcc8 patches to test, so probably not
Jun 07 14:04:07 <armpit> k
Jun 07 14:06:36 <rburton> RP: my mingw patches built with master-next
Jun 07 14:07:36 <rburton> RP: pushed to master
Jun 07 14:11:28 <yocti> New news from stackoverflow: raspberry pi 3 less than 1 second <https://stackoverflow.com/questions/50743424/raspberry-pi-3-less-than-1-second> || can't capture browser log using python, selenium and phantomjs <https://stackoverflow.com/questions/50743117/cant-capture-browser-log-using-python-selenium-and-phantomjs> || Yocto/Bitbake Path Variable for Append File Directory <https://stackoverflow.com/questions/50743109/yocto-bitbake-path-variable-fo
Jun 07 14:13:57 <jof> nrossi: How much smaller, btw?
Jun 07 14:15:23 <jof> nrossi: N.m. My non-working one is actually ever so slightly larger (304 bytes) than the one that works.
Jun 07 14:15:37 <nrossi> jof: depends, i haven't looked at zynq stuff in a while. I remember being about 1/2 the size if its missing the ps7_init code
Jun 07 14:16:18 <nrossi> jof: so like 100K with, 50K without
Jun 07 14:22:25 <jof> nrossi: Ok, thanks  :)
Jun 07 14:32:05 <boucman_work> hey all
Jun 07 14:32:42 <boucman_work> what is the correct way to have a recipe be dependant on the exact machine, not just the architecture ? (the opposite of allarch.bbclass) ? thx
Jun 07 14:33:12 <LetoThe2nd> boucman_work: have COMPATIBLE_MACHINE set, AFIAK
Jun 07 14:33:57 <LetoThe2nd> https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-COMPATIBLE_MACHINE
Jun 07 14:35:06 <boucman_work> aah right, thx
Jun 07 14:39:41 <tlwoerner> moto-timo: https://wiki.yoctoproject.org/wiki/Bug_Triage
Jun 07 14:41:34 <yocti> New news from stackoverflow: Custom recipe for mgetty in yocto project <https://stackoverflow.com/questions/50743641/custom-recipe-for-mgetty-in-yocto-project>
Jun 07 14:42:08 <moto-timo> https://www.yoctoproject.org/docs/2.5/bsp-guide/bsp-guide.html
Jun 07 14:46:30 <JaMa> boucman_work: PACKAGE_ARCH = "${MACHINE_ARCH}"
Jun 07 14:47:17 <JaMa> boucman_work: COMPATIBLE_MACHINE is just to restrict for which MACHINEs the recipe can be built (but doesn't set the package arch
Jun 07 14:47:54 <boucman_work> i'll try that, thx
Jun 07 14:51:23 <boucman_work> anybody knows about this error ?
Jun 07 14:51:26 <boucman_work> ERROR: core-image-minimal-packaged-1.0-r0 do_prepare_recipe_sysroot: The file /usr/include/aliases.h is installed by both glibc-initial and glibc, aborting
Jun 07 14:51:53 <boucman_work> is that just a case of "rebuild everything" ? or is there something else going on...
Jun 07 14:59:29 <boucman_work> sorry, computer problems :(
Jun 07 15:11:41 <yocti> New news from stackoverflow: Issue when integrating different bsp-layers on a single bblayers.conf <https://stackoverflow.com/questions/50744231/issue-when-integrating-different-bsp-layers-on-a-single-bblayers-conf>
Jun 07 17:12:30 <khem> boucman_work: which release ?
Jun 07 17:13:15 <khem> boucman_work: only one of them should provide it
Jun 07 17:14:04 <khem> and it should be glibc recipe which should be the one so adding rm -rf ${D}${includeddir}/alias.h in do_install of glibc-initial recipe might be in order
Jun 07 18:22:07 <rschaefe> Hi All. I'm trying to build debug libraries of only qtwebengine. I have come across DEBUG_BUILD variable, which I think enables debug builds for all packages. Is there a way to specify which packages are built as debug
Jun 07 19:12:30 <yocti> New news from stackoverflow: How to raspberry pi 3 less than 1 second boot? <https://stackoverflow.com/questions/50743424/how-to-raspberry-pi-3-less-than-1-second-boot>
Jun 07 21:00:23 <khem> rschaefe: usually debug info is always built along, so you can add that to your image via IMAGE_INSTALL are you also looking to use lower optimization level so you can get better debug view ? if not then something like IMAGE_INSTALL_append = " <recipe>-dbg" might be enough
Jun 07 21:01:00 <khem> also note that its going to pull in debug info for dependent packages as well. Since it will otherwise not be able to give you full view
Jun 07 21:03:27 <khem> but if you just want it for this one package and are ok with all other constraints you can instruction it to not strip debug info into seprate package set INHIBIT_PACKAGE_DEBUG_SPLIT = "1" and INHIBIT_PACKAGE_STRIP = "1"
Jun 07 21:03:52 <khem> and that will make existing package contain this info for this recipe alone
Jun 07 23:20:59 <rschaefe> khem: are the debug versions included in the sdk, so if I get a core dump from a target, and I can load the debug symbols with only the sdk? Or do I need to explicitly add these to the sdk
Jun 08 01:15:22 <khem> rschaefe: I think only dev packages are included
**** ENDING LOGGING AT Fri Jun 08 03:00:18 2018