Monday, 2019-02-04

*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC00:19
*** agust <agust!> has quit IRC00:25
*** ferlzc <ferlzc!~ferlzc@> has quit IRC00:44
*** armpit <armpit!~armpit@2601:202:4180:c33:40c2:82ac:4641:f878> has joined #yocto00:45
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC00:46
* armpit wishes reproducing AB issue where easier.. aaarg00:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto00:50
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto00:54
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC01:26
*** ferlzc <ferlzc!~ferlzc@> has quit IRC01:34
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto01:45
*** nighty- <nighty-!> has joined #yocto01:52
*** robbawebba <robbawebba!~rob@> has quit IRC01:54
*** fatalhalt <fatalhalt!> has joined #yocto02:25
*** robbawebba <robbawebba!~rob@> has joined #yocto02:40
*** thaytan <thaytan!> has joined #yocto05:17
*** comptroller <comptroller!> has quit IRC05:28
*** AndersD <AndersD!> has joined #yocto06:12
*** AndersD <AndersD!> has quit IRC06:14
*** AndersD <AndersD!~AndersD@> has joined #yocto06:16
*** jobroe <jobroe!~manjaro-u@> has joined #yocto06:17
*** sno <sno!> has quit IRC06:19
yoctiNew news from stackoverflow: How to generate lcov report of a package in yocto <>06:38
*** jobroe <jobroe!~manjaro-u@> has quit IRC06:41
*** jobroe <jobroe!~manjaro-u@> has joined #yocto06:52
*** sno <sno!> has joined #yocto06:59
*** cvasilak <cvasilak!> has joined #yocto07:03
*** CoLa|work <CoLa|work!~cordlandw@> has joined #yocto07:11
sven^I am looking at 3.1.9 in the yocto manual: Appending and Prepending (Override Style Syntax. It says "When you use this syntax, no spaces are inserted.". Why? Is there any reasoning behind this?07:11
*** agust <agust!> has joined #yocto07:20
*** yann <yann!> has quit IRC07:31
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto07:43
*** TobSnyder <TobSnyder!> has joined #yocto07:52
*** mckoan|away is now known as mckoan07:52
mckoansven^: it acts as .= in python07:53
*** fl0v0 <fl0v0!> has joined #yocto07:57
sven^you mean +=? Yeah, but why? Is there a reason why there is no "remove whitespace", "append with one space in between"?08:02
sven^it makes writing recipes so error-prone08:02
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:04
mckoansven^: no, I mean .= append (without space)08:06
*** tprrt <tprrt!~tprrt@> has joined #yocto08:07
sven^yeah, that's += in python. .= is not a python operator08:07
sven^anyway, my question is why it's simply appended instead of adding a space if there is none08:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:08
*** lusus <lusus!~lusus@> has joined #yocto08:10
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC08:11
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto08:12
*** diego_r <diego_r!> has joined #yocto08:15
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto08:18
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC08:38
sven^ok, different question: I am trying to add a file containing version information using a bbclass. So I wrote some python code to dump the version information to a file and use d.setVar("FILES_" + PACKAGENAME, ...) to add it to the package's files. I add this function with do_install[postfuncs] += "myfunc" and that part works. But for some reason the change to FILES_${PN} is not por08:38
sven^if I do d.getVar in my python code it shows the correctly altered files-variable. But when I use bitbake -e <recipe> my entries are missing08:39
*** florian_kc is now known as florian08:48
*** cquast <cquast!~cquast@> has joined #yocto08:48
*** Crofton|work <Crofton|work!~Crofton@2a02:a03f:3eec:d700:7580:b159:5a96:14ae> has quit IRC08:52
*** cquast <cquast!~cquast@> has quit IRC08:53
*** cquast <cquast!~cquast@> has joined #yocto08:55
*** varjag <varjag!> has joined #yocto08:57
*** sveinse <sveinse!> has joined #yocto09:04
sveinseWhen a recipe is build, all its packages are built. Is all RDEPENDS for these pacakges always built too, or is that for later when putting together an image?09:06
LetoThe2ndsveinse: AFAIK RDEPENDS are not being built09:07
sveinseI'm making a packagegroup package (in an existing recipe) for specifying the packages that I'd want built into our package feed, but that won't go into an image. Hence I'm looking for a way to specify this list of packages to build.09:08
sveinseLetoThe2nd: hmm, I tried running bitbake mypackagegroup, and it did build a new RDEPENDS I added... I think. I need to retest.09:09
LetoThe2ndwell you said recipe earlier, not packagegroup. in the latter case i would've answered "no idea", as they behave a bit differently at times.09:10
sveinseLetoThe2nd: aha, ok, I assumes packagegroup were like any other recipe (forgetting the special nature of some things in bb). Sorry.09:11
LetoThe2ndsveinse: np. in that case, i would suggest ot dig into the task-depends09:12
*** miwa <miwa!~miwa@unaffiliated/miwa> has joined #yocto09:22
sveinseAFAICS it does build RDEPENDS of packagegroup packages -- even if the that package isn't explicitly used by any image or mentioned on bitbake cmd line09:25
sveinseInteresting... That actually implies I should split my all-in-one packagegroup into multiple severeal, since one might not want to build all of a SDK or development packages when building a small image.09:27
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:39
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC09:41
*** moritz_ <moritz_!5098e50e@gateway/web/freenode/ip.> has joined #yocto09:50
*** lfa <lfa!~lfa@> has joined #yocto09:54
*** hamis <hamis!~irfan@> has quit IRC10:00
*** hamis <hamis!~irfan@> has joined #yocto10:00
*** comptroller <comptroller!> has joined #yocto10:04
*** rburton <rburton!> has joined #yocto10:10
sven^what exactly do I have to do to alter tthe FILES_${PN} variable from within a bbclass? I am doing d.appendVar("FILES_" + d.getVar("PN"), "something") in a do_install[postfuncs]. If I look at the variable right afterwards the value is there, but when I do bitbake -e it is not10:24
sven^oh, sorry, do_compile[postfuncs]10:24
*** berton <berton!~berton@> has joined #yocto10:32
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:33
*** florian_kc is now known as florian10:35
moritz_sven I think you should be able to see what alters your FILES_${PN} variable using bitbake -e. Just pipe the output into a text file and search. (wild guess would be that something overrides it)10:35
*** berton <berton!~berton@> has quit IRC10:35
rburtonthat won't work becayse -e won't execute the compile task10:36
rburtonif -e executed tasks, it would be compiling stuff....10:36
rburtonnote that appendVar doesn't add whitespace so you'll need to remember to do that10:37
*** berton <berton!~berton@> has joined #yocto10:37
*** lucaceresoli <lucaceresoli!> has joined #yocto10:40
kanavinRP: yep, not too bad10:41
*** CoLa|work <CoLa|work!~cordlandw@> has quit IRC10:42
sveinseIs there any tools to generate URLs for target to access package feeds? I mean, looking into tmp/deploy/ipk, there are multiple dirs which should be available for any given MACHINE target. Is there a parseable list I can use to determine the target config?10:48
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has joined #yocto10:49
sveinseFor my imx target, I got at least 4 ipk dirs: all, ${TUNE}, ${TUNE}-${SOC} and ${MACHINE}. Of course I can hardcode these, but I'd rather like to extract them10:51
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has quit IRC10:55
*** yann <yann!~yann@> has joined #yocto10:55
*** feddischson <feddischson!> has joined #yocto10:57
*** Crofton|work <Crofton|work!> has joined #yocto11:10
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto11:13
*** hilt0n <hilt0n!b92bf572@gateway/web/freenode/ip.> has joined #yocto11:14
hilt0nHi there11:14
hilt0nI created a specific ubi image creation on which the rootfs depends on a data img task11:15
hilt0nThe data img name is based on timestamp and the rootfs as well11:15
hilt0nMy problem is that if I stop the rootfs final image creation and restart this command, the previously created data image doesn't the same timestamp as the new rootfs image11:16
hilt0nDo you have an idea on how to recreate each time the data img as "PHONY" in Makefile or may be there is a better way ?11:17
rburtonsveinse: set PACKAGE_FEED_URLS in local.conf to the URL of the http youre running over deploydir and it will set up the package manager for you11:21
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto11:22
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:22
*** Crofton|work <Crofton|work!> has quit IRC11:30
*** Crofton|work <Crofton|work!> has joined #yocto11:30
sven^moritz_: I did that for debugging11:34
sven^nothing overwrote it but my class just didn't set the variable11:34
sven^or for some reason the newly set variable didn't propagate back to the recipes11:34
sven^I finally solved it by setting the variable in python __anonymous ()11:35
sven^but I still don't get why I need to do that when classes like this: set it right in a normal function11:35
moritz_Yes sorry that was a wrong shot by me as rb pointed out already11:35
sven^I guess it has something to do with when and how the variable is set and how the setting function is called, but I can't find anything in the manual that explains what's happening11:36
*** grma <grma!~gruberm@> has quit IRC11:38
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:39
yoctiNew news from stackoverflow: Porting driver from static to dynamic on Yocto <>11:39
rburton-e shows the value after parse, which includes anon py11:39
rburtona do_compile[postfunc] is a task that is ran, so anything you in there won't be visible at parse time, or even at any point before the function runs11:40
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC11:40
*** kanavin <kanavin!~kanavin@> has quit IRC11:41
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto11:43
*** CoLa|work <CoLa|work!~cordlandw@> has joined #yocto11:43
sven^rburton: ok, but it also did not work. I think. For the last 15 "tries" I only used -e to check if it works11:48
*** Crofton|work <Crofton|work!> has quit IRC11:48
*** grma <grma!~gruberm@> has joined #yocto12:01
*** JoshDeWeese[m] <JoshDeWeese[m]!enoch247sa@gateway/shell/> has left #yocto12:01
*** berton <berton!~berton@> has quit IRC12:10
*** berton <berton!~berton@> has joined #yocto12:11
*** ferlzc <ferlzc!~ferlzc@> has quit IRC12:13
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC12:26
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto12:31
*** ferlzc <ferlzc!~ferlzc@> has quit IRC12:32
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto12:48
*** feddischson <feddischson!> has quit IRC13:03
*** Crofton|work <Crofton|work!> has joined #yocto13:05
*** Crofton|work <Crofton|work!> has quit IRC13:26
*** kanavin <kanavin!~kanavin@> has joined #yocto13:32
*** marka <marka!~masselst@> has joined #yocto13:35
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC13:47
*** Crofton|work <Crofton|work!> has joined #yocto13:58
*** Crofton|work <Crofton|work!> has quit IRC14:04
*** varjag <varjag!> has quit IRC14:18
*** stephano <stephano!~stephano@> has joined #yocto14:22
*** Crofton|work <Crofton|work!> has joined #yocto14:31
*** andycooper <andycooper!uid246432@gateway/web/> has joined #yocto14:37
*** nayfe <nayfe!uid259604@gateway/web/> has joined #yocto14:44
*** moritz_ <moritz_!5098e50e@gateway/web/freenode/ip.> has left #yocto14:49
nayfeHi all, I have a problem with Go and prometheus/node_exporter on Thud, it crashes quite a lot (it wasn't in Sumo). Do you know any issue with Go runtime on x86-64 (meta-intel) arch? (recipe here: It also crash with backported go1.11.4 version. I raised an issue on prometheus github14:52
nayfe too.14:52
*** osoldano <osoldano!> has left #yocto14:52
*** maudat <maudat!~moda@> has joined #yocto14:55
*** AndersD <AndersD!~AndersD@> has quit IRC14:58
nayfe@khem any thoughts? (I saw you worked on meta-influx ^^)14:59
sveinseI notice that the target package "gcc" installs itself as a cross compiler, e.g. "/usr/bin/arm-oe-linux-gnueabi-gcc", and not as "/usr/bin/gcc". Any particular reason for that?15:02
sveinserburton: thanks. That worked perfect. Just have to save the config and remove it from the production image15:03
RPsveinse: look for the gcc-symlinks package15:05
*** Bunio_FH <Bunio_FH!> has joined #yocto15:06
kanavinRP: the latest patch for py3 is still not 100% right, I'll resend15:06
sveinseRP: there you go, thanks!15:07
*** lazyape <lazyape!> has quit IRC15:15
*** lazyape <lazyape!> has joined #yocto15:16
*** cvasilak <cvasilak!> has quit IRC15:24
*** cvasilak <cvasilak!> has joined #yocto15:30
RPkanavin: thanks, fired with the updated version15:32
kanavinRP: thanks, what is the current plan with the remaining virgl patches?15:34
RPkanavin: waiting on rburton15:36
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto15:38
*** diego_r <diego_r!> has quit IRC15:39
kanavinrburton: ^^^ :)15:41
*** tasslehoff <tasslehoff!~aronning@> has quit IRC15:43
*** tasslehoff <tasslehoff!~aronning@> has joined #yocto15:43
*** hilt0n <hilt0n!b92bf572@gateway/web/freenode/ip.> has quit IRC15:45
rburtonsveinse: surely you remove package management from production images anyway15:47
rburtonkanavin: damnit15:48
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto15:48
sveinserburton: We used to, but it is actually going to change. The reason is that it is extremely difficult to add stuff post-release (e.g. for in-production debugging) without a pkg manager. So we did a risk assessment if what shipping with a pkgmanager would entail security wise. The only thing a pkg manager adds to the table is a database of packages with its member files. It doesn't actually change anything15:51
sveinseon the system, so unless this database is critical, it doesn't hurt having it on board.15:51
*** adelcast1 <adelcast1!~adelcast@> has quit IRC15:51
*** adelcast <adelcast!~adelcast@> has joined #yocto15:51
sveinseIf hackers want to install something on a system, they don't need a pkg manager to do that15:52
*** TobSnyder <TobSnyder!> has quit IRC15:52
*** Crofton|work <Crofton|work!> has quit IRC15:54
*** tprrt <tprrt!~tprrt@> has quit IRC16:00
*** jobroe <jobroe!~manjaro-u@> has quit IRC16:00
*** Bunio_FH <Bunio_FH!> has quit IRC16:04
*** sjolley <sjolley!> has joined #yocto16:07
RPsveinse: if they have the privs to install things the pkgmanager won't make much difference16:18
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC16:19
sveinseRP: they don't have access to the cmd-line, so it would be a breach with or without a pkgmanager. Hence the pkgmanager doesn't add or subtract anything securitywise16:21
*** chandana73 <chandana73!~ckalluri@> has joined #yocto16:25
LetoThe2ndshipping the pkg manager per se is unproblematic. shipping open ssh ports or comparable stuff is much more16:25
*** dkee <dkee!3e9d79e4@gateway/web/freenode/ip.> has joined #yocto16:25
LetoThe2nd(my $.02)16:26
dkeehi all. I am wondering why my eventhandler does only get "bb.event.RecipePreFinalise" , see
*** Aethenelle <Aethenelle!> has joined #yocto16:28
dkeeany idea?16:28
dkeei can see do_compile etc.. and expect
kergothtaskstarted and buildstarted are global, so must be registered in the config metadata. so that even thandler has to be in a .inc or a bbclass listed in INHERIT, not in a class inherited yb a recipe16:29
dkeekergoth: thank you very much! thats it!16:32
*** lusus <lusus!~lusus@> has quit IRC16:43
*** WillMiles <WillMiles!> has joined #yocto16:48
*** Aethenelle <Aethenelle!> has quit IRC16:56
*** suvirb <suvirb!uid16371@gateway/web/> has joined #yocto17:01
*** yann <yann!~yann@> has quit IRC17:06
*** cquast <cquast!~cquast@> has quit IRC17:06
*** cvasilak <cvasilak!> has quit IRC17:10
*** mckoan is now known as mckoan|away17:11
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto17:17
*** Crofton|work <Crofton|work!~Crofton@2a02:a03f:3eec:d700:7580:b159:5a96:14ae> has joined #yocto17:24
*** fl0v0 <fl0v0!> has quit IRC17:30
*** rcw <rcw!~rcw@> has joined #yocto17:34
*** kroon <kroon!> has joined #yocto17:35
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC17:41
*** nighty- <nighty-!> has quit IRC17:42
yatesis there a special "rev=" syntax for SRC_URI for "latest"?17:47
yateslemme guess? "rev=latest"?17:47
*** berton <berton!~berton@> has quit IRC17:48
kergothwhy not use SRCREV, which supports that already?17:48
rburtonyates: you're after AUTOREV17:49
yatesis it as simple as a) SRCREV = "${AUTOREV}", b) remove rev= from SRC_URI?17:55
yatesor would it be (in fell swoop): "SRC_URI = "svn://ebtronwsus/svn/SmartDisplaySoftware;module=${SVNMODULE};protocol=https;rev=${AUTOREV}; ?17:56
RPkanavin: x32 failed in testimage in dnf...17:58
yatessee section 4.4 here:
tgoodwinI have a recipe that depends on a -native package, but the compile task is running before the -native package has installed.  Is that normal?17:59
kergoththat's not how it works.18:07
*** thannoy_ <thannoy_!> has joined #yocto18:11
*** thannoy <thannoy!> has quit IRC18:12
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC18:17
*** yann <yann!> has joined #yocto18:18
yateskergoth: are you responding to me?18:30
yatesERROR: rf-control-1.0-r0 do_packagedata: QA Issue: Package version for package rf-control-dbg went backwards which would break package feeds from (0:1.0-rc2-r0 to 0:1.0-r0) [version-going-backwards18:30
yateshow do i fix these?18:30
yatesit's right, i renamed my recipe since AUTOREV apparently automatically adds "-r0"18:31
*** feddischson <feddischson!> has joined #yocto18:31
*** nate0202 <nate0202!> has joined #yocto18:32
yateswould i just delete everything in the package feeds?18:32
kergoththe fix is not to let your version go backwards. but it's only really a concern if you need upgradability when using package feeds18:32
khemnayfe: I have some local work on influx to get grafana influxdb etc to latest, havent pushed it to community repo on github18:32
kergothit uses packagedata, not packages, and packagedata will just be restored from sstate as needed18:32
kergothpersonally i disable that error quite often, just not that useful for my use cases18:33
yatesi am using smart, and i would like it not to be confused about revisions. in short, i'd like to just nix all those old, previously-named revisions18:33
*** nate0202 <nate0202!> has quit IRC18:33
yatesif i have spend 3 hours rebuilding, so be it18:34
yatescurious: does the r0 suffix get incremented when the autorev revision changes? (automagically?)18:35
yatess/if i have spend/if i have to spend/18:35
yateskergoth: i'm not sure what you meant by "...and packagedata will just be restored from sstate as needed"18:36
yatesare you implying that if i remove cache-sstate, everything will be rebuilt with correct revisions?18:37
yateslet me clarify: i do NOT have existing systems out in the world which would be confused with a backwards package version18:39
*** zeddii_home <zeddii_home!> has joined #yocto18:44
*** sno <sno!> has quit IRC18:53
*** behanw <behanw!uid110099@gateway/web/> has quit IRC18:59
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto19:01
*** sno <sno!> has joined #yocto19:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:09
*** ferlzc <ferlzc!~ferlzc@> has quit IRC19:23
*** tgraydon <tgraydon!~textual@> has joined #yocto19:28
*** zino_ <zino_!> has quit IRC19:30
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto19:32
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto19:39
*** tgraydon <tgraydon!~textual@> has quit IRC19:41
*** tgraydon <tgraydon!~textual@> has joined #yocto19:50
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC19:50
khemRP: so now I sent binutils 2.32 update :)20:04
*** rperier <rperier!~quassel@unaffiliated/bambee> has quit IRC20:04
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has joined #yocto20:04
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC20:17
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto20:17
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto20:18
RPkanavin: and a multilib failure but basically looking better :)20:21
RPkhem: heh, cool20:21
*** kroon <kroon!> has quit IRC20:22
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto20:32
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC20:36
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto20:36
khemRP: I have been carrying it over for few weeks so should be eventless hopefully20:51
*** maudat <maudat!~moda@> has quit IRC20:56
*** feddischson <feddischson!> has quit IRC20:57
*** maudat <maudat!~moda@> has joined #yocto20:58
RPkhem: the commit message is a little terse (why were the patches dropped)20:58
yatesdo you break smart package versioning when you use SRCREV=${AUTOREV}?20:59
RP(I know why but it should say)20:59
yatesyocto seems to always generate a -r0 in that case.20:59
yatesand smart doesn't work.. rebuilding a recipe from a new version "bitbake <pn>", running "bitbake package-index", and then running "smart upgrade <pn>" yields "No interesting upgrades available"21:01
khemRP: most of backports were dropped21:03
yatesrburton: can you help?21:04
khemnothing else21:04
yatesfurther, running "bitbake <pn>" after the repository specified in the SRC_URI bumps a revision does not even do a new build. "Attempt N tasks of which N didn't need to be rerun and all succeeded"21:05
yatesis there a pointer on how to get all this (SRCREV et al.) to work?21:06
yatesi looked for some time and couldn't find the docs for it21:06
*** robbawebba <robbawebba!~rob@> has quit IRC21:07
yatesessentially i want yocto to manage the revision of the package. -r0, -r1, -r2, etc. when the repo revision bumps21:08
yatesor am i confusing everyone?21:08
yatesam i confused?21:09
yateswait..., i have missed some documentation - reading it now. SRCPV and such21:12
khemRP: I Can make it a bit better commit msg wise,21:12
kergothyates: set SRCREV, not rev=, and use SRCPV in PV. that'll ensure bitbake sees the revision change as a variable change and re-run the task21:14
*** peacememories <peacememories!~textual@2a02:8388:8480:fd80:cd06:c5c6:5bd5:47be> has joined #yocto21:15
khemRP: sent a v221:19
yateskergoth: like this?
rburtonyates: turn on pr service21:20
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto21:20
yatesrburton: huh? "pr" service?21:21
yatesyou mean irc private message?21:21
kergothno, PR as in the recipe variable. the PR server maintains a db to bump PR automatically whenever appropriate changes occur21:21
kergothyates: PV .= "+svn${SRCPV}" is probably sufficient. the := stuff is just unnecessary, and + is a common convention for an scm based version suffix21:22
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC21:29
*** rcw <rcw!~rcw@> has quit IRC21:31
yateskergoth: thanks21:34
yatesrburton: thanks, but admittedly i didn't follow that21:34
yatesso if you use svn, you really don't need the PR service as their revision numbers always increment?21:35
rburtonassuming you embed the revision into the PV yes21:36
rburtonif you have a feed you want PR service21:36
yatesi do21:36
rburtonbecause no other recipe has an incrementing PR21:36
yates"because no other recipe has an incrementing PR"...? OH. you mean the PR only increments for the recipe that is being updated?21:38
rburtonPR is a recipe variable21:38
rburtonits part of the version21:38
rburtonr3 is PR21:38
rburton"Package Revision"21:38
*** peacememories <peacememories!~textual@2a02:8388:8480:fd80:cd06:c5c6:5bd5:47be> has quit IRC21:38
rburtonthe PR service bump the PR every time a recipe is rebuilt, because if it was rebuilt it potentially changed21:38
rburtonotherwise, a feed is pointless21:39
* yates looks up meaning of PV21:41
rburtonPackage Version21:41
kergothyates: modify a recipe, add a patch to SRC_URI. the version in the binary package won't change unless you use the PR service or explicitly bump PR manually every single time you make a cahnge.21:42
rburtontypically *upstream* version21:42
kergothyates: the only exception is scm recipes, since we have srcrev/srcpv21:43
rburtonoh the good old days of "change configure option" patches followed by "forgot to bump PR" patches21:43
kergothbut even that benefits from it,s ince not all changes are source changes21:43
kergothugh, yes, that was horrible21:43
yateswhat would be wrong with using SRCPV to set the PR? bastardization perhaps, but wouldn't it work (for svn)?21:44
rburtonbecause if your recipe changes from --disable-foo to --enable-foo, the revision ID hasn't changed21:45
rburtonstill the same upstream commit21:45
rburtonbut the package is definitely different21:45
rburtonlets not even think about you change a *class* that some of your recipes inherit21:46
*** khem <khem!~khem@unaffiliated/khem> has quit IRC21:46
yateswas the PR service available on Morty?21:49
kergothif you aren't maintaining and using a package feed for more than just image construction, you may well not need the pr server at all. bitbake checksums the metadata nd will use the new packages to build the images when you change the recipe anyway21:51
kergotha lot of folks don't use a package manager to deploy upgrades. if i'm going to reflash every time, or roll it out with swupdate, it doesn't really matter21:52
kergothdepends on your needs21:52
yatesi have found a package manager so useful just in development that i'd like to maintain it.21:52
rburtonyates: looks like its 1.4 onwards21:52
yateswell what i had in mind for this project right now was to fix my PV to 1.0 (production 1.0) and allow the PRs to roll with svn updates. e.g., loadrfcontrol_1.0-r0, then loadrfcontrol_1.0-r1 if the source changes.21:54
kergothi kind of wish runqemu automatically started up a web server pointing at our package feed after re-indexing it and configured the runtime to point at it somehow21:54
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto21:55
rburtonyates: that would be abusing PR, just put the svn id in the PV21:55
rburton1.0+svn10 etc21:55
yateswhy would you call that a version and not a revision?21:56
rburtonrevision implies upstream didn't change21:56
rburtonPV is the upstream version21:56
yateswhat is upstream?21:56
rburtonyates: the software, not the recipe21:56
rburtonkergoth: sort of works :)21:57
kergothhuh, indeed, pretty close21:57
rburtonkergoth: though the autobuilder can destroy simpleserver in automated qa21:57
kergothi'll have to play with that, thanks. it's so common for me to forget to include a package in an image during development and testing21:58
rburtonkergoth: i think i actually used it to install a package so it *works* but isn't finished21:59
* kergoth nods21:59
yatesrburton: so you mean to say that, typically, the upstream doesn't changed between r0 and r1, e.g.?21:59
rburtontypically no, unless you count adding a patch. which wouldn't be a PV change but a PR.21:59
yatesso policy is that a change to the upstream changes the PV?22:01
rburtonwell, that's typical22:01
yatesno wonder i've been confused..22:01
rburtoneither the tarball being fetched gets a new version22:01
rburton(new PV)22:01
rburtonor the vcs checkout is a new revision, which is the version22:02
rburtongod i wish i could remember how bash read worked22:02
yateswhat i'm doing (right or wrong) is to set the SRC_URI to a specific branch (branches/production-1.0) and to consider THAT the version and then auto-increment the revision on updates in that branch.22:03
yates(or rather, what i'm intending on doing)22:04
rburtonwhereas what the convention is, is to use SRCPV22:04
rburtonrecipes-extended/libnsl/ = "1.2.0+git${SRCPV}"22:04
rburtonto pick a random recipe22:04
rburtonas kergoth said a while back22:05
kergothrburton: ugh, i *hate* 'read' in shell scripts. i use it all the time, but it pisses me off22:06
kergothi *want* it to be useful for columnar data, but it can't handle empty fields. or rather it compresses them22:06
kergothprintf 'foo\tbar\t\tbaz' | read -r a b c d -> 'baz' is in c, not d22:06
rburtonso i am doing it right: echo foo bar fish | read a b c   should mean that echo $a is foo22:07
rburtoni'm just getting blank :(22:07
kergothit should, but there are caveats based on when shell creates subshells22:08
rburtonsee i hate read22:08
kergothin posix sh that wont work because the use of the pipe basically creates a new shell conceptually.. that is, the vars are only valid in the context of the right side of the pipe22:09
kergothi.e. echo foo bar baz | ( read a b c; echo $a ) should give correct results22:09
rburtongoddamnit bash22:09
rburtonthat was it22:09
rburtonso i just need to wrap this in a block22:09
kergoththat's what i usually do, yeah22:10
kergothoccasionally it pisses me off. like i'll want to do cat somefile | foo | while read -r a b c; do foundit=1; done -> found it is *not* 1, since the vars set in the while don't hit the main shell22:10
kergothbut if you read from a file with a redirect, it doesn't hit that issue22:11
kergothso sometimes need a temporary file just to sidestep that issue22:11
yateskergoth: when you wrote: PV .= "+svn${SRCPV}", is the leading "+" a literial "+" (or, e.g., a concatenation operator)?22:12
yates.= is concatenate, right?22:12
* yates looks for the section of the manual on variable constructions22:13
kergoth"Command substitution, commands that are grouped with parentheses, and asynchronous lists shall be executed in a subshell environment. Additionally, each command of a multi-command pipeline is in a subshell environment; as an extension, however, any or all commands in a pipeline may be executed in the current environment. All other commands shall be executed in the current shell environment." there it is. "Additionally, each command of a multi-command22:16
kergoth pipeline is in a subshell environment", running in the current envirionment is an optional extension!22:16
kergothfrom POSIX.1-200822:16
kergoth -> shell & utilities -> shell command language -> shell execution environment22:16
yatesis that syntax basically python's string manipulation syntax?22:17
kergoth.= is concatenation, yes22:17
kergothas i said earlier, + is a convention in some version strings to separate the component of the version referring to the scm rev22:17
yatesyes, but i put a "-" there and still saw a "+:"!22:17
kergothas rburton said, i.e. "1.0+svn10 etc"22:18
rburtonyates: grep oe-core for SRCPV, loads of examples22:18
kergothyeah, good call22:18
yatesjust trying to understand why22:18
*** ferlzc <ferlzc!~ferlzc@> has quit IRC22:18
yatesseeing things..22:19
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto22:22
rburtonkergoth: ten minutes of argh because i put foo3.img instead of foo.img322:22
rburtonno wonder the read was returning blank22:23
kergoth and mostly inspired the original notion of epoch/version/revision in oe as originally the tooling was portage based and the distro was debian based. trying to have a single versioning system work for every upstream version scheme *and* be compatible with any arbitrary target binary package management system is .. a bit of a pain at times22:23
rburtonbut i do now have my recipe, erm, extracting an ext partition from a disk image22:23
kergothI actually think equinox p2's "omniversion" scheme is really interesting. it lets you encode the versioning scheme / how the version is parsed by supplying a format string in the omniversion string. completely self contained, no need for a central handler for it22:24
*** WillMiles <WillMiles!> has quit IRC22:28
kergothyates: + is also the convention for pre-releases. 0.9+1.0rc0. that way 1.0 is still seen as newer, rather than 1.0rc being seen as newer than 1.022:28
kergothjust as an fyi22:28
rburtonof course we can now do 1.0~rc122:29
rburtonwhich sorts before 1.022:29
kergothah, true, forgot that was added22:29
rburtonmy do_install now has fdisk, dd, and debugfs calls in.22:32
rburtondo i win a prize?22:32
RPrburton: scary :)22:33
rburton[41924.676444] print_req_error: I/O error, dev sdc, sector 2460676822:37
rburtonoh ffs22:37
rburtonnow my usb stick is dying22:37
yoctiNew news from stackoverflow: How can I force bitbake to find my libraries? <>22:41
*** scottrif <scottrif!> has joined #yocto22:52
rburtondebugfs created a file called /this/is/the/long/path/i/wanted in the root of the file system22:54
rburtonthat is not funny22:55
*** chandana73 <chandana73!~ckalluri@> has quit IRC22:56
*** chandana73 <chandana73!~ckalluri@> has joined #yocto22:58
bluelightningcan someone help out scottrif and comment as to whether this is a workaround for a bug or a genuine requirement that we should list?
yoctiBug 13164: minor, Undecided, 2.7 M4, srifenbark, NEEDINFO , Include libncurses-dev in the list of required packages22:58
scottrifthanks Paul22:58
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto22:59
rburtonthats a duplicate22:59
rburtonnow wheres the original22:59
rburtonscottrif: closed :)23:00
scottrifrburton: thanks23:01
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC23:02
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto23:02
bluelightningcrazy, the two bugs were even number anagrams of eachother :D23:02
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC23:05
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto23:05
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto23:08
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto23:08
rburtonyeah i noticed that :)23:08
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:09
RPrburton: I'm trying not to smile. Sorry.23:12
*** rburton <rburton!> has quit IRC23:37
*** chandana73 <chandana73!~ckalluri@> has quit IRC23:46

Generated by 2.11.0 by Marius Gedminas - find it at!