**** BEGIN LOGGING AT Tue Aug 27 02:59:57 2019 Aug 27 04:01:23 /msg aehs29 a friend even sent me the survey link so I could complain with him and no power in the embedded hacking room Aug 27 07:38:57 New news from stackoverflow: Installing a precompiled library that depends on another in a bitbake recipe Aug 27 07:49:08 good morning Aug 27 07:53:02 mckoan: mostly yes, indeed! Aug 27 07:55:00 :) Aug 27 07:56:10 mckoan: btw, you coming to lyon too? Aug 27 07:59:33 why do I have warning message? https://pastebin.com/5Sw0UEug Aug 27 08:15:00 LetoThe2nd: yes of course Aug 27 08:15:21 112 Aug 27 08:15:39 hahaha, ignore that, serious lag on this connection :D Aug 27 08:17:10 Proffalken: hi.. sorry for me not getting back to you, didn't find any time to look at the layer. my bad. Aug 27 08:17:14 mckoan: \O/ Aug 27 08:17:54 LetoThe2nd: No worries, I've been sunning myself by a pool and listening to Cricket, feeling incredibly guilty that I wasn't doing any work! :D Aug 27 08:18:24 Proffalken: Hooray! Crickets! Aug 27 08:22:07 Should clarify just incase - I'm talking about the sport, not the insect! ;) Aug 27 08:22:26 I'm talking about the insects. Just to clarifiy! Aug 27 08:23:20 \o/ Aug 27 08:24:31 Proffalken: so, maybe i can have a peek laters. but it certainly wouldn't hurt if you repeat the paste here, tuesday is usually a good day for folks being around. Aug 27 08:25:10 OK, thanks for the heads-up Aug 27 08:25:25 Proffalken: good luck! Aug 27 08:28:03 I'm having issues adding a new layer to a custom image I'm trying to build. The code and output from Jenkins is at https://gist.github.com/proffalken/972d8f180d7371713c8f589688486838 Aug 27 08:28:11 The code I'm trying to add the layer to is https://github.com/brocaar/lora-gateway-os Aug 27 08:28:25 and I have this as a submodule of my "parent" repo Aug 27 08:28:50 The new layer is discovered, however none of the .bb files are found Aug 27 08:30:59 Proffalken: what have you done to make the new layer be discovered? Aug 27 08:31:59 Hi Aug 27 08:32:51 I am currently trying to find the related Issue to this patch http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch?h=master Aug 27 08:33:17 The commit message says it closes #12504 and mentions #12505 Aug 27 08:33:52 If i go to bugzilla.yoctoproject.org and search for these issues, both of them are there but have nothing to do with this patch Aug 27 08:34:36 i would like to backport these patches to systemd 241 to be able to use systemd link up in the warrior release Aug 27 08:34:55 can anybody help me here and point me into the right direction? Aug 27 08:43:24 qschulz: https://gist.github.com/proffalken/972d8f180d7371713c8f589688486838#file-bblayers-conf-L28 points to the directory that contains the layer in bblayers.conf, and the error message is WARNING: No bb files matched BBFILE_PATTERN_meta-telegraf '^/media/yocto/jenkins/jenkins-meta/jenkins-meta/workspace/eway-os_feature_install_telegraf/lora-gateway-os/build/../../mbc-layers/meta-telegraf/' Aug 27 08:45:54 Note - I'm new to both Yocto and Bitbake, never had to use it until now, but the docs don't seem to cover this particular use-case where the new layer is outside the existing ones because of how the repo is organised Aug 27 08:46:05 s/is/needs to be/g Aug 27 08:47:48 Proffalken: nope, that shouldn't be a problem. the paths are meant to be completely arbitrary. what i rather guess is that the regex in layer.conf doesn't match for some reason, but i need a longer look. Aug 27 08:48:29 Cool, at least it's not likely that then, really appreciate all the help :) Aug 27 09:03:30 Hello. Is there are simple way to determine a package's dependencies within a recipe? Aug 27 09:03:44 deuteron: "within a recipe"? Aug 27 09:04:42 Yes. I have some recipe that I want to produce a zip file of some ipks and their dependencies. Aug 27 09:05:41 sounds very much like an XY-problem Aug 27 09:05:51 What's that? Aug 27 09:06:17 Oh, right. Aug 27 09:06:31 you are trying to solve problem X, and think that Y is a way to do that. you struggle with doing Y, so you ask us about Y. why not just ask about X? Aug 27 09:07:14 Basically, I want to delay installing some packages until install time. Aug 27 09:07:24 I don't want to bake them into the image. Aug 27 09:08:17 https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-EXTRA_IMAGEDEPENDS ? Aug 27 09:08:46 Packages are built but not installed in the rootfs Aug 27 09:09:14 New news from stackoverflow: YOCTO : can't insert linux module to the kernel : versions are different Aug 27 09:09:39 i see. what qschulz mentioned should suffice for triggering the build. then you can either install them though an accessible package repository, or copy them onto the target. Aug 27 09:09:40 you should have them in tmp/deploy/{ipk,rpm,deb} (depending on your package manager) Aug 27 09:10:28 deuteron: the problem i see with your packaging approach is, where do you stop? most things ultimately depend on the libc, kernel, or comparable essential things of the infrastructure. Aug 27 09:11:51 Well the rootfs has 90% of things. Aug 27 09:12:26 But for some installers we would like to have dropbear, say. So I need to find the dropbear dependencies that aren't already in the rootfs to be bundled with the installer also. Aug 27 09:12:34 deuteron: yeah buit how does your zipping process where to stop? if it just walks the dependency tree, it has no idea about what is already there, and what not. Aug 27 09:12:59 LetoThe2nd: Sure, in theory it could bundle EVERYTHING, but in practise that won't happen. Aug 27 09:13:23 deuteron: see, and thats where things start to be complicated. Aug 27 09:13:55 deuteron: the simplest solution would certainly be if you can use a network based package repository, so the package manager just pulls what it needs. Aug 27 09:14:30 deuteron: next in line probably would be a static build of the desired packages. it adds to the space consumption, but makes it self-contained. Aug 27 09:16:01 Network access is not available on non-development devices. Aug 27 09:16:28 The second option is what we already have and it's too slow. We have to build 6 or so different rootfs and then 6 installers. Aug 27 09:17:03 So, I'm trying to build a single installer, that can then be stripped down as needed just using 'zip -d ...' Aug 27 09:17:22 deuteron: then you will need some pretty convuluted logic to tell the zipper what to include and what not. Aug 27 09:17:40 No, that part is easy and already works. Aug 27 09:17:45 I just need the dependency tracking. Aug 27 09:18:02 but i'd probably do that external to bitbake, just reach into the package deploy folder, look at the package dependencies and then rcurse. Aug 27 09:18:25 So that when I say the installer needs to bundle 'bash' I don't need to say 'and libreadline, etc.' Aug 27 09:18:36 LetoThe2nd: Yes, I'm starting to think that too. Aug 27 09:18:37 please read again what i just wrote :) Aug 27 09:19:09 It's not convoluted, this is simple stuff. Package A depends on package B. Aug 27 09:19:25 and for that thing that would do such, have a list provided that tells it what is already installed. that could be derived from the image manifest Aug 27 09:19:47 deuteron: the mindset is simple of course. the rest is not. Aug 27 09:20:12 deuteron: https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527 Aug 27 09:20:34 No. The package manager exists. Yocto already does all this stuff. Aug 27 09:20:44 if you believe so Aug 27 09:21:22 that zip-up-thing is basically a dependency walking package manager right on top of the yocto one. Aug 27 09:21:26 All the dependency information is there already. It's just not obvious how to access it. Aug 27 09:21:36 so its not trivial(TM) Aug 27 09:21:56 I've already done this once to produce subsets of SDKs. Aug 27 09:22:22 It was quite easy to just walk the dependencies. Aug 27 09:22:33 i don't say it can be done. i'm just saying its more complicated than "A depends on B". if we're talking general purpose, not only trivial subsets. Aug 27 09:22:48 typo. i'm not saying it can't be done. Aug 27 09:22:54 What would be a non-trivial subset? Aug 27 09:24:55 deuteron: non-trivial subsets would probably be anything where the dependency graph contains closed areas, as a first tought. Aug 27 09:25:12 deuteron: but i'm no specialist there. for examples of problems to hit, read that article. Aug 27 09:26:22 its of course entirely possible that many of those do not apply to your specific use case. hence the expression "general purpose" earlier. Aug 27 09:27:18 This guy is insufferable. Aug 27 09:27:20 deuteron: I see that you have no network but maybe you have other ways to have "temporary" sources (like a USB stick?). Then you just put tmp/deploy/ipk on this stick, attach it to the target and run the package manager which will figure out the dependencies by itself Aug 27 09:27:36 qschulz: ++ Aug 27 09:27:38 qschulz: That's basically what we're doing. Aug 27 09:27:53 But I'm trying to avoid having to specify ALL the packages that need to go on the USB stick. Aug 27 09:28:29 get a big USB stick and spare days/weeks worth of work? Aug 27 09:29:01 For example, if I want to install 'bash' from the usb after unpacking the rootfs onto the device, then I need to include libreadline (or w/e) also. Aug 27 09:30:13 But I'm trying to avoid having to manually specify that libreadline needs to be bundled with the installer. Aug 27 09:30:15 deuteron: `opkg depends packagename` would provide such a thing (but I don't know if it resolves dependencies of depdencies). Also pckg manager specific :/ Aug 27 09:30:59 I just figured yocto spends so much loading caches and other stuff before it actually does anything that this information is *surely* readily available. Aug 27 09:31:00 then you put this process in the image recipe after everything Aug 27 09:33:31 Well, I'm out of time today. Better luck tomorrow, I guess. Aug 27 09:33:37 qschulz: LetoThe2nd: Thanks for your time. Aug 27 09:33:56 good luck Aug 27 10:32:36 I have noticed that http://layers.openembedded.org/layerindex/api/recipes/ is not available. Is that just temporary? Aug 27 10:34:14 halstead: ^^^^^^^^ Aug 27 10:41:06 ralu: admin says he'll look into it, but will take some time, sorry. Aug 27 10:44:02 Ok, thank you! Aug 27 10:44:30 yw Aug 27 11:08:59 Proffalken: I don't know honestly, it looks ok to me. Hopefully LetoThe2nd or anyone else knowing a little bit more about this will be able to help :) Aug 27 11:09:32 New news from stackoverflow: /dev/fd/ socket or pipe links fail, NOT missing /dev/fd link Aug 27 11:10:25 it's not possible anymore to use AUTOREV with svn ? --> https://pastebin.com/siTKFpMe This recep works only if SRCREV is defirrent of AUTOREV any advice ? :S Aug 27 11:16:33 define "works only" Aug 27 11:17:08 also, https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-AUTOREV you need to override PV to have SRCPV in it Aug 27 11:18:33 qschulz --> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, | /usr/bin/env: 'svn': No such file or directory Aug 27 11:20:17 qschulz after added PR = "r0" thx for advice I have read the doc to fast ;) Aug 27 11:22:19 I was talking about PV, not PR. these are two different things Aug 27 11:23:25 I don't know much about PR, but you definitely need to set PV with SRCREV in it otherwise Yocto does not know when to rebuild (or something like that, Yocto is broken if you don't do it from my experience) Aug 27 11:32:55 qschulz Okay it's was a trap :P I don't really understand what's append with autorev but could please explain how to set this variable ? o.0 Aug 27 11:35:13 SRCREV = "${AUTOREV}" and PV = "+git${SRCPV}" (sorry typo, I meant to say SRCPV and not SRCREV earlier) Aug 27 11:35:51 (you don't need +git in PV, it's just what I do) Aug 27 11:36:00 qschulz yep thx no prob for typo ;) Aug 27 11:36:38 I don't know exactly, but IIRC there is some mechanism to detect when a rebuild is required that is based on PV Aug 27 11:37:06 with SRCREV set to autorev, this PV is not updated or something like that, and Yocto fails to detect the update Aug 27 11:37:48 that's extremely vague because I don';t know what I'm talking about and if that is actually true Aug 27 11:38:03 anyway, no PV="+git${SRCPV}" it failed for me Aug 27 11:39:15 same here, I don't know exactly what's happening but PR is for package managers on the target to know if the package you want to install is of a newer version of the currently installed one, same version or below. Usually default behavior is to not install a package which has the same version or lower version. Aug 27 11:39:27 when you change PR in Yocto you trigger a rebuild I think Aug 27 11:39:47 But please, anyone, correct anything I'm saying. It's just assumptions I making here from my little experience Aug 27 11:41:13 qschulz Yes don't worry about that, I nedd just 1 or 2 clues in order to fix my recipe, but PV="+git${SRCPV}" doesn't work on my side :S Aug 27 11:41:51 logs :) Aug 27 11:42:58 And I most likely won't be of any more help anyway since I've experience only with git but SRCREV and PV aren't stated as git specific in any way. But logs, or explain more the "doesn't work" so people can help you :) Aug 27 11:44:27 qschulz: no worries, thanks for looking, kinda glad it looks ok to you as well, I've been tearing my hair out over here! :D Aug 27 11:46:46 qschulz https://pastebin.com/Yzhz02Z3 Aug 27 11:47:07 qschulz that's my trouble ^^ Aug 27 11:47:22 qschulz it's really strange any trouble with git sources :S Aug 27 11:51:18 PinkSnake: what's the content of your recipe now? Aug 27 11:52:43 qschulzhttps://pastebin.com/y4Y32G6G Aug 27 11:53:41 it's complaining it can't find svn Aug 27 11:53:49 /usr/bin/env: 'svn': No such file or directory Aug 27 11:54:31 is svn not in the $PATH used by Yocto? Aug 27 11:54:42 yes but if I replace AUTOREV with a revision number everything works as expected Aug 27 11:55:00 subversion ... :S Aug 27 11:58:41 PinkSnake: I'm clueless sorry. SRCPV triggers the @bb.fetch2.get_srcrev(d) function which is supported by svn fetcher apparently. This function calls /usr/bin/env svn and can't find svn but that's already the same command that is used to fetch the repo so it should have never worked in the first place (if that is the only issue) Aug 27 12:00:00 Proffalken: can't seem to reproduce it, sorry. what comes to my mind is maybe somthing happening as this is in a jenkins build with does magic, and the path is really, really long. do you also see the warning if you try manually? Aug 27 12:58:27 Good morning Aug 27 13:10:48 Good morning all, has anyone tried to change partition owner on a partition created using .wks? Aug 27 13:11:09 As per this link https://lists.yoctoproject.org/pipermail/yocto/2016-November/032973.html it seems possible Aug 27 13:11:47 but I'm trying to do this without success, partition is always owned by root:root (I'm on Yocto Warrior) Aug 27 13:17:30 ms_k: I did something like this previously when required to create a separate partition for 'home', however in that case, it was the contents of home that had a different ownership, not home itself. Aug 27 13:19:42 ms_k: In my case, I was using an image preprocess command to tweak ownership. I believe you would have to do something like that so that when the partition is mounted, the ownership is correct. Aug 27 13:21:36 ms_k: So in your imnage definition, IMAGE_PREPROCESS_COMMAND_append = "change_permissions;" and then implement that function to run chown. Aug 27 13:21:58 * tgoodwin image* ...either too much or not enough coffee. Aug 27 13:39:46 tgoodwin: Thank you, I will give it a try Aug 27 13:44:35 ms_k: you're welcome :) Aug 27 14:03:39 where might i be going wrong when I get "ld: cannot find -lBoost::filesystem"? using cmake on a rather simple package. DEPENDS = "boost" is set. Aug 27 14:04:18 seems like the wrong library name. Aug 27 14:04:55 tgoodwin: should be lboost_filesystem, right? Aug 27 14:05:28 LetoThe2nd: yes, I think so (that's what it's showing on my x86_64 system). Aug 27 14:05:40 your error indicates it's using the namespace (::) Aug 27 14:06:24 tgoodwin: i see. thanks for the input! Aug 27 14:06:26 And a capital B. Aug 27 14:06:28 you bet :) Aug 27 14:13:57 hi everyone, I've been trying to create a recipe for `pytorch` to enable some edge computing for embedded devices and after giving up on trying to create a recipe which would compile things from source, I resorted to trying to deploy the precompiled shared libraries `pytorch` offers. I get some strange "no providers found in RDEPENDS_" errors. I'v Aug 27 14:13:58 e posted my recipe on stackoverflow: https://stackoverflow.com/questions/57669621/installing-a-precompiled-library-that-depends-on-another-in-a-bitbake-recipe Aug 27 14:14:07 I get the feeling that i'm missing something small but crucial, any pointers? Aug 27 14:15:19 platisd: what's likely happening is that your recipe deploying that .so has an empty main package. Aug 27 14:15:59 Hmm, can you please elaborate on the "empty main package"? Aug 27 14:17:04 Sorry, responded too fast; it sounded a lot like a problem I heard a while back where someone was trying to deploy an so, but the RDEPENDS error came up when creating their image. Aug 27 14:17:11 I've had some other recipes that merely move over precompiled libraries without a problem. The main difference with this one is that one of the libraries that another depends on is versioned. Aug 27 14:17:26 No problem Aug 27 14:19:08 Looks like you don't have a RDEPENDS against whatever is providing libgomp Aug 27 14:20:49 I've tried that too, but before we go there, since I am installing that particular library as well in the same recipe, should it be even needed? Aug 27 14:21:04 I think that's "gcc-runtime" Aug 27 14:21:06 One of the files in the .zip is the ligomp Aug 27 14:21:15 I see Aug 27 14:21:57 Yeah, gcc-runtime does provide `libgomp`. Unfortunately pytorch wants to link against a very specific version of libgomp, i.e. `libgomp-753e6e92.so.1` Aug 27 14:22:55 I would assume that `install -m 0755 ${LOCAL_LIB}/*.so* ${TARGET_LIB}` should have been enough to necessary everything that is necessary. Aug 27 14:23:48 In any case, I've tried creating another recipe just with the particular version of `libgomp` and listing it in RDEPENDS_${PN}. Sadly (and unsurprisingly a bit) it doesn't seem to make any difference. Aug 27 14:25:17 Have you checked the package's "image" directory as well as "package" and "packages-split" to make sure it's being collected as you expect? Aug 27 14:29:42 Hi Aug 27 14:31:09 > Have you checked the package's "image" directory as well as "package" and "packages-split" to make sure it's being collected as you expect?Any specific thing to look for? The files I am interested in seem to be there. For example in `image/usr/lib` all the `.so` files are there. Aug 27 14:31:19 oops, sorry for the bad format Aug 27 14:34:23 platisd: packages RPROVIDES libraries. This gets automatically filled in with IIRC the SONAME of the *.so.* files. Aug 27 14:34:38 None are RPROVIDES-ing libgomp-753e6e92 Aug 27 14:36:26 Add a symlink somehwere that links libgomp-753e6e92.so.1 to libgomp.so.1 and add a RPROVIDES_${PN} += "libgomp-753e6e92.so.1". That *might* work. Untested of course Aug 27 14:37:12 qschulz I've created a separate recipe, called torch-deps. You can find it here: https://gist.github.com/platisd/aeec6bdf88923976fd759d7b5fe939aa Aug 27 14:37:32 Inside it, I specifically provide: `RPROVIDES_${PN} = "libgomp-753e6e92.so.1"` Aug 27 14:37:49 Let me have a look at your last suggestion about symlinking Aug 27 14:39:14 platisd: mainly curious if the main package in packages-split contains your "libgomp-753e6e92.so.1" file or if it's in some other package. Aug 27 14:39:44 i'm facing exactly the same error on yocto warrior with python 2.7 as fixed here for python 3: Aug 27 14:39:47 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c499f55303ec40942f5dfa3ca95037591d9242ae Aug 27 14:40:33 tgoodwin yeap, it's in there :) Aug 27 14:41:12 hmm Aug 27 14:45:02 qschulz I've added a symlink, however I don't know if it's what you means. The `torch-deps` recipe now looks like this: Aug 27 14:45:10 ` install -m 0755 ${LOCAL_LIB}/libgomp-753e6e92.so.1 ${D}${libdir} ln -rs ${D}${libdir}/libgomp-753e6e92.so.1 libgomp-753e6e92.so` Aug 27 14:45:48 It's still erroring though :/ Aug 27 14:47:06 I'm getting baffled by the fact that creating a new recipe should not be necessary. Just copying them as they are to `/usr/lib` would have solved all my problems :P Aug 27 14:47:35 Have you tried skipping "file-rdeps" to see what errors you get on the target? Aug 27 14:48:57 FWIW I think including that symlink may actually break something in the event you try to install gcc-runtime (multiple providers) Aug 27 14:49:11 Yeah, it made me very happy to see that it finally compiled. However eventually nothing ends up on target Aug 27 14:52:04 Does your image include your package (either IMAGE_INSTALL or CORE_IMAGE_EXTRA_INSTALL)? Aug 27 14:52:26 It did indirectly, through another package that depends on these libraries Aug 27 14:52:52 Matter of fact, when listing it as a runtime dependency of the other package, the error would again resurface Aug 27 14:52:53 I see. Aug 27 14:53:39 But we would expect it to, right? (since only things that have been RDEPENDS-against will be in the image) Aug 27 14:54:37 Indeed that is correct Aug 27 14:55:01 but just tried it as a sanity check anyway :P Aug 27 14:55:36 So including the `libtorch` recipe directly to my image via `IMAGE_INSTALL_append` throws the following error Aug 27 14:55:44 ```Error: Problem: conflicting requests - nothing provides libgomp-753e6e92.so.1()(64bit) needed by libtorch-1.2.0-r0.corei7_64``` Aug 27 14:58:30 platisd: tbf we had the same issue and added a INSANE_SKIP for file-rdeps for this veri specific thing. Aug 27 14:59:15 FOr a lib that didn't have an SONAME IIRC or requiring libfoo.so while only libfoo.so.1.0 was provided (then symlink + INSANE_SKIP) Aug 27 15:02:04 I don't think that symlinking worked as it should (see earlier comment) because I actually cannot find the link in the staging directory. Care to share how should that look like? Aug 27 15:02:36 you actually don't care about the symlink Aug 27 15:02:48 INSANE_SKIP but make sure the lib is in the rootfs Aug 27 15:03:00 RDEPENDS on the package providing the lib Aug 27 15:03:57 which is torch-deps Aug 27 15:09:47 Hmmm still get an error. on my image recipe I'm adding: `IMAGE_INSTALL_append = " torch-deps libtorch"`. Then the error is: `nothing provides libgomp-753e6e92.so.1()(64bit) needed by libtorch-1.2.0-r0.corei7_64`. Both of my `libtorch` and `torch-deps` recipes can be found at https://gist.github.com/platisd/aeec6bdf88923976fd759d7b5fe939aa#file-libt Aug 27 15:09:47 orch_1-2-0-bb Aug 27 15:10:18 New news from stackoverflow: error in fw_setenv when building u-boot-fw-utils Aug 27 15:17:05 ah but you need it at compile time as well? Aug 27 15:20:20 Connection died before so I may have missed something you wrote Aug 27 15:21:08 it seems you need it at compile time as well Aug 27 15:21:14 which is different Aug 27 15:22:05 Well not at the moment, no. Nothing needs those libraries at the moment. Aug 27 15:22:29 I'm trying to add them, make them available via the sdk and then eventually components will start depending on them Aug 27 15:22:31 well... nothing *provides* libgomp-753e6e92.so.1() Aug 27 15:23:47 @qshulz torch-deps specifically provides it, at least that's what I intended with the RPROVIDES on L24: https://gist.github.com/platisd/aeec6bdf88923976fd759d7b5fe939aa#file-torch-deps_1-2-0-bb-L24 Aug 27 15:24:18 are meta-selinux folks on irc? Aug 27 15:24:59 Unless you meant "provides" as opposed to "rprovides" Aug 27 15:26:14 (I guess there isn't such a thing as "provides" so nvm) Aug 27 15:27:02 https://www.yoctoproject.org/docs/2.6.2/mega-manual/mega-manual.html#var-PROVIDES there is :) Aug 27 15:27:49 but how the sentence is written is more like it cannot find a package which is providing libgomp-753e6e92.so.1 which is needed at compile time Aug 27 15:28:04 to be included in the sysroot of libtorch Aug 27 15:28:22 which is different from hacking around and not caring much about file-reps wanrnings Aug 27 15:29:41 Well, sure, to be exact it will be required both at compile time (to - eventually - compile a component) and at runtime so it can run on the target Aug 27 15:30:18 To eventually be *linked with a component Aug 27 15:31:50 qschulz: didn't know there was a provides, wonder if that'll help Aug 27 15:50:38 DevDay slides : https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 Aug 27 15:53:10 dreyna: thanks Aug 27 19:50:27 Hi, maybe someone could help me to understand how to handle package (recipe) version vs software version. I mean, suppose I have a recipe named "my-software_1_0.bb". SRC_URI is set to a git C++ repo and once build it produce a software with the version "1.0.34". Do I need to update the PR (inside the recipe) each time the software produce a newer version ? Like settings "PR=1.0.35" next time I launch a new build ? Aug 27 20:11:33 LetoThe2nd: Yup, still get the same error, even if I copy the new layer into the `layers` directory and re-run the script Aug 27 20:12:12 There must be something wrong with the way in which I'm setting this up. I'll take it to the upstream project and ask them where I'm going wrong... thanks for all the help! Aug 27 20:50:53 The package name should be something like "my-software_1.0.34+gitr0+2f35d32268-r0_cortexa8hf-vfp-neon", but I build a new one with some source code changes, so the only difference in the file name will be the git hash. So the opkg server will be able to keep both version in the same folder. The question is, how opkg (opkg update && opkg upgrade) will know which of them are the most recent ? Aug 27 20:58:26 erakis: AFAIK, you can't get opkg to properly update based only on a git hash. Aug 27 20:58:58 erakis: The PR is after the git hash, so it doesn't help Aug 28 01:54:49 JPEW: So how do we handle that ? I already have a recipe my-software_1_0.bb, so without updating the recipe's name (version) okpg will not be able to differentiate them in term of which one is the more recent ? Does it means that each time a new software release is available but the recipe does not required to be change, we even need to create a copy `1_1` of the recipe but incremented manually the version `1_2` in file name to get a new package that opkg Aug 28 01:54:49 will now see a more recent ? **** ENDING LOGGING AT Wed Aug 28 02:59:57 2019