Tuesday, 2019-08-27

*** armpit <armpit!~armpit@50-196-181-114-static.hfc.comcastbusiness.net> has joined #yocto00:28
*** bbraun <bbraun!~bbraun@opendarwin/core/bbraun> has quit IRC00:44
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto01:00
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto01:33
*** kaspter <kaspter!~Instantbi@115.195.55.3> has joined #yocto01:41
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC01:54
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC03:25
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto03:29
*** Crofton <Crofton!~Crofton@145.253.78.226> has quit IRC03:59
*** Crofton <Crofton!~Crofton@145.253.78.226> has joined #yocto03:59
Crofton /msg aehs29 a friend even sent me the survey link so I could complain with him and no power in the embedded hacking room04:01
*** cp is now known as cp-04:02
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto04:29
*** Crofton <Crofton!~Crofton@145.253.78.226> has quit IRC04:44
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC05:06
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto05:23
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto06:04
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC06:27
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto06:28
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto06:35
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto06:41
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto06:51
*** yacar_ <yacar_!~yacar@80.215.197.37> has joined #yocto07:12
*** yann <yann!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has quit IRC07:18
*** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto07:29
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC07:30
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:32
yoctiNew news from stackoverflow: Installing a precompiled library that depends on another in a bitbake recipe <https://stackoverflow.com/questions/57669621/installing-a-precompiled-library-that-depends-on-another-in-a-bitbake-recipe>07:38
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto07:43
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto07:48
mckoangood morning07:49
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto07:49
LetoThe2ndmckoan: mostly yes, indeed!07:53
erbo:)07:54
LetoThe2ndmckoan: btw, you coming to lyon too?07:56
*** Dvorkin <Dvorkin!~Dvorkin@176.114.204.12> has joined #yocto07:56
Dvorkinwhy do I have warning message? https://pastebin.com/5Sw0UEug07:59
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto08:04
mckoanLetoThe2nd: yes of course08:15
*** goliath <goliath!~goliath@82.150.214.1> has joined #yocto08:15
Proffalken11208:15
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC08:15
Proffalkenhahaha, ignore that, serious lag on this connection :D08:15
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto08:17
LetoThe2ndProffalken: hi.. sorry for me not getting back to you, didn't find any time to look at the layer. my bad.08:17
LetoThe2ndmckoan: \O/08:17
ProffalkenLetoThe2nd: No worries, I've been sunning myself by a pool and listening to Cricket, feeling incredibly guilty that I wasn't doing any work! :D08:17
LetoThe2ndProffalken: Hooray! Crickets!08:18
ProffalkenShould clarify just incase - I'm talking about the sport, not the insect! ;)08:22
LetoThe2ndI'm talking about the insects. Just to clarifiy!08:22
Proffalken\o/08:23
LetoThe2ndProffalken: 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.08:24
ProffalkenOK, thanks for the heads-up08:25
LetoThe2ndProffalken: good luck!08:25
ProffalkenI'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/972d8f180d7371713c8f58968848683808:28
ProffalkenThe code I'm trying to add the layer to is https://github.com/brocaar/lora-gateway-os08:28
Proffalkenand I have this as a submodule of my "parent" repo08:28
ProffalkenThe new layer is discovered, however none of the .bb files are found08:28
qschulzProffalken: what have you done to make the new layer be discovered?08:30
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto08:31
jklareHi08:31
jklareI 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=master08:32
jklareThe commit message says it closes #12504 and mentions #1250508:33
jklareIf i go to bugzilla.yoctoproject.org and search for these issues, both of them are there but have nothing to do with this patch08:33
jklarei would like to backport these patches to systemd 241 to be able to use systemd link up in the warrior release08:34
jklarecan anybody help me here and point me into the right direction?08:34
*** kaspter <kaspter!~Instantbi@115.195.55.3> has quit IRC08:38
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-pvkhrjzdvopscgsb> has joined #yocto08:41
Proffalkenqschulz: 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/'08:43
ProffalkenNote - 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 organised08:45
Proffalkens/is/needs to be/g08:46
LetoThe2ndProffalken: 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.08:47
ProffalkenCool, at least it's not likely that then, really appreciate all the help :)08:48
*** yann <yann!~yann@85.118.38.73> has joined #yocto08:48
*** deuteron <deuteron!~deuteron@ppp118-210-114-94.bras2.adl4.internode.on.net> has joined #yocto09:02
deuteronHello.  Is there are simple way to determine a package's dependencies within a recipe?09:03
LetoThe2nddeuteron: "within a recipe"?09:03
deuteronYes. I have some recipe that I want to produce a zip file of some ipks and their dependencies.09:04
*** lemagoup <lemagoup!~lemagoup@softbank-robotics-gw1.ter4.eqx2.par.cust.as8218.eu> has quit IRC09:05
LetoThe2ndsounds very much like an XY-problem09:05
deuteronWhat's that?09:05
deuteronOh, right.09:06
*** lemagoup <lemagoup!~lemagoup@softbank-robotics-gw1.ter4.eqx2.par.cust.as8218.eu> has joined #yocto09:06
LetoThe2ndyou 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?09:06
deuteronBasically, I want to delay installing some packages until install time.09:07
deuteronI don't want to bake them into the image.09:07
qschulzhttps://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-EXTRA_IMAGEDEPENDS ?09:08
qschulzPackages are built but not installed in the rootfs09:08
yoctiNew news from stackoverflow: YOCTO : can't insert linux module to the kernel : versions are different <https://stackoverflow.com/questions/57670786/yocto-cant-insert-linux-module-to-the-kernel-versions-are-different>09:09
LetoThe2ndi 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.09:09
qschulzyou should have them in tmp/deploy/{ipk,rpm,deb} (depending on your package manager)09:09
LetoThe2nddeuteron: 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.09:10
deuteronWell the rootfs has 90% of things.09:11
deuteronBut 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.09:12
LetoThe2nddeuteron: 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.09:12
deuteronLetoThe2nd: Sure, in theory it could bundle EVERYTHING, but in practise that won't happen.09:12
LetoThe2nddeuteron: see, and thats where things start to be complicated.09:13
LetoThe2nddeuteron: the simplest solution would certainly be if you can use a network based package repository, so the package manager just pulls what it needs.09:13
LetoThe2nddeuteron: next in line probably would be a static build of the desired packages. it adds to the space consumption, but makes it self-contained.09:14
deuteronNetwork access is not available on non-development devices.09:16
deuteronThe 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.09:16
deuteronSo, I'm trying to build a single installer, that can then be stripped down as needed just using 'zip -d ...'09:17
LetoThe2nddeuteron: then you will need some pretty convuluted logic to tell the zipper what to include and what not.09:17
deuteronNo, that part is easy and already works.09:17
deuteronI just need the dependency tracking.09:17
LetoThe2ndbut i'd probably do that external to bitbake, just reach into the package deploy folder, look at the package dependencies and then rcurse.09:18
deuteronSo that when I say the installer needs to bundle 'bash' I don't need to say 'and libreadline, etc.'09:18
deuteronLetoThe2nd: Yes, I'm starting to think that too.09:18
LetoThe2ndplease read again what i just wrote :)09:18
deuteronIt's not convoluted, this is simple stuff. Package A depends on package B.09:19
LetoThe2ndand 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 manifest09:19
LetoThe2nddeuteron: the mindset is simple of course. the rest is not.09:19
LetoThe2nddeuteron: https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d952709:20
deuteronNo. The package manager exists. Yocto already does all this stuff.09:20
LetoThe2ndif you believe so09:20
LetoThe2ndthat zip-up-thing is basically a dependency walking package manager right on top of the yocto one.09:21
deuteronAll the dependency information is there already. It's just not obvious how to access it.09:21
LetoThe2ndso its not trivial(TM)09:21
deuteronI've already done this once to produce subsets of SDKs.09:21
deuteronIt was quite easy to just walk the dependencies.09:22
LetoThe2ndi 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.09:22
LetoThe2ndtypo. i'm not saying it can't be done.09:22
deuteronWhat would be a non-trivial subset?09:22
*** falk0n_ <falk0n_!~falk0n@a109-49-147-206.cpe.netcabo.pt> has quit IRC09:23
LetoThe2nddeuteron: non-trivial subsets would probably be anything where the dependency graph contains closed areas, as a first tought.09:24
LetoThe2nddeuteron: but i'm no specialist there. for examples of problems to hit, read that article.09:25
*** falk0n <falk0n!~falk0n@a109-49-142-1.cpe.netcabo.pt> has joined #yocto09:25
LetoThe2ndits of course entirely possible that many of those do not apply to your specific use case. hence the expression "general purpose" earlier.09:26
deuteronThis guy is insufferable.09:27
qschulzdeuteron: 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 itself09:27
LetoThe2ndqschulz: ++09:27
deuteronqschulz: That's basically what we're doing.09:27
deuteronBut I'm trying to avoid having to specify ALL the packages that need to go on the USB stick.09:27
qschulzget a big USB stick and spare days/weeks worth of work?09:28
deuteronFor 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.09:29
deuteronBut I'm trying to avoid having to manually specify that libreadline needs to be bundled with the installer.09:30
qschulzdeuteron: `opkg depends packagename` would provide such a thing (but I don't know if it resolves dependencies of depdencies). Also pckg manager specific :/09:30
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has joined #yocto09:30
deuteronI just figured yocto spends so much loading caches and other stuff before it actually does anything that this information is *surely* readily available.09:30
qschulzthen you put this process in the image recipe after everything09:31
deuteronWell, I'm out of time today.  Better luck tomorrow, I guess.09:33
deuteronqschulz: LetoThe2nd: Thanks for your time.09:33
LetoThe2ndgood luck09:33
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC09:41
*** yacar_ <yacar_!~yacar@80.215.197.37> has quit IRC09:51
*** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has joined #yocto09:53
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto10:00
*** learningc <learningc!~learningc@121.122.92.156> has joined #yocto10:15
*** ralu <ralu!~ralu@mail.i-tech.si> has joined #yocto10:31
raluI have noticed that http://layers.openembedded.org/layerindex/api/recipes/ is not available. Is that just temporary?10:32
LetoThe2ndhalstead: ^^^^^^^^10:34
LetoThe2ndralu: admin says he'll look into it, but will take some time, sorry.10:41
raluOk, thank you!10:44
LetoThe2ndyw10:44
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC10:45
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto10:46
*** nameclash <nameclash!3e60c2d5@h-62.96.194.213.host.de.colt.net> has joined #yocto10:55
qschulzProffalken: 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 :)11:08
yoctiNew news from stackoverflow: /dev/fd/ socket or pipe links fail, NOT missing /dev/fd link <https://stackoverflow.com/questions/57498881/dev-fd-socket-or-pipe-links-fail-not-missing-dev-fd-link>11:09
PinkSnakeit'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 ? :S11:10
*** yacar_ <yacar_!~yacar@80.215.197.37> has joined #yocto11:11
qschulzdefine "works only"11:16
qschulzalso, https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-AUTOREV you need to override PV to have SRCPV in it11:17
PinkSnakeqschulz --> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, | /usr/bin/env: 'svn': No such file or directory11:18
PinkSnakeqschulz after added PR = "r0" thx for advice I have read the doc to fast ;)11:20
*** learningc <learningc!~learningc@121.122.92.156> has quit IRC11:21
*** learningc <learningc!~learningc@121.122.92.156> has joined #yocto11:21
qschulzI was talking about PV, not PR. these are two different things11:22
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC11:22
*** learningc <learningc!~learningc@121.122.92.156> has quit IRC11:22
qschulzI 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)11:23
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:23
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC11:32
PinkSnakeqschulz 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.011:32
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:33
qschulzSRCREV = "${AUTOREV}" and PV = "+git${SRCPV}" (sorry typo, I meant to say SRCPV and not SRCREV earlier)11:35
qschulz(you don't need +git in PV, it's just what I do)11:35
PinkSnakeqschulz yep thx no prob for typo ;)11:36
qschulzI don't know exactly, but IIRC there is some mechanism to detect when a rebuild is required that is based on PV11:36
qschulzwith SRCREV set to autorev, this PV is not updated or something like that, and Yocto fails to detect the update11:37
qschulzthat's extremely vague because I don';t know what I'm talking about and if that is actually true11:37
qschulzanyway, no PV="+git${SRCPV}" it failed for me11:38
qschulzsame 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.11:39
qschulzwhen you change PR in Yocto you trigger a rebuild I think11:39
qschulzBut please, anyone, correct anything I'm saying. It's just assumptions I making here from my little experience11:39
PinkSnakeqschulz 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 :S11:41
qschulzlogs :)11:41
*** berton <berton!~berton@181.220.83.67> has joined #yocto11:41
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC11:42
qschulzAnd 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 :)11:42
Proffalkenqschulz: no worries, thanks for looking, kinda glad it looks ok to you as well, I've been tearing my hair out over here! :D11:44
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto11:46
PinkSnakeqschulz https://pastebin.com/Yzhz02Z311:46
PinkSnakeqschulz that's my trouble ^^11:47
PinkSnakeqschulz it's really strange any trouble with git sources :S11:47
*** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto11:50
qschulzPinkSnake: what's the content of your recipe now?11:51
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC11:51
PinkSnakeqschulzhttps://pastebin.com/y4Y32G6G11:52
qschulzit's complaining it can't find svn11:53
qschulz /usr/bin/env: 'svn': No such file or directory11:53
qschulzis svn not in the $PATH used by Yocto?11:54
PinkSnakeyes but if I replace AUTOREV with a revision number everything works as expected11:54
PinkSnakesubversion ... :S11:55
qschulzPinkSnake: 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)11:58
LetoThe2ndProffalken: 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?12:00
*** edgar444 <edgar444!uid214381@gateway/web/irccloud.com/x-arzstconmeoghkaa> has joined #yocto12:29
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto12:40
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC12:45
*** mauro_ <mauro_!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has joined #yocto12:54
mauro_Good morning12:58
*** mauro_ <mauro_!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has left #yocto12:58
*** mauro_ <mauro_!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has joined #yocto12:59
*** mauro_ <mauro_!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has left #yocto12:59
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC13:03
*** ms_k <ms_k!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has joined #yocto13:03
*** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC13:08
ms_kGood morning all, has anyone tried to change partition owner on a partition created using .wks?13:10
ms_kAs per this link https://lists.yoctoproject.org/pipermail/yocto/2016-November/032973.html it seems possible13:11
ms_kbut I'm trying to do this without success, partition is always owned by root:root (I'm on Yocto Warrior)13:11
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto13:12
tgoodwinms_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.13:17
*** yacar_ <yacar_!~yacar@80.215.197.37> has quit IRC13:17
*** yacar_ <yacar_!~yacar@80.215.197.37> has joined #yocto13:18
tgoodwinms_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.13:19
*** armpit <armpit!~armpit@50-196-181-114-static.hfc.comcastbusiness.net> has quit IRC13:20
*** armpit <armpit!~armpit@50-196-181-114-static.hfc.comcastbusiness.net> has joined #yocto13:20
tgoodwinms_k: So in your imnage definition, IMAGE_PREPROCESS_COMMAND_append = "change_permissions;" and then implement that function to run chown.13:21
* tgoodwin image* ...either too much or not enough coffee.13:21
ms_ktgoodwin: Thank you, I will give it a try13:39
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC13:44
tgoodwinms_k: you're welcome :)13:44
*** ms_k <ms_k!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has quit IRC13:50
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC13:50
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC13:52
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC13:55
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto13:57
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto13:57
*** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto13:59
*** platisd <platisd!4f885a78@h-90-120.A137.corp.bahnhof.se> has joined #yocto13:59
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC14:01
LetoThe2ndwhere might i be going wrong when I get "ld: cannot find -lBoost::filesystem"? using cmake on a rather simple package. DEPENDS = "boost" is set.14:03
tgoodwinseems like the wrong library name.14:04
LetoThe2ndtgoodwin: should be lboost_filesystem, right?14:04
tgoodwinLetoThe2nd: yes, I think so (that's what it's showing on my x86_64 system).14:05
tgoodwinyour error indicates it's using the namespace (::)14:05
LetoThe2ndtgoodwin: i see. thanks for the input!14:06
tgoodwinAnd a capital B.14:06
tgoodwinyou bet :)14:06
*** armpit <armpit!~armpit@50-196-181-114-static.hfc.comcastbusiness.net> has quit IRC14:11
platisdhi 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'v14:13
platisde posted my recipe on stackoverflow: https://stackoverflow.com/questions/57669621/installing-a-precompiled-library-that-depends-on-another-in-a-bitbake-recipe14:13
platisdI get the feeling that i'm missing something small but crucial, any pointers?14:14
tgoodwinplatisd: what's likely happening is that your recipe deploying that .so has an empty main package.14:15
platisdHmm, can you please elaborate on the "empty main package"?14:15
tgoodwinSorry, 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.14:17
platisdI'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.14:17
platisdNo problem14:17
tgoodwinLooks like you don't have a RDEPENDS against whatever is providing libgomp14:19
platisdI'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?14:20
tgoodwinI think that's "gcc-runtime"14:21
platisdOne of the files in the .zip is the ligomp14:21
tgoodwinI see14:21
platisdYeah, gcc-runtime does provide `libgomp`. Unfortunately pytorch wants to link against a very specific version of libgomp, i.e. `libgomp-753e6e92.so.1`14:21
*** yacar_ <yacar_!~yacar@80.215.197.37> has quit IRC14:22
platisdI would assume that `install -m 0755 ${LOCAL_LIB}/*.so* ${TARGET_LIB}` should have been enough to necessary everything that is necessary.14:22
platisdIn 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.14:23
tgoodwinHave you checked the package's "image" directory as well as "package" and "packages-split" to make sure it's being collected as you expect?14:25
*** nickoss <nickoss!a5e1565b@165.225.86.91> has joined #yocto14:29
nickossHi14:29
platisd> 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.14:31
platisdoops, sorry for the bad format14:31
*** platisd_ <platisd_!uid388022@gateway/web/irccloud.com/x-iyomzpeluanufriv> has joined #yocto14:31
*** platisd_ <platisd_!uid388022@gateway/web/irccloud.com/x-iyomzpeluanufriv> has quit IRC14:32
qschulzplatisd: packages RPROVIDES libraries. This gets automatically filled in with IIRC the SONAME of the *.so.* files.14:34
qschulzNone are RPROVIDES-ing libgomp-753e6e9214:34
*** ralu <ralu!~ralu@mail.i-tech.si> has quit IRC14:35
qschulzAdd 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 course14:36
platisdqschulz I've created a separate recipe, called torch-deps. You can find it here: https://gist.github.com/platisd/aeec6bdf88923976fd759d7b5fe939aa14:37
platisdInside it, I specifically provide: `RPROVIDES_${PN} = "libgomp-753e6e92.so.1"`14:37
platisdLet me have a look at your last suggestion about symlinking14:37
*** goliath <goliath!~goliath@82.150.214.1> has quit IRC14:38
*** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has quit IRC14:38
tgoodwinplatisd: mainly curious if the main package in packages-split contains your "libgomp-753e6e92.so.1" file or if it's in some other package.14:39
derRichardi'm facing exactly the same error on yocto warrior with python 2.7 as fixed here for python 3:14:39
derRichardhttp://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c499f55303ec40942f5dfa3ca95037591d9242ae14:39
platisdtgoodwin yeap, it's in there :)14:40
tgoodwinhmm14:41
*** armpit <armpit!~armpit@45.19.219.178> has joined #yocto14:41
platisdqschulz I've added a symlink, however I don't know if it's what you means. The `torch-deps` recipe now looks like this:14:45
platisd`    install -m 0755 ${LOCAL_LIB}/libgomp-753e6e92.so.1 ${D}${libdir}    ln -rs ${D}${libdir}/libgomp-753e6e92.so.1 libgomp-753e6e92.so`14:45
platisdIt's still erroring though :/14:45
platisdI'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 :P14:47
tgoodwinHave you tried skipping "file-rdeps" to see what errors you get on the target?14:47
*** edgar444 <edgar444!uid214381@gateway/web/irccloud.com/x-arzstconmeoghkaa> has quit IRC14:48
tgoodwinFWIW I think including that symlink may actually break something in the event you try to install gcc-runtime (multiple providers)14:48
platisdYeah, it made me very happy to see that it finally compiled. However eventually nothing ends up on target14:49
*** yacar_ <yacar_!~yacar@80.215.197.37> has joined #yocto14:50
tgoodwinDoes your image include your package (either IMAGE_INSTALL or CORE_IMAGE_EXTRA_INSTALL)?14:52
platisdIt did indirectly, through another package that depends on these libraries14:52
platisdMatter of fact, when listing it as a runtime dependency of the other package, the error would again resurface14:52
tgoodwinI see.14:52
tgoodwinBut we would expect it to, right? (since only things that have been RDEPENDS-against will be in the image)14:53
platisdIndeed that is correct14:54
platisdbut just tried it as a sanity check anyway :P14:55
platisdSo including the `libtorch` recipe directly to my image via `IMAGE_INSTALL_append` throws the following error14:55
platisd```Error:  Problem: conflicting requests  - nothing provides libgomp-753e6e92.so.1()(64bit) needed by libtorch-1.2.0-r0.corei7_64```14:55
qschulzplatisd: tbf we had the same issue and added a INSANE_SKIP for file-rdeps for this veri specific thing.14:58
qschulzFOr 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)14:59
*** dreyna <dreyna!~dreyna@12.145.98.24> has joined #yocto14:59
platisdI 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?15:02
qschulzyou actually don't care about the symlink15:02
qschulzINSANE_SKIP but make sure the lib is in the rootfs15:02
qschulzRDEPENDS on the package providing the lib15:03
qschulzwhich is torch-deps15:03
platisdHmmm 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-libt15:09
platisdorch_1-2-0-bb15:09
*** platisd <platisd!4f885a78@h-90-120.A137.corp.bahnhof.se> has left #yocto15:10
yoctiNew news from stackoverflow: error in fw_setenv when building u-boot-fw-utils <https://stackoverflow.com/questions/57677457/error-in-fw-setenv-when-building-u-boot-fw-utils>15:10
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC15:14
qschulzah but you need it at compile time as well?15:17
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto15:17
*** platisd <platisd!uid388022@gateway/web/irccloud.com/x-wfupjvwuykelmjtv> has joined #yocto15:19
platisdConnection died before so I may have missed something you wrote15:20
qschulzit seems you need it at compile time as well15:21
qschulzwhich is different15:21
platisdWell not at the moment, no. Nothing needs those libraries at the moment.15:22
platisdI'm trying to add them, make them available via the sdk and then eventually components will start depending on them15:22
qschulzwell... nothing *provides* libgomp-753e6e92.so.1()15:22
platisd@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-L2415:23
*** nickoss <nickoss!a5e1565b@165.225.86.91> has quit IRC15:23
derRichardare meta-selinux folks on irc?15:24
platisdUnless you meant "provides" as opposed to "rprovides"15:24
platisd(I guess there isn't such a thing as "provides" so nvm)15:26
qschulzhttps://www.yoctoproject.org/docs/2.6.2/mega-manual/mega-manual.html#var-PROVIDES there is :)15:27
*** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC15:27
qschulzbut 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 time15:27
qschulzto be included in the sysroot of libtorch15:28
qschulzwhich is different from hacking around and not caring much about file-reps wanrnings15:28
platisdWell, 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 target15:29
platisdTo eventually be *linked with a component15:30
platisdqschulz: didn't know there was a provides, wonder if that'll help15:31
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC15:32
*** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC15:36
*** yacar_ <yacar_!~yacar@80.215.197.37> has quit IRC15:48
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC15:50
dreynaDevDay slides : https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_201915:50
mckoandreyna: thanks15:53
*** ms_k <ms_k!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has joined #yocto15:54
*** dreyna <dreyna!~dreyna@12.145.98.24> has quit IRC15:56
*** armpit <armpit!~armpit@45.19.219.178> has quit IRC15:58
*** armpit <armpit!~armpit@45.19.219.178> has joined #yocto16:14
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC16:17
*** ms_k <ms_k!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has left #yocto16:25
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC16:30
*** mckoan is now known as mckoan|away16:31
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:46
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:47
*** yann <yann!~yann@85.118.38.73> has quit IRC16:52
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto17:09
*** dreyna <dreyna!~dreyna@12.145.98.24> has joined #yocto17:14
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto17:16
*** stephano <stephano!stephano@nat/intel/x-prtddlqccqcaqfyg> has joined #yocto17:25
*** nabokov <nabokov!~armand@67.218.223.154> has joined #yocto17:26
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-pvkhrjzdvopscgsb> has quit IRC17:31
*** dreyna <dreyna!~dreyna@12.145.98.24> has quit IRC17:55
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-nenwfdfuirgvjmtt> has joined #yocto18:08
*** Crofton <Crofton!~Crofton@12.245.46.170> has joined #yocto18:08
*** dreyna <dreyna!~dreyna@12.145.98.24> has joined #yocto18:21
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto18:44
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC18:45
*** dreyna <dreyna!~dreyna@12.145.98.24> has quit IRC18:59
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:08
*** mischief <mischief!~mischief@wopr.sciops.net> has quit IRC19:13
*** stephano <stephano!stephano@nat/intel/x-prtddlqccqcaqfyg> has quit IRC19:17
*** Proffalken <Proffalken!~ec2-user@ec2-18-208-106-45.compute-1.amazonaws.com> has quit IRC19:37
*** dreyna <dreyna!~dreyna@12.145.98.24> has joined #yocto19:45
*** erakis <erakis!~erakis@199.58.239.58> has joined #yocto19:45
*** dreyna <dreyna!~dreyna@12.145.98.24> has quit IRC19:46
*** erakis is now known as erakis_19:47
*** erakis_ is now known as erakis19:47
*** Proffalken <Proffalken!~ec2-user@ec2-18-208-106-45.compute-1.amazonaws.com> has joined #yocto19:48
erakisHi, 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 ?19:50
*** Crofton|mini <Crofton|mini!~Crofton@c-73-152-143-112.hsd1.va.comcast.net> has joined #yocto19:51
*** Crofton <Crofton!~Crofton@12.245.46.170> has quit IRC19:54
ProffalkenLetoThe2nd: Yup, still get the same error, even if I copy the new layer into the `layers` directory and re-run the script20:11
ProffalkenThere 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!20:12
*** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC20:37
erakisThe 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 ?20:50
JPEWerakis: AFAIK, you can't get opkg to properly update based only on a git hash.20:58
JPEWerakis: The PR is after the git hash, so it doesn't help20:58
*** stephano <stephano!stephano@nat/intel/x-esuqsdhvgnordopw> has joined #yocto21:12
*** berton <berton!~berton@181.220.83.67> has quit IRC21:18
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC21:24
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.137.213> has joined #yocto21:29
*** nabokov <nabokov!~armand@67.218.223.154> has quit IRC21:33
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto21:40
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC21:41
*** aidanh_ is now known as aidanh21:41
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto21:45
*** dv_ <dv_!~dv@62.178.50.190> has quit IRC21:48
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto22:02
*** Crofton|mini <Crofton|mini!~Crofton@c-73-152-143-112.hsd1.va.comcast.net> has quit IRC22:10
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:22
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC22:27
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto22:27
*** Crofton|mini <Crofton|mini!~Crofton@ip-64-134-100-98.public.wayport.net> has joined #yocto22:40
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC22:49
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:56
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto22:57
*** deuteron <deuteron!~deuteron@ppp118-210-114-94.bras2.adl4.internode.on.net> has quit IRC23:04
*** stwcx <stwcx!~stwcx@2604:880:a:6::c9c> has quit IRC23:13
*** stwcx <stwcx!~stwcx@172.110.7.206> has joined #yocto23:13
*** Crofton|mini <Crofton|mini!~Crofton@ip-64-134-100-98.public.wayport.net> has quit IRC23:17
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC23:23
*** armpit <armpit!~armpit@45.19.219.178> has quit IRC23:27
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC23:29
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC23:41
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto23:45

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!