**** BEGIN LOGGING AT Fri Nov 01 03:00:13 2019
Nov 01 11:02:21 <kayterina> hello, hello
Nov 01 11:03:04 <LetoThe2nd> hell-o, hell-o
Nov 01 13:01:48 <kayterina> so...mfgtool v2.7. how does it work? why does it need an mfg-kernel and mfg uboot?
Nov 01 13:18:03 <litb> quick question.. in uninative.bbclass there's an event handler that fires for event ConfigParsed.
Nov 01 13:18:20 <litb> it's a bitbake-style python function. and its only line is to call a normal python defined below it. what use does this have?
Nov 01 13:33:07 <kroon> litb, that function is used in another place aswell
Nov 01 14:13:36 <litb> quick question... in https://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html there are some useful things like description of meta-ide-support
Nov 01 14:13:57 <litb> but adt-manual seems to be outdated/deprecated because it belongs to yocto version 1.1 ?
Nov 01 14:14:04 <litb> https://www.yoctoproject.org/docs/latest/sdk-manual/sdk-manual.html doesn't include those infos anymore, though
Nov 01 14:20:43 <LetoThe2nd> litb: adt, meta-toolchain and the eclipse plugin are totally outdated and unsupported by now
Nov 01 14:20:56 <litb> ah, I see!
Nov 01 14:22:01 <LetoThe2nd> i actually think that anybody offering a good dev experience based on OE, nice IDE integration , maybe even on windows, would have a serious sales pitch
Nov 01 14:31:47 <litb> LetoThe2nd, yeah with nice GUI for devtools and reintegration support into the layers.. that would be cool.
Nov 01 14:32:00 <LetoThe2nd> litb: make up, sell, profit!
Nov 01 15:04:13 <litb> This does not work, I suspect, in a bb that inherits siteinfo ?    OVERRIDES .= ":bits-${SITEINFO_BITS}"      FOO_bits-32 = ...   FOO_bits-64 = ...    , because overrides are applied before running anonymous python functions
Nov 01 15:04:32 <litb> and SIZEINFO_BITS is set in an anonymous python function within siteinfo.bbclass
Nov 01 15:05:06 <litb> I'm not using the MACHINEOVERRIDES  x86  and x86-64  because they won't work when building the recipe for -native and nativesdk-
Nov 01 15:25:15 <d_thomas> I'm building the AT91Bootstrap bootloader through Yocto.  The *.inc file is setting the default configuration, but I would like to change it.  What is the best way to do that?  Create a .bbappend file to modify *.inc file?  Run menuconfig before the build?  Something else?
Nov 01 15:36:14 <armpit> d_thomas, just, you can "patch" the default config with the changes you need
Nov 01 15:36:37 <armpit> bbapend the bootstrap recipe
Nov 01 15:37:20 <d_thomas> So I could change a variable from the inc file in a bbappend?
Nov 01 15:38:08 <kergoth> including a .inc is no different than putting its content int he recipe itself
Nov 01 15:38:18 <kergoth> and a bbappend is just like concatenating those lines to the recipe
Nov 01 15:38:26 <kergoth> so short answer yes
Nov 01 15:38:59 <d_thomas> Okay.  The source was providing a .bb file and an .inc file.  I just wanted to follow "best practices" for changing it.  I'll go with a bbappend file.
Nov 01 15:39:24 <d_thomas> thanks!
Nov 01 15:45:48 <kergoth> yeah, there's no way to directly append a .inc, so that's the only viable option in most cases
Nov 01 15:50:52 <yocti> New news from stackoverflow: apt-get returns 100 when bitbaking meta-toolchain-qt5 <https://stackoverflow.com/questions/58661863/apt-get-returns-100-when-bitbaking-meta-toolchain-qt5>
Nov 01 15:53:19 <fullstop> I have a commercial package with a bunch of shared libraries that are pre-built, so I can't get them versioned properly with sonames.  I have it set up as a package and the .so files are in the regular package and the .h files are in the -dev package.
Nov 01 15:53:58 <fullstop> How can I get the .so files also in the -dev package without the symlink and qa checks failing?
Nov 01 15:59:36 <kergoth> FILES_${PN} += "${libdir}/*.so"
Nov 01 15:59:37 <kergoth> FILES_SOLIBSDEV = ""
Nov 01 16:00:57 <kergoth> er, misread
Nov 01 16:01:04 <kergoth> the above will move the non-symlink .so to the main package
Nov 01 16:01:37 <kergoth> that and/or use of INSANE_SKIP_${PN} to disable explicit qa checks should get you where you want to be one way or the other
Nov 01 16:04:37 <fullstop> i'll give that a shot
Nov 01 16:06:01 <LetoThe2nd> inoffiall end-of-lyon dinner: ~18:00 at the brew brothers
Nov 01 16:48:45 <fullstop> okay, so I'm following https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries which seems to be what kergoth was referring to.. I have no symlinks and everything is just a plain old .so file.
Nov 01 16:49:35 <fullstop> If I follow that guide, I end up with the libraries in the target filesystem, and that's great -- exactly what I want!
Nov 01 16:50:25 <fullstop> Is there a way to include those .so files in the recipe-sysroot so that another recipe / package can link to them?
Nov 01 16:56:53 <kanavin> fullstop, yes - if that recipe DEPENDS on the recipe that packages the libs, they should appear in that recipe's sysroot prior to building
Nov 01 16:57:35 <fullstop> kanavin: when I tried that only the .h files were present, since the .so files were not part of the -dev package
Nov 01 17:04:18 <kanavin> fullstop, the sysroot population is separate from packaging and has own rules
Nov 01 17:04:29 <kanavin> fullstop, where do the .so libs go to during install?
Nov 01 17:11:22 <fullstop> kanavin: /opt/nvidia/deepstream-4.0/lib/*.so
Nov 01 17:12:54 <rburton> *sigh&
Nov 01 17:13:04 <fullstop> sorry, rburton
Nov 01 17:13:06 <rburton> dear everyone: put libraries in the proper place
Nov 01 17:13:16 <rburton> fullstop: can you put them into /usr/lib where they're meant to go?
Nov 01 17:13:26 <fullstop> I can relocate them with a bit of effort.
Nov 01 17:13:28 <rburton> if not then add SYSROOT_DIRS += "/opt/" to the recipe
Nov 01 17:14:09 <fullstop> let me ensure that none of the deepstream binaries have rpaths
Nov 01 17:14:50 <rburton> oh they probably do, people who release binary software tend to do it wrong wherever they can
Nov 01 17:15:27 <fullstop> good news!  They don't!
Nov 01 17:16:41 <neverpanic> How did that work then in the first place? LD_LIBRARY_PATH or modified ld.so.conf?
Nov 01 17:17:06 <rburton> i'm gussing probably ld.so.conf
Nov 01 17:17:42 <fullstop> nvidia provides an ubuntu image with no way to rebuild it.  That's why I'm using yocto.  I think that the original ubuntu image has ld.so.conf changes.
Nov 01 17:17:57 <rburton> niiiiice
Nov 01 17:18:03 <rburton> see i said when there's a way to do it wrong, they will
Nov 01 17:18:20 <fullstop> it's the nvidia way
Nov 01 17:18:36 <fullstop> but at least there is some linux support, right?
Nov 01 17:18:37 <rburton> i endorse forcing the packaging to be traditional as much as possible
Nov 01 17:19:18 <fullstop> rburton: I sometimes worry about, and it's likely misguided, namespace collisions in /usr/lib/
Nov 01 17:19:52 <rburton> fullstop: valid if theyve named the libraries something silly. your call
Nov 01 17:21:01 <neverpanic> even then, /usr/lib/nvidia/ would probably be a better place, no?
Nov 01 17:21:10 <yocti> New news from stackoverflow: Customizing U-boot serial prompt messages <https://stackoverflow.com/questions/58663248/customizing-u-boot-serial-prompt-messages>
Nov 01 17:21:20 <rburton> neverpanic: yeah
Nov 01 17:21:26 <fullstop> I might do that
Nov 01 17:23:09 <neverpanic> FWIW, $employer built a pretty big system using Yocto with its fair share of precompiled binaries, and we don't need an /opt folder either.
Nov 01 17:23:35 <neverpanic> No conflicts that I'm aware of. A couple of libs duplicated in ${libexecdir} in combination with PRIVATE_LIBS, but that's about it.
Nov 01 17:25:07 <rburton> libraries in $libexecdir, of course
Nov 01 17:25:38 <neverpanic> I'm not sure about the details of it, but some ${PN}-local dir, at least.
Nov 01 17:26:15 <neverpanic> libexecdir used to be libdir/BPN anyway for Yocto
Nov 01 17:28:24 <rburton> indeed
Nov 01 17:34:21 <fullstop> rburton, kanavin (even though you dropped), neverpanic, kergoth: thanks a million, putting things in /usr/lib is definitely the way to go.
Nov 01 17:44:37 <turnip420> How are modules loaded on boot? I don't have a /etc/modules-load.d/ dir
Nov 01 17:47:08 <rburton> kernel autoloads
Nov 01 17:47:43 <rburton> the usual userspace tools exist, so write files as you usually would if you want to force stuff to load
Nov 01 17:56:01 <turnip420> rburton: So the kernel just finds all the ko files and loads them? All mine seem to live here /lib/modules/3.14.79+gc720cc0
Nov 01 17:56:26 <rburton> turnip420: yocto behaves exactly as eg ubuntu in this
Nov 01 17:57:34 <turnip420> https://manpages.ubuntu.com/manpages/bionic/man5/modules.5.html
Nov 01 17:57:45 <turnip420> However I don't have a /etc/modules file
Nov 01 17:59:25 <rburton> make one
Nov 01 17:59:45 <rburton> also fwiw, my core-image-minimal has a /etc/modules-load.d/ directory
Nov 01 18:00:00 <rburton> (because meta-intel drops a i915 file in there)
Nov 01 18:01:56 <turnip420> I have a modprobe.d
Nov 01 18:01:58 <turnip420> dir
Nov 01 18:06:55 <turnip420> Added my wifi driver ko to that file, comes up, still no wlan0 :(
Nov 01 18:07:00 <turnip420> rburton: thanks for the help
Nov 01 18:07:12 <rburton> wifi driver should be auto-loaded unless the driver is terrible
Nov 01 18:09:42 <turnip420> Hmm
Nov 01 18:12:10 <turnip420> I'm assuming the wifi driver needs to come up before mac80211 and cfg80211, because right now I think it's coming up after. Also it doesn't seem to be autoloading
Nov 01 20:22:41 <d_thomas> I'm using the meta-atmel layer.  I would like to upgrade the version of u-boot.  Should I create a *.bb file in my layer similar to what meta-atmel is using or should I create a *.bbappend file that updates the SRCREV, PV, etc. fields?
Nov 01 20:22:59 <d_thomas> What is the correct approach here?
Nov 01 20:25:21 <LetoThe2nd> d_thomas: it depends (TM)
Nov 01 20:26:43 <LetoThe2nd> d_thomas: for smaller version bumps, a bbappend might be fine. a version upgrade usually should get a complete, derived recipe set IMHO
Nov 01 20:32:53 <d_thomas> Hmmm... I'm going from 6.0 to 6.2, but the dates in the recipe change from 2018.07 to 2019.04.
Nov 01 20:37:54 <LetoThe2nd> d_thomas: i guess the 6.0 -> 6.2 is the atme sinux4sam version scheme, shich actually matters for nobdy
Nov 01 20:38:33 <d_thomas> As it is, the build didn't pick up my new version.  Gotta figure that out
Nov 01 20:38:41 <d_thomas> It still built the old version from meta-atmel
Nov 01 20:38:58 <LetoThe2nd> and a version bump u-boot 2018.07 -> 2019.04 certainly is to be considered major and deserves a proper, fresstanding recipe IMHO
Nov 01 20:39:36 <LetoThe2nd> bitbake -e it and see if PREFERRED_VERSION is being set sometwhere you don't expect, or if theres a MACHINE_COMPATIBLE marking that does something.
Nov 01 20:39:37 <d_thomas> That's kind of what I thought.  I wanted the recipes to be clear as to what they were building
Nov 01 20:42:31 <d_thomas> I see some PREFERRED_PROVIDER comments about it
Nov 01 20:52:31 <d_thomas> Does it matter where my *.bb file is located?  I have it in my own custom layer.
Nov 01 20:53:50 <LetoThe2nd> that alone does not matter
Nov 01 20:54:23 <LetoThe2nd> if its not built even if you expect it, then probably something does not allow it.
Nov 01 20:56:29 <d_thomas> Otherwise standard procedure is to build the latest version determined by some method?
Nov 01 20:56:56 <LetoThe2nd> yes
Nov 01 21:03:00 <LetoThe2nd> bitbake -e it und look at the PV evaluation
Nov 01 21:03:54 <d_thomas> PV evaluation?
Nov 01 21:04:22 <d_thomas> u-boot does not have a PREFERRED_VERSION if that is what you mean.  Perhaps it's rejecting my recipe
Nov 01 21:07:50 <LetoThe2nd> no, i mean exactly what i wrote.
Nov 01 21:08:17 <LetoThe2nd> bitbake -e the u-boot build and look at the PV evaluation
Nov 01 21:09:37 <d_thomas> PV="v2018.07-at91+gitAUTOINC+1e7d2e5973", it's getting set
Nov 01 21:10:29 <LetoThe2nd> this is the old version. and whats the evaluation history above it?
Nov 01 21:10:50 <d_thomas> Yes, that's the old version
Nov 01 21:10:52 <d_thomas>  7085 # $PV [4 operations] 7086 #   set /home/daren/work/poky/meta/conf/bitbake.conf:203 7087 #     "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" 7088 #   set /home/daren/work/poky/meta/conf/documentation.conf:338 7089 #     [doc] "The version of the recipe. The version is normally extracted from the recipe
Nov 01 21:10:52 <d_thomas> filename." 7090 #   set /home/daren/work/poky/meta/classes/sstate.bbclass:21 7091 #     [vardepvalue] "${PV}" 7092 #   set /home/daren/work/meta-atmel/recipes-bsp/u-boot/u-boot-at91_2018.07.bb:8 7093 #     "v2018.07-at91+git${SRCPV}" 7094 # pre-expansion value: 7095 #   "v2018.07-at91+git${SRCPV}" 7096 PV="v2018.07-at91+gitAUTOINC+1e7d2e5973"
Nov 01 21:10:59 <d_thomas> sorry, that's a mess
Nov 01 21:12:53 <LetoThe2nd> my guess is that something in the recipe does not allow it being built for your specific machine, or the distro/machine in use point to the old verson
Nov 01 21:13:54 <d_thomas> It doesn't appear to be even looking in my meta-custom layer
Nov 01 21:14:07 <LetoThe2nd> hum. have you added it to bblayers.conf?
Nov 01 21:14:12 <d_thomas> yes
Nov 01 21:14:25 <d_thomas> I"m building other packages from that layer
Nov 01 21:14:45 <LetoThe2nd> is the recipe fulfilling the regex recipes-*/*/*.bb?
Nov 01 21:15:10 <d_thomas> yes, I copied the name and path from meta-atmel before changing the version numbers
Nov 01 21:15:44 <d_thomas> in fact, I have a .bbappend file for the old version that building.... just didn't work on my board which is why I'm trying to upgrade
Nov 01 21:16:23 <LetoThe2nd> so again, you have checked that your recipe sets compatible machine accordingly?
Nov 01 21:16:24 <d_thomas> so the path should be good
Nov 01 21:16:48 <LetoThe2nd> you can also put it in a pastebin, u-boot is usually no big secret
Nov 01 21:17:21 <d_thomas> yes, it does
Nov 01 21:17:44 <d_thomas> I copied the recipe for the old version from meta-atmel
Nov 01 21:18:10 <d_thomas> changed two version numbers, the SRCREV value, and updated the require path
Nov 01 21:19:18 <d_thomas> https://pastebin.com/53Jj7e9K
Nov 01 21:20:45 <LetoThe2nd> d_thomas: and absolutely nothing sets like PREFEREED_VERSION_u-boot-...?
Nov 01 21:24:51 <d_thomas> not that I've found
Nov 01 21:25:28 <d_thomas> If I can't figure this out, I will try to set it myself.... but I'd kind of like to understand what I'm missing here
Nov 01 21:44:50 <d_thomas> Well that's frustrating, even the preferred version I set appears to be ignored
Nov 01 21:53:39 <LetoThe2nd> i'm certain it could be spotted, but without knowing the rest of the layer and machine/distro files at *I* am out of ideas. and you are certainly not doing anyhitng in local.conf? or have leftovers from devtool?
Nov 02 00:22:22 <yocti> New news from stackoverflow: YoctoProject: change ownership of all files in a recipe <https://stackoverflow.com/questions/44935074/yoctoproject-change-ownership-of-all-files-in-a-recipe>
**** ENDING LOGGING AT Sat Nov 02 02:59:57 2019