Wednesday, 2019-09-04

*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto00:16
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC00:39
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC00:41
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC01:05
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC01:07
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto01:08
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has quit IRC01:10
*** kaspter <kaspter!~Instantbi@2409:8928:66c:b82:8078:23da:9db1:7d7b> has joined #yocto01:12
*** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto01:25
*** tgraydon <tgraydon!~tgraydon@> has quit IRC01:40
*** Dracos-Carazza <Dracos-Carazza!> has quit IRC02:00
*** Dracos-Carazza <Dracos-Carazza!> has joined #yocto02:00
*** kaspter <kaspter!~Instantbi@2409:8928:66c:b82:8078:23da:9db1:7d7b> has quit IRC02:14
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:34
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC03:07
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto03:09
*** FailDev <FailDev!18d83107@> has quit IRC03:57
*** chinhuat6479 <chinhuat6479!~chinhuat@> has joined #yocto04:02
*** chinhuat647 <chinhuat647!~chinhuat@> has quit IRC04:04
*** anujm <anujm!~anujm@> has joined #yocto04:15
*** anujm <anujm!~anujm@> has joined #yocto04:21
*** kroon <kroon!~kroon@> has joined #yocto04:22
*** kroon <kroon!~kroon@> has quit IRC04:26
*** kroon <kroon!~kroon@> has joined #yocto04:27
iceawayI have created a small test application for the sake of learning how to create a custom recipe. The test application is using CMake. When I build this recipe in bitbake I get the error message: "do_package: QA Issue: anpr-test: Files/directories were installed but not shipped in any package:". Could this be because the install dir in the CMake description does not use the default "bin" directory, but04:30
iceawayrather a custom directory under /?04:30
krooniceaway, sounds likely04:32
krooniceaway, unusual files like that need to be explicitly listed in FILES_*04:33
krooniceaway, but you can use wildcards when listing04:33
iceawayOk great, thanks.04:34
nrossiRP: just started looking at the autobuilder runs with the toolchain test patches... I realised its running everything :| aka both gcc/glibc with user and system qemu. That will take awhile :|04:37
zeddiiRP: finally I have the systemtap issue reproduced on my mips64 image. it’s 12:40 am here, so I’ll pick it up in the morning. I assume that your uprev in master-next didn’t sort it out.04:40
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto04:43
*** anujm <anujm!~anujm@> has quit IRC04:45
iceawayI'm trying to use wic to create a custom partitioning scheme for my image. I have setup two partitions / and /anpr. But when I try to create the image I get an error message: "ERROR: Nothing PROVIDES '${IMAGE_ROOTFS}/anpr'". I can see that /anpr is present in the tar.gz version of the rootfs in my deploy/images directory. Any ideas?04:56
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC05:07
yoctiNew news from stackoverflow: bitbake failed with ExpansionError <>05:08
*** AndersD <AndersD!> has joined #yocto05:18
yoctiNew news from stackoverflow: OpenBMC with Raspberry Pi (2 or 3) and build bmcweb? <>05:38
*** agust <agust!> has joined #yocto05:50
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto06:07
*** TobSnyder <TobSnyder!> has joined #yocto06:16
*** alessioigor <alessioigor!~alessioig@> has quit IRC06:36
*** chinhuat64799 <chinhuat64799!~chinhuat@> has joined #yocto06:39
*** chinhuat6479 <chinhuat6479!~chinhuat@> has quit IRC06:40
*** feilz <feilz!> has joined #yocto06:48
feilzHello, I stumbled upon something strange with the bitbake build system.06:48
*** AndersD <AndersD!> has quit IRC06:49
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto06:50
feilzin my project at work, it seems that when I have two packages, and the first package has a dependency on the second package. If i update the second package, rebuilding the first package doesn't automatically update the cached dependency06:50
feilzmeaning that I might rebuild the first package, using the old version of the second package, even though the second package has been updated06:51
MarcWedo you have SRCREV = "${AUTOREV}" ?06:52
*** frsc <frsc!> has joined #yocto06:52
feilzno. They are two local packages06:52
feilzas both packages are fairly small06:52
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto06:53
feilzso far only way I found that solves this issue is by manually deleting the cache of the first package06:54
*** learningc <learningc!> has joined #yocto06:54
MarcWebitbake is not rebuilding if it is sees that the bb file is not changed06:54
feilzahaa... then that would be the cause, even if the compiled package is different06:55
MarcWedo you have your package in a git repo ( on your local machine ) ?06:55
feilzboth packages are in the same git repo on my local machine06:56
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:56
MarcWeyou can do a git init an somthing like  SRC_URI = git:///Data/Development/Qt/package1;protocol=file;branch=${BRANCH}06:56
MarcWeSRCREV = "${AUTOREV}06:57
feilzi feel like you are not exactly following the problem I'm describing, as this is not related to git (as far as I know).06:57
MarcWehow do you store the local package?06:58
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC06:58
*** anujm <anujm!~anujm@> has joined #yocto06:58
feilzin my companys git repository, both inside the same layer06:59
qschulzhow do you "update the second package" ?07:00
feilz"bitbake -c compile second-package-name"07:01
MarcWeo wait, do you have ${SRCREV} in your PV var this will trigger rebuild if the git repo is updated07:02
feilz@MarcWe I have taken advantage of that when it's linking two different git repos together in the same layer. However, in this situation that is not the case.07:03
qschulzfeilz: you've done something before that which is requiring you to run do_configure. What?07:03
feilzmodifying the source files07:04
qschulzmodified the source code? modified the recipe? what did you do?07:04
qschulzfrom where?07:04
qschulzI mean, where did you operate the changes for the source code? in the workdir? how do you fetch the sources?07:04
feilzuhh... inside the folder where the second package .bb directory07:04
qschulzfeilz: are you adding directories in SRC_URI by any chance?07:05
qschulzRP: FYI, plain text version of "Yocto Project Status WW36’19" mail I received is unreadable. It's missing new lines (at least).07:07
*** feilz <feilz!> has quit IRC07:09
qschulzfeilz you shouldn't have to run compile for the package, the dependency should be pulled because there's been a change in one the source file. So something makes Yocto think the source files were not updated (or somethng is saying to avoid rebuilding)07:10
*** feilz <feilz!> has joined #yocto07:10
RPqschulz: hmm, it was entered as html as that is what stephen normally does so something went wrong. You can also read it on the wiki07:11
feilzsorry, crash on my end. qschulz we use SRC_URI = "file://*" to include all files07:11
MarcWefeilz: that way bitbake is not seeing change to the bb file content so it not rebuilding ( if you change things in "file://*" )07:13
*** jmiehe <jmiehe!> has joined #yocto07:14
feilzif I included all files manulally such as SRC_URI = "file://files/filename1.c \ file://files/filename2.c", the change would be seen?07:14
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:16
*** S54 <S54!2eeb996e@> has joined #yocto07:16
MarcWefeilz: im not shure about that. but sins * is not working i think it is not getting picked up07:19
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC07:21
*** feilz <feilz!> has quit IRC07:21
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:22
S54I'm facing "file /lib/systemd conflicts between attempted installs of"  while doing a rootfs, can't figure out why but it happens whereas i'm installing different files from different packages. Could this also apply on directories?07:24
*** feilz <feilz!> has joined #yocto07:26
*** kaspter <kaspter!~Instantbi@> has quit IRC07:26
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:26
feilz@qschulz the browser based irc client kept crashing on me... switched to command line. probably missed any questions / messages that came after my last comment07:27
feilzbasically i know the reason why rebuilding the first package failed, as the .bb file didn't change of the dependency.07:30
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:30
feilzone suggestion for implementing to bitbake would be an option to force rebuild dependency packages of the package im building, to avoid having to manually delete the cache07:30
*** User_ <User_!> has joined #yocto07:31
feilzwould perhaps be cool as well if it would be incorporated to "bitbake -c cleanall packagename" as well07:31
LetoThe2ndfeilz: i guess you rather need to look at PR/PV in depth07:31
*** yann <yann!~yann@> has joined #yocto07:31
LetoThe2ndfeilz: because bitbake intentionally rebuild when it gets told that has been a change, and does not rebuild when not being told07:32
feilzaaaa... now i remember reading about that...07:32
*** likewise <likewise!~leon@> has joined #yocto07:33
qschulzLetoThe2nd: I also have the same issue. When using directories with SRC_URI, if you change the content of the files, Yocto does not detect the changes and do not rebuild07:33
*** learningc <learningc!> has quit IRC07:34
LetoThe2ndfeilz: as well as rethinking the recipe/source structure. because if you have one source repo building several packgaes, it might be helpful to actually pour it into one recipe that provides additional packages.07:34
LetoThe2ndqschulz: directories, as "something local on your disk"?07:34
qschulzLetoThe2nd: meta/recipes-foo/foo/ SRC_URI = "file://bar" and then meta/recipes-foo/foo/bar/main.cpp07:35
qschulzchange main.cpp, nothing gets rebuilt07:35
feilzLettoThe2nd: rethinking the recipe/source structure won't be necessary in this situation. The problem I describe is what qschulz now highlights (apparently much better than I managed to do)07:36
LetoThe2ndi see what you mean, but in my opinion sticking source into the layers is a super bad practise anyways, and those who do it deserve to be punished :-P07:36
feilzif I use PV="0.1" and then bump that number, that should force a rebuild of main.cpp07:37
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:37
qschulzfeilz: maybe even PR IIRC07:37
qschulzbut not great07:37
qschulzLetoThe2nd: well, it does not have to be specific to code actually07:38
qschulzI can have configuration files there07:38
feilzespecially when doing some minor fixes, having to bump for every character change or minor bugfix does seem excessive07:38
*** yacar_ <yacar_!~yacar@> has joined #yocto07:38
LetoThe2ndqschulz: sure, i know what you mean. taking me overly serious is a bad practise too :)07:38
qschulzfeilz: -c cleanall for the package you're modifying07:38
qschulzLetoThe2nd: well, I don't like it myself as well but ATM, things are how they are07:38
feilzoh... that's how it's solved07:39
qschulzfeilz: no, worked around :)07:39
qschulzsorry, -c cleansstate is enough IIRC07:39
feilzanyways, hope I managed to bring this issue to light... glad we managed to find a workaround. Took me a day of bughunting yesterday to notice this :)07:40
*** S54 <S54!2eeb996e@> has quit IRC07:40
qschulzLetoThe2nd: do you have more input on why it is working that way? It seems to be a known "issue". Is there a reason for not fixing it?07:40
qschulzfeilz: been there :)07:41
qschulzLetoThe2nd: which could well be "nobody took time to send a patch". But maybe there was something already posted and got rejected for a reason.07:41
LetoThe2ndqschulz: in a nutshell it is like this: "bitbake decides what do based on looking at the recipe". so if it looks at the recipe, nothing changed, then nothing is to be done07:42
LetoThe2ndqschulz: it can be forced to behave differently by applying stuff like externalsrc, but thats the main reasoning.07:42
qschulzLetoThe2nd: well... it knows when a file from SRC_URI is changed07:42
qschulzso can't we have a glob there of the content of directories?07:43
qschulzI guess there is something like the hash of the files in SRC_URI in the sstate-cache to know if it's changed/07:43
*** S54 <S54!94401315@> has joined #yocto07:44
tprrtHello, I have a question about the ccache bbclass which has been reworked, but the mega-manual seems not to be up to date and advises against using it, is this advice still valid?07:46
LetoThe2ndno, it does not07:46
LetoThe2ndAFAIK it does *not* look at the files mentionend in SRC_URI, only at SRC_URI itself07:47
LetoThe2ndbut there are others you can explain siggen way better than me.07:47
S54can't find what DIRFILES does in the mega manual, am I missing sth?07:48
qschulzLetoThe2nd: that's something I haven't looked at yet and I'm eager to know about it a bit more :) so if anyone has pointers...07:48
LetoThe2ndqschulz: hand over beer to RP :)07:49
LetoThe2ndi think theres also a tool like bitbake-diffsigs or such07:50
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC07:55
qschulzRP: thanks, I just wanted to give a headsup as previous mails (last week's was broken as well IIRC though) were readable. Nothing to worry about, I still can open the html version, but you know.. one more key press :D07:57
RPqschulz: FWIW a glob of files should correctly notice when they change07:59
*** goliath <goliath!> has joined #yocto08:04
RPqschulz: you can understand a bit about it by doing bitbake-dumpsig on tmp/stamps/XXX/YY.do_fetch.sigdata08:04
RPThat will tell you what makes up the data bitbake uses on that task08:05
*** S54 <S54!94401315@> has quit IRC08:07
*** ms_k <ms_k!> has joined #yocto08:15
MarcWeIm trying to do some app development for my target using qt creator but im getting the error: /usr/lib/ version `GLIBCXX_3.4.22' not found (required by08:17
RPMarcWe: on target or using native tools on the host?08:19
MarcWeon the target08:19
RPthat sounds like trying to run newer binaries on a older target toolchain08:19
RPgcc and glibc aren't matched up08:20
MarcWeyes but im shure that i loaded up the correct tool chain08:20
RPMarcWe: that error says otherwise, it looks like glibc is probably too old08:21
*** Proffalken <Proffalken!uid388181@gateway/web/> has quit IRC08:25
*** Bunio_FH <Bunio_FH!> has joined #yocto08:32
RPnrossi: happen to be around?08:36
yoctiNew news from stackoverflow: Description of files that are in image files folder in Yocto project and the boot sequence of Yocto linux <>08:39
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:42
*** kaspter <kaspter!~Instantbi@> has quit IRC08:46
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:47
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:48
*** Bunio_FH <Bunio_FH!> has quit IRC08:54
*** Bunio_FH <Bunio_FH!> has joined #yocto08:55
nrossiRP: i am now09:00
RPnrossi: I've run the series on the autobuilder and the gcc tests are going crazy. I've locally tracked it down to all the headers in gcc/include/*.h containing just the word "timestamp"09:01
*** Bunio_FH <Bunio_FH!> has quit IRC09:02
RPnrossi: I had to add python3-pexect and python3-ptysomething to the build to make it work. We also need to add inherit nopackages to glibc-testsuite.inc09:02
RPnrossi: those python3 bits and the dejagnu are missing from too09:02
RPnrossi: any idea why "timestamp" would end up in those headers?09:03
nrossiRP: for the gcc ones I thought that might be due to builddir issues due to the multiple processes running with selftest but I had not looked into it. Though you say you have reproduced it on a local build without rm_work?09:03
RPnrossi: right, I don't use rm_work, nor does the autobuilder09:04
RPnrossi: its appeared on both09:04
nrossiRP: for the python-pexpect, i saw that when looking at the autobuilder logs. I completely forgot to check those packages. They are only there to make a FAIL -> UNSUPPORTED, needs gdb to actually run the tests. I am looking at that atm09:04
nrossiRP: I will wipe away my sstate and see if i can reproduce.09:05
RPnrossi: this sounds like criticism, its not meant as such btw :) It is great to see this so close!09:05
nrossiRP: dont worry, I have not taken your words in that way. Getting this stuff working is lots of moving pieces and I expected issues :)09:07
RPnrossi: I'm struggling with too many issues which we're struggling to debug right now :/09:08
nrossiRP: one question I did have seeing the builds running, is did you actually want to have all machines running all usermode and system emu tests?09:08
nrossiRP: I have been following, sorry if i'm taking too much of your time away from more important tasks09:09
RPnrossi: this is important! :)09:09
RPnrossi: I'm just mentioning this in case I seem a little distracted09:09
RPnrossi: no, we probably don't want both usermode and system09:10
RPnrossi: I think that was my naive way of running things09:10
nrossiRP: probably need a "manual" tag or similar to put on some of the tests. And possibly change the selftest -t to a "tags of test must match those in list of supplied tags"09:11
RPnrossi: not quite decided how to integrate into the autobuilder yet, this was just a quick hack to start testing09:11
nrossiRP: no problems, I was mostly focused on getting everything working with the v2 series with less emphasis on autobuilder setup09:12
RPnrossi: right, and I wanted to get something run so we could find any issues with that piece. I'll ponder the integration a bit more but you're right, we need to select between the user and system modes09:13
RPnrossi: it may be enough just to tag them differently and run machine,toolchain-system or machine,toolchain-user or something that simple09:13
nrossiRP: possibly, I was just thinking about having the system emulated glibc tests running for x86-64 by default though09:14
feilzschulz: lettoThe2nd: one possible solution that could solve the issue we talked about is to modify file checking to take chksum of all files included, and compare that to the new version. Think it could work?09:16
RPnrossi: it gets tricky as you'd want to do something different on an arm host :/09:16
*** sbach <sbach!~sbach@> has quit IRC09:17
*** sbach <sbach!~sbach@> has joined #yocto09:18
*** anujm <anujm!~anujm@> has quit IRC09:19
nrossiRP: I will have a bit of a think about it, see if there is a decent solution09:19
RPnrossi: ok. We do have a bit of time pressure now to get something ready for 3.0 even if its not perfect09:20
nrossiRP: of course, i meant think as in whilst sorting out some of the current issues :)09:21
RPnrossi: fair enough :)09:21
nrossiRP: also should I put the maintainers as those that already mantain said recipes, e.g. binutils, glibc?09:21
RPnrossi: yes, I think that is khem09:22
qschulzRP: I didn't know about those. Thanks :)09:22
nrossiRP: and for dejagnu who should I put? it is not a hard recipe to maintain so I am not against putting my name if nessecary09:22
RPnrossi: the python ones are trickier but even better if we don't need them09:22
RPnrossi: volunteers are very welcome to spread the load09:22
nrossiRP: if the gdb tests don't work anyways I think its probably just easier to drop them so they appear as "FAIL:"09:23
qschulzRP: well, the issue is that SRC_URI = "file://dir" does not add the files of this directory to the "This task depends on the checksums of files:" list. SRC_URI = "file://dir/*" as well. HOWEVER, SRC_URI = "file://dir/" does.09:23
qschulzfeilz: ^09:23
qschulz(well, both RP and feilz actually)09:23
RPqschulz: probably time to add a new selftest to the bitbake test suite and fix it...09:24
RPqschulz: it sounds a bit like a bug09:24
feilzi'm not a bitbake developer, started using bitbake about 2 months ago when i started at my current employer :)09:28
qschulzLetoThe2nd: see, there is a point in having people "misuse" Yocto, you get to find bugs :D09:29
feilzbut glad that I could help the community :)09:29
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto09:29
qschulzfeilz: add everything in a subdir so that you can include SRC_URI = "file://subdir/"09:30
feilzand it does seem like the "misuse" of Yocto is a little more widespread, as I know at least 2 of the client companies that this company works for does the same setup09:30
qschulzalso IIRC, we didn't see the issue when it was a simple * but a *.c for example09:30
qschulzfeilz: don't forget the trailing slash09:31
LetoThe2ndqschulz: certainly!09:31
RPnrossi: I just reproduced the header thing again. cleansstate of gcc-cross-x86_64 and gcc-runtime09:31
feilzi'll give it a go. Let's see if this works as expected09:31
RPnrossi: inspected the headers in gcc-cross-x86-64's gcc stash builddir and they were fine. Build gcc-runtime, they're not09:31
RPnrossi: I'll dig a bit more09:32
qschulzfeilz: my issue with Yocto is that the ramp up is long so it does not get much interest from people for which Yocto is the tool and not the goal. Also, it is pretty much possible to have something that works "good enough" you don't experience the issues before a long time (not writing in the sstate cache output dirs for example). Which results in people having bad Yocto layers "but it works" TM09:33
feilzyeah... I understand09:34
LetoThe2ndqschulz: s/"but it works"/"doesn't break enough for me to care"/09:34
RPnrossi: gcc-cross-x86_64:do_install destroys the files09:35
RPnrossi: looks like a race where "make install" messes with the hardlinked files09:36
qschulzLetoThe2nd: the number of times I see people cleaning the whole build dir/sstate cache because there is an error in the build they don't understand/want to fix and a fuild rebuild/build fromsstate cache fix the issue.09:37
nrossiRP: but do_gcc_stash_builddir is supposed to be run before do_install :|09:37
nrossiRP: oh right, you mean onces the hardlinking is done but before the sstate part of the task?09:38
yoctiNew news from stackoverflow: GitLab CI Yocto Build - How to use SSTATE and DL_DIR <>09:39
kroonqschulz, you should tell them to file bugs. I've not had any problems with reusing sstate-cache for ages09:41
RPnrossi: the hardlink is done before do_install, gcc messes up the hardlink09:42
RPnrossi: it will be this: Makefile:STAMP = echo timestamp >09:42
feilz@qschulz: tested out moving it into it's own directory, and when doing that make fails, due to no makefile found.09:42
feilzeven though that does exist in that folder.09:43
qschulzfeilz: S = "${WORKDIR}/dir"?09:43
*** yacar_ <yacar_!~yacar@> has quit IRC09:44
RPnrossi: the "move-if-change" stuff09:44
nrossiRP: ok, i'm not fully aware of how the sstate-inputdirs stuff works, but does it not store the content in sstate before the task is "complete"? or is the issue that the hardlinks are kept to populate the outputdirs immediately instead of from the sstate binary?09:44
qschulzkroon: my goal now is to get rid of as many warnings as possible so that we have a clean build. Then teach people to not ignore the warnings (except those I couldn't get rid of and explain why), either to report them or to fix them09:44
qschulzkroon: and in the end have them report anything that is not looking normal09:45
kroonqschulz, I apologize, I think I misread your sentence09:45
qschulzkroon: didn't see you misinterepreted it >< it matched both situations :D09:46
kroonqschulz, :-D09:46
tprrtThe advise about the ccache.bbclass from the mega-manual, is this advice still valid on Warrior?"09:47
qschulzfeilz: also... might be actually a good idea to have the code outside of the yocto layers and use externalsrc instead?09:47
qschulzif it's actually code, it's better to use externalsrc IMHO (if you can't/don't want to have it in a git repo)09:49
qschulzanything else, I find it okay to use in-layer files. but you know, IMO. I don't have extensive knowledge about best practices09:50
feilzqschulz: I do agree to that, but the project is too far in already to have them modify the project structure any longer.09:51
feilzI do agree with what you are saying, and the previous project I did in this company we had that. Was far easier to manage :)09:51
feilzbut yeah, I'm getting forward, and that problem is long gone. Seems I still have other issues, but I'll work them out 1by1 :)09:52
qschulzfeilz: :)09:53
qschulzRP: another issue with dirs in SRC_URI. If you have dir1/dir2/myfile and dir1/dir3/myfile (same hash for both). If you remove one, it does not recompile.09:54
qschulzif you have dir1/dir2/myfile and you add the same file to dir1/ for example. Does not retrigger the fetch09:54
qschulzmy understanding of bitbake-dumpsig is that we store the name of the file and its hash and not the path to the file09:55
qschulzsorry, even worse, any file duplicated in SRC_URI, wherever it's from won't trigger a refetch. Again, my understanding of bitbake-dumpsig, happy to be told I'm wrong09:58
*** griffinp <griffinp!griffinp@gateway/shell/linaro/x-otxlgrsgngkzwvxg> has joined #yocto10:00
RPqschulz: I think you may be right. Could you file bug reports please so we don't lose the info and can investigate?10:01
feilzqschulz: hmm... actually I may have been wrong... doesn't seem like my issue got solved after all... running bitbake package-2-name passes just fine, and no issues anywhere. however bitbake package-1-name seems to still carry some extremely old version of package-2, that makes building of package-1 fail.10:03
feilzrunning cleanall in between doesn't seem to change anything10:05
qschulzfeilz: how's the dependency on package-1 explicited in package-2?10:06
feilzDEPENDS = "package-1"10:07
kroonqschulz, SRC_URI = "file://dir" seems to work here..10:10
feilzkroon: yeah, I noticed the same, and it seems to work for me as well.10:11
*** User_ <User_!> has quit IRC10:12
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto10:13
kroonqschulz, cleansstate for recipe, rebuild recipe, check with bitbake-dumpsigs10:14
kroonqschulz, SRC_URI = "file://dir/*" does not work, but not sure if that is a bug10:15
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC10:16
*** rburton <rburton!> has joined #yocto10:19
kroonqschulz, found which has some information10:22
nrossiRP: makes sense, I did not realize that the sstate -> sysroot-components also used hardlinks as an optimization10:26
nrossiRP: even the sysroot-components -> builddir extraction might be problematic10:27
RPnrossi: we use a lot of hardlinks although most of our edit scripts do know to break them10:28
RPnrossi: queued as well10:30
RPnrossi: also, we may need to think about the exit code of the toolchain tests. "fail" isn't going to help the autobuilder10:31
RPnrossi: I think we mark ptest as exepected fail or something :/10:31
nrossiRP: yer, also the logging of the failed tests is not partically helpful when 150000 of them fail ;)10:31
RPnrossi: I'll rerun with those two fixes and see how that looks10:33
*** learningc <learningc!~learningc@> has joined #yocto10:36
RPnrossi: output looks much better locally now!10:37
yoctiNew news from stackoverflow: How should the sstate-cache directory be deleted in Yocto? <>10:39
qschulzkroon: define "SRC_URI = "file://dir" seems to work here.." ?10:43
__angelocan i build another recipe form a function added by addtask ?10:45
nrossiRP: ok cool. For the pexpect/gdb stuff, the tests do pass with gdb on target. But it requires configuring gdb with python enabled which is not default in oe. So ignoring the tests would probably be fine. Any opinions?10:45
RPnrossi: enabling python for target gdb probably isn't that bad of an idea10:46
nrossiRP: by default or just in the glibc test config?10:46
nrossiRP: glibc selftest*10:46
RPnrossi: maybe by default?10:47
RPrburton: any opinion ?10:47
qschulz__angelo: first, what are you trying to do? It seems wrong at first sight.10:48
__angeloqschulz, i am trying to have an initramfs image together with a rootfs image10:49
__angelo*build together10:49
feilz__angelo: I think the solution you are looking for is 'require otherRecipe'10:50
feilznot inside an addtask, but just inside the image recipe10:50
qschulzqschulz: we talked about it right? it didn't work what I suggested?10:51
__angelofeilz, thanks, but at least the only "require" is not triggering the image to build10:52
__angeloqschulz, no didn't worked10:52
feilzahh, that's right10:54
feilzrequire adds everything from that other file into the location where you have require10:54
feilzbut doesnt run it10:54
*** learningc <learningc!~learningc@> has quit IRC10:55
feilzhence you have to make a call somewhere that activates the build sequence for the other image10:55
kroonqschulz, bitbake recipe, touch new-file-under-dir, bitbake recipe again, bitbake-dumpsigs says fetch depends on newly touched file10:55
feilzor solve it some other way10:55
*** learningc <learningc!~learningc@> has joined #yocto10:55
rburtonnrossi RP: struggling to have a strong opinion. the tests should definitely skip if python isn't enabled. if we're doing special builds for the gcc tests then its trivial enough to turn py on in that setup.10:58
rburton(skipping if py isn't present should be an upstreamable change)10:58
rburtonRP: are we dropping gcc8.3 from master?10:59
RPrburton: very tempted to, nobody's objected yet11:00
*** yacar_ <yacar_!~yacar@> has joined #yocto11:03
nrossirburton: currently the tests fail if python or pexpect is not available, but mark unsupported if gdb is not present or if its missing python support in gdb. So its a query as to whether the addition of python-pexpect in oe-core and having to configure gdb with python is worth the test result.11:18
*** tprrt <tprrt!> has quit IRC11:19
nrossiRP: also, should I make these various changes as additional patches or v3 of the previous series?11:20
*** tprrt <tprrt!> has joined #yocto11:20
*** jofr <jofr!~jofr@> has quit IRC11:23
*** jofr <jofr!~jofr@> has joined #yocto11:25
*** mads_andreasen <mads_andreasen!sid294408@gateway/web/> has joined #yocto11:29
iceawayAfter trying to solve my wic issue, i read on the internet that in order to use the ${IMAGE_ROOTFS} variable in the kickstarter file, it may need to end in If I rename my file to, wic can no longer find it as an image type.11:30
iceawayi.e. with wic list images11:30
rburtonnrossi: i'd be tempted to say lets not do that *now* but after the rest is merged.11:32
nrossirburton: as in don't bring in the gdb/python-pexpect? and let the (its only 6 tests) fail11:35
JaMaRP: this fixes the issue with PRserv for me, hopefully doesn't break HashServe
*** berton <berton!~berton@> has joined #yocto11:39
*** berton <berton!~berton@> has quit IRC11:40
*** berton <berton!~berton@> has joined #yocto11:41
*** florian_kc is now known as florian11:42
RPJaMa: that doesn't surprise me but not sure its the right fix11:58
RPnrossi: maybe additional patches at this point?11:59
RPnrossi: I can always squash11:59
nrossiRP: ok, looks like the gcc/includes/* is not the only directory touched by stamping11:59
RPnrossi: I saw the cs-*.h, s-* and stmp-* files but only the include ones seemed to change12:00
*** mads_andreasen <mads_andreasen!sid294408@gateway/web/> has quit IRC12:01
nrossiRP: how can i tell what commit of oe-core the autobuilder is running against?12:01
RPnrossi: the build properties should show you, or look at the poky commit and it will show the oe-core hash12:02
JaMaRP: I'm not sure as well :/12:03
*** diego_r <diego_r!> has joined #yocto12:03
millonihi folks, i want to use selinux with a yocto build12:04
milloniit seems that yocto adds selinux labels on first boot12:04
milloniwhat do i do in a case where the filesystem is meant to be read-only?12:04
*** vmeson <vmeson!> has quit IRC12:07
qschulzkroon: ok, I'm building thud right now. so maybe this was fixed since then. ALSO, I've discovered this file://dir is actually a symlink to some other places (I hate it, but here it is atm). So maybe a corner case for symlinks...12:09
erboiceaway: did you change WKS_FILE to point to the file?12:18
erboiceaway: hmm, I guess it should be listed under "wic list images" anyway though12:20
iceawayerbo: is that required? I thougt the .wks-file was found by name in the wic create <wic_image_name> -e <bitbake_image_name>12:25
iceawayI don't quite understand under which circumstances the WKS_FILE is required. Is it so that a wic image will be generated automatically with bitbake <image>?12:26
erboI think so, if I have IMAGE_FSTYPES including "wic" for an image, and I do "bitbake that-image", then WKS_FILE need to point out the file to use.12:29
iceawayOKay, understood. Where would one put the WK_FILE? IN the distro/image .conf file?12:33
*** JaMa <JaMa!> has quit IRC12:35
*** vmeson <vmeson!~rmacleod@> has joined #yocto12:36
*** anujm <anujm!~anujm@> has joined #yocto12:37
nrossiRP: do these changes look fine?
nrossiRP: also, im not sure what is causing the current failures with gcc tests on the autobuilder. Unfortunately I have not been able to reproduce the issues with do_install modifying hardlinks. I suspect it is a case of more of those files being modified12:44
*** kroon_ <kroon_!~kroon@> has joined #yocto12:47
*** kaspter <kaspter!~Instantbi@> has quit IRC12:48
*** kroon <kroon!~kroon@> has quit IRC12:50
*** xtron <xtron!~xtron@> has joined #yocto12:53
nrossiRP: also i think i have a reasonable solution for the autobuilder config, qemu sys/usr execution.12:54
*** kroon <kroon!~kroon@> has joined #yocto12:55
nrossiRP: gcc sys is tagged as machine and release, glibc sys is tagged as machine  and qemu-slow. When running qemu* it is "selftest -t machine", when running qemux86-64 it is "selftest -t machine qemu-slow". When doing "release" testing it is always "selftest -t machine qemu-slow release". This means glibc tests are run with kvm, but otherwise not run unless release testing.12:56
*** kroon_ <kroon_!~kroon@> has quit IRC12:57
qschulzkroon: ok, could reproduce with a symlink but not with dirs. So you're right SRC_URI = "file://dir" and SRC_URI = "file://dir/" work for dirs but not symlinks (only the later then).13:03
*** feilz <feilz!> has quit IRC13:03
kroonqschulz, ahh.. was just about to test on thud13:03
erboiceaway: I guess WKS_FILE is usually set as part of machine configs13:04
qschulzkroon: now I'm interested by regex in SRC_URI, so going to test that :)13:05
iceawayerbo: Got it working. Apparantly using += on the IMAGE_FSTYPES variable did not work, I had  to use _append.13:05
qschulziceaway: bitbake -e and you can see who's setting IMAGE_FSTYPES and how13:06
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:06
qschulzI guess it was loosely set (?= or ??=)13:06
qschulzand when you use += you override those13:06
xtronhow to add dependent layers with bitbake-layers add-layer <layer>?13:06
kroonqschulz, symlink - that was sneaky.. should definitely be a bug reported, either bitbake should handle it as expected or at least warn about it IMO13:07
RPnrossi: yes, they look good13:07
RPnrossi: how do we make the autobuilder do that though :/ Its to complex for it to handle :(13:08
nrossiRP: you mean for the "selftest" template?13:09
yoctiNew news from stackoverflow: Difference between devshell environment and bitbake task environment? <> || Yocto change psplash image without rebuild the system <>13:10
RPnrossi: well, its currently in the arch-qemu template13:10
RPnrossi: obviously we can hardcode things into the autobuilder but we've managed to avoid much of that so far13:10
RPnrossi: it also needs to work with the older release branches13:10
RPnrossi: I also notice that resulttool is lumping sys and  usr test results together13:11
nrossiRP: yes that was something I was going to ask, prefix/suffix them?13:12
RPnrossi: probably suffix then they'll sort next to each other13:12
nrossiRP: with the selftest args, are you suggesting that selftest itself should handle what is default?13:13
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC13:13
RPnrossi: I don't know what I'm suggesting. I just don't see how this release/qemu-slow tagging is going to get us to where we need to be13:14
RPnrossi: right now the tests would be triggered every build which is too often so we need to fix that. There is then the question of where in a full build they'd hook in13:15
nrossiRP: ok, but changing the autobuilder templates is undesirable?13:16
iceawayqschulz: bitbake -e is a life-saver :)13:16
*** Proffalken__ <Proffalken__!> has quit IRC13:17
RPnrossi: no, we can change the templates13:17
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:18
nrossiRP: for the sys/usr suffix. Should it suffix both or just usr (aka, gcc-user)13:20
kroonqschulz, if you wanna play around, I think its bitbake/lib/bb/ that is the interesting one13:20
RPnrossi: just one, -user is probably fine13:21
kroonqschulz, see Bitbake commit 66dff37ebcd1dd14ebd6933d727df9cf0a64186613:22
*** anujm <anujm!~anujm@> has quit IRC13:22
*** ricardocrudo <ricardocrudo!> has joined #yocto13:24
*** iceaway <iceaway!~pelle@> has quit IRC13:25
ricardocrudoI'm trying to update qt to version 5.12 (currently using 5.11) on my yocto project, but I'm having some trouble trying to find out how to do that. I don't see any tag or branch on the meta-qt5 repo. Anyone here perhaps can give me a hint on that?13:26
qschulzricardocrudo: QT_MODULE_BRANCH in qt5-git?13:29
qschulzto be exact, QT_MODULE_BRANCH_PARAM but it is using QT_MODULE_BRANCH.13:32
qschulzbad news is that you'll have to have a bbappend for all qt recipes13:32
qschulzricardocrudo: also, can't you just take the meta layer at the commit hash where they had qt 5.12?13:33
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:34
qschulzkroon: wow, big pandora box opened now13:37
*** ricardocrudo <ricardocrudo!> has quit IRC13:37
qschulzSRC_URI = "file://bar/*.txt" in recipes-foo/foo/ and then you have recipes-foo/foo/foo/bar/bar.txt recipes-foo/foo/foo/baz/baz.txt13:38
qschulzin WORKDIR: tmp/work/aarch64-poky-linux/foo/bar AND baz13:38
*** sgw <sgw!sgw@nat/intel/x-scbjidavzahrvdgy> has joined #yocto13:38
kroonqschulz, well.. not terrible13:39
RPqschulz: some of that code is rather old :/13:39
kroonqschulz, it includes baz.txt in the checksum by mistake. so you get unncesseray rebuilds, right ?13:40
kroonqschulz, still rebuilds if bar.txt is modified13:40
qschulzkroon: nope, not in the list of watched files13:40
qschulzso 1. it seems there is no support for regexp (at least `*`) in SRC_URI13:41
qschulz2. why is it fetching baz as well?13:41
*** ricardocrudo <ricardocrudo!> has joined #yocto13:41
kroonqschulz, I thought you meant "bar AND baz" meant both was checksummed. So none of them are checksummed ?13:41
RPqschulz: it would be globbing, not regexp13:42
qschulzkroon: none of them are checksummed but both are fetched (visible in workdir)13:42
ricardocrudoThanks (about qt5), that should do it13:42
RPqschulz: do they show up in unpack? file:// urls are odd in that we don't actually need to fetch them13:43
*** zbooth <zbooth!cc4da337@> has joined #yocto13:44
* kroon heads home13:46
*** kroon <kroon!~kroon@> has quit IRC13:46
qschulzDEBUG: Searching for bar/*.txt in path: /media/qschulz/yocto/oe-dummy-project/recipes-foo/foo/foo/.13:54
qschulzNOTE: Unpacking /media/qschulz/yocto/oe-dummy-project/recipes-foo/foo/foo/. to /media/qschulz/build/tmp/work/aarch64-poky-linux/foo/1.0-r0/13:54
*** oz_rhett <oz_rhett!> has joined #yocto13:54
qschulz(from log.do_unpack)13:55
*** LocutusOfBorg <LocutusOfBorg!LocutusOfB@ubuntu/member/locutusofborg> has quit IRC13:55
qschulzRP: ^13:55
oz_rhettPerhaps a simple question, but how can I remove all the old task log files ? Over time they accumulate and take a lot of disk space.  Other than completely nuking my build directory tree, what other options are there ?  I just don't need multiple (old) copies of every,, etc. wasting valuable disk space13:56
RPqschulz: right, I just wondered if the unpack sig had the file checksums rather than fetch13:56
*** ricardocrudo <ricardocrudo!> has quit IRC13:57
qschulzRP: nothing in sig for do_unpack13:59
RPqschulz: fair enough, just wondered13:59
qschulzsure np14:00
qschulzoh no sorry, it's worse /o\ bar and baz dirs are in a bar directory in workdir, it looks like this: WORKDIR/bar/{bar,baz}/{bar.txt,baz.txt} instead of the expected WORKDIR/bar/bar.txt14:05
*** AndersD <AndersD!> has joined #yocto14:05
*** AndersD <AndersD!> has quit IRC14:10
RPqschulz: I think that is a legacy behaviour  :/14:10
RPqschulz: i.e. things rely on it14:11
qschulzRP: it does not look like it's from glob though, I quickly tested witha ptyhon3 interpreter and glob was working as expected14:13
qschulzRP: I'll try to ban the use of regular expression/glob in SRC_URI in our project then14:14
nrossiRP: going to send out these patches. Just checking again, I can respin them into the series if you would prefer?14:17
RPnrossi: it helps me just to stack them14:17
RPqschulz: It would help a lot to improve bitbake-selftest for this14:18
nrossiRP: ok, I will just send them as a stand alone series then :)14:19
RPnrossi: thanks14:19
*** likewise <likewise!~leon@> has quit IRC14:19
*** runde <runde!sid228344@gateway/web/> has quit IRC14:20
nrossiRP: oh btw, you should drop the python-pexpect patch when you apply these. As it is no longer required14:20
RPnrossi: right, makes sense, thanks14:20
*** runde <runde!sid228344@gateway/web/> has joined #yocto14:20
RPnrossi: realised binutils-cross-testsuite needs the nopackages fix to stop warnings too14:21
nrossiRP: want me to add that to this series for you?14:21
*** yacar_ <yacar_!~yacar@> has quit IRC14:22
RPnrossi: its ok thanks, I have it locally14:22
*** kroon <kroon!> has joined #yocto14:23
nrossiRP: np, series sent14:24
RPnrossi: added to -next, thanks!14:26
oz_rhettDoes anyone have much experience with building recipes that use the Go language ?14:29
oz_rhettThere doesn't seem to be a whole lot of documentation, just random web pages that I find using Google.14:29
RPahrg, autobuilder is locked up on some kind of fetch nfs lock :(14:31
nrossiRP: anyways i managed to produce the "timestamp" issue locally, forcing install task after a clean run produced it, so I will see if i can look into the gcc failures that weren't fixed after your link breaking change. However its past midnight so I am off shortly14:32
*** kroon <kroon!> has quit IRC14:32
RPnrossi: which gcc failures weren't fixed?14:33
*** kroon <kroon!> has joined #yocto14:33
nrossiRP: a number of gcc tests and gcc-runtime tests were failing on this run which should have your fix14:34
RPnrossi: ah, right. Maybe arch specific headers :/14:36
RPnrossi: I'd not spotted that yet :/14:36
*** frsc <frsc!> has quit IRC14:37
*** frsc <frsc!> has joined #yocto14:38
armpitzeddii, did you see the email about perf on older kernels?14:56
RPzeddii: With stap I got as far as seeing that runtime/linux/access_process_vm.h:#if defined(STAPCONF_LINUX_SCHED_HEADERS) is part of the problem15:00
RPzeddii: it seems STAPCONF_LINUX_SCHED_HEADERS should be defined but isn't. No idea why15:00
RPzeddii: I can change the error if I bypass that15:01
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:22
*** JaMa <JaMa!> has joined #yocto15:24
JPEWRP: Using the BASEHASH in place of the TASKHASH for hash equivalence seems like it would work... except that the BASEHASH doesn't seem to include files (e.g. SRC_URI?)15:28
RPJPEW: right, those are added in later. Not sure that matters though?15:33
RPJPEW: ah, I do see what you mean15:33
JPEWRP: Unless the actual value of SRC_URI is included in the basehash... in which case any change to it would cover the sources actually changing15:34
RPJPEW: a key use case is change a patch with whitespace/comment, rebuild and get the hash equiv15:35
RPJPEW: if the local file checksums aren't in basehash, that doesn't work15:35
JPEWRP: Correct. You wouldn't want different source to be detected as equivalent (at least with the default hash detection)15:36
RPJPEW: I don't think detecting different source as equivalent is a problem, that is inevitable15:36
JPEWRight, as long as the change to source doesn't affect the output?15:37
RPJPEW: exactly15:37
*** zbooth <zbooth!cc4da337@> has quit IRC15:37
*** oz_rhett <oz_rhett!> has quit IRC15:37
RPJPEW: I think we're going to have to change the code15:41
JPEWRP: For the basehash or something else?15:42
RPJPEW: Looking at the code, add in a "nodephash" which hashequiv would work off15:43
__angelohi sorry if i repeat the help request, but getting crazy. Manual, mailing list etc says that putting DEPENDS += "recipe_2" inside recipe_1 will trig recipe_1 to be processed. It doesn't work for me at all.15:43
RP__angelo: what does bitbake recipe_1 -e show?15:44
__angeloi am wondering if may be connected my recipe_1 is an initramfs recipe15:44
__angeloRP, thank, trying15:44
RP__angelo: yes, since images don't have do_configure steps which is where DEPENDS get added15:45
RP__angelo: try do_sometask[depends] += "recipe_2:do_someothertask"15:45
__angelobitbake recipe_1 -e   shows an infinite python code output15:46
RP__angelo: add | grep DEPENDS.*=, I doubt its infinite15:46
__angelook in bitbake recipe_1 -e   i see there is image_2 in the DEPENDS list15:56
__angeloi try now the do_sometask stuff15:57
__angeloRP,  super thanks. Finally i solved16:03
__angeloi used   do_rootfs[depends] = "my-initramfs-image:do_image"16:04
__angeloi think i tried before with "my-initramfs-image:do_rootfs" that was not working since probaly initramfs does not call that task16:05
*** kroon <kroon!> has quit IRC16:07
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:07
*** diego_r <diego_r!> has quit IRC16:10
*** frsc <frsc!> has quit IRC16:15
*** jmiehe <jmiehe!> has quit IRC16:16
*** ms_k <ms_k!> has left #yocto16:17
RPzeddii: some progress. When stap is testing its definitions its not finding headers like spaces.h on mips16:34
RPzeddii: It has  -I./arch/mips/include/asm/mach-generic missing from its search path16:34
RPzeddii: the rabbit hole beckons...16:35
zeddiihmm. I was just poking at how it generates defines, etc. but not much progress on it.16:35
zeddiidid we lose our cisco guy that actually knows stap ? :D16:35
zeddiiI could solve the problem with git rm :D16:35
RPzeddii: no, we should ask him16:35
RPzeddii: any luck with kprobes?16:36
zeddiiI've never had that dmesg show up.16:36
RPzeddii: I'm burning a ton of time on this which is going to cost hashequiv :/16:36
zeddiibuildrun.cxx is kind of nasty in systemtap. we should try and offload that, and I can look at krpobes to try and trigger it here.16:37
RPzeddii: "kind of"?16:37
zeddiiIIRC that's an arch where systemtap runs, and that triggers it.16:37
zeddii(the kprobes one)16:37
*** TobSnyder <TobSnyder!> has quit IRC16:37
RPzeddii: I ended up on the systemtap channel asking for help16:37
RPzeddii: systemtap on 32bit arm and mips is not tested16:38
RPzeddii: but they welcome patches when we fix it16:38
zeddiifor the 32 bit arches. I was going to suggest we just mark them incompatible.16:39
RPzeddii: don't tempt me16:39
zeddiiwhen the one 32 bit systemtap user crawls out of a hole, we can tell them the same thing. patches accepted :D16:39
*** mckoan is now known as mckoan|away16:40
*** armpit <armpit!~armpit@2601:202:4180:c33:7901:9fbe:6d35:e8ad> has quit IRC16:51
*** User_ <User_!~learningc@> has joined #yocto17:00
*** cferssy <cferssy!b36fd503@> has joined #yocto17:01
*** learningc <learningc!~learningc@> has quit IRC17:04
cferssyHello guys! I am beginner at yocto project and I would like to know how can I to put my apps and webpage at the linux image? I'm working with legato mangoh.17:04
*** cferssy <cferssy!b36fd503@> has left #yocto17:04
*** cferssy <cferssy!b36fd503@> has joined #yocto17:12
cferssyHello guys! I am beginner at yocto project and I would like to know how can I to put my apps and webpage at the linux image? I'm working with legato mangoh.17:12
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:20
*** learningc <learningc!~learningc@> has joined #yocto17:25
RPzeddii: _KBUILD_CFLAGS := $(call flags,KBUILD_CFLAGS) is what the stap Makefile does17:27
RPzeddii: KBUILD_CFLAGS has our flag, _KBUILD_CFLAGS is empty17:27
RPzeddii: is there an easy way to check if the flags filter was removed from the kernel or something?17:28
*** User_ <User_!~learningc@> has quit IRC17:28
zeddiisec. let me check on that.17:31
*** learningc <learningc!~learningc@> has quit IRC17:31
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:34
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has joined #yocto17:35
zeddiiRP: not currently seeing a difference between 5.0 and 5.2 in that area. looking more.17:42
RPzeddii: I can't even tell what its meant to do. Commenting it out and using raw KBUILD_CFLAGS does seem better17:43
zeddiiI thought it was just me that got lost in that routine. I read all the way to the bottom to see *how* that generated Makefile was used (I assume it is a generated makfile, given the “call” syntax).17:45
RPzeddii: Yes, there is a horrendous make command you end up with. I should write down my "stap debugging tips" and send you a copy17:47
*** nabokov <nabokov!~armand@> has quit IRC17:48
zeddiiI still haven’t found where the ‘call’ make macro is defined. kernel or stap.17:51
* zeddii tries a new strategy17:51
*** WillMiles <WillMiles!> has joined #yocto18:05
RPzeddii:  kernel commit cdd750bfb1f76fe9be8cfb53cbe77b2e811081ab18:34
*** kroon <kroon!> has joined #yocto18:35
RPzeddii:;a=commitdiff;h=7cfac6c0f8ba16c9a64c6799dd76ef61ef529f09 fix in systemtap to test18:38
zeddiiwell crap. I was limiting my git history foo to a different set of Makefiles. but I wonder why my #@$@#$ git grep "flags =" in the 5.0 kernel missed that.18:41
zeddiiI'm switching to qemuarm64 and the kprobes message then. IIRC it is showing on there.18:42
* zeddii finds that email18:42
zeddiiyup. will use arm6418:43
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto18:47
RPzeddii: My day is feeling like that :/18:52
*** armpit <armpit!> has joined #yocto18:54
fullstopqschulz: I found my problem, btw.  It was because of something I had in local.conf.. DEBUG_PREFIX_MAP=""18:55
fullstopI added it because setting that to "" avoids adding some compiler flags which gcc7 does not have.18:55
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto19:04
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC19:08
*** cferssy <cferssy!b36fd503@> has quit IRC19:09
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:08
RPzeddii: confirmed that systemtap master fixes qemumips stap20:12
*** dfrey <dfrey!~dfrey@> has quit IRC20:17
JPEWRP: so nodephash would be an intermediate hash between basehash and taskhash that includes the files?20:17
*** kroon <kroon!> has quit IRC20:17
RPJPEW: yes20:18
*** vmeson <vmeson!~rmacleod@> has quit IRC20:28
*** JaMa <JaMa!> has quit IRC20:57
rsalvetikhem: the update to 9.2 dropped the GLIBC_DYNAMIC_LINKER changes for risc-v again :-)21:02
rsalvetithird time now :-)21:02
kergothman am i looking forward to being able to move to master once hashequiv is polished off. waiting for a complete rebuild from scratch for no damn reason21:02
* kergoth taps foot21:02
*** vmeson <vmeson!> has joined #yocto21:07
JPEWkergoth: Want to beta test :)21:12
JPEWkergoth: It's not ready yet though21:12
kergothyeah, i know. been poking at it occasionally. even as is it's nice, just not ready to switch production over21:12
*** berton <berton!~berton@> has quit IRC21:14
*** Willy-- <Willy--!~william@> has joined #yocto21:18
*** warthog9 <warthog9!> has quit IRC21:20
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto21:21
*** warthog9 <warthog9!> has joined #yocto21:21
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC21:22
*** WillMiles <WillMiles!> has quit IRC21:26
*** warthog9 <warthog9!> has quit IRC21:29
RPzeddii: still one qemuarm stap issue left: - much simpler though21:30
*** warthog9 <warthog9!> has joined #yocto21:38
RPzeddii: FWIW a straight boot of the qemuarm64 kernel here shows the kprobes message in dmesg21:38
RPzeddii: don't need any of the tests to trigger it21:39
RPzeddii: a fix? ^^^21:40
zeddiiroot@qemuarm64:/tmp# dmesg |grep -i kpr21:44
zeddii[    2.892795] kprobes: failed to populate blacklist: -2221:44
zeddii[    2.893110] Please take care of using kprobes.21:44
zeddiiyah, was just looking at that.21:44
zeddiiI can easily test that commit to see if it does address it.21:45
zeddiiRP: that fix is queued for 5.2 -stable, which means it is likely the one and I've grabbed it from there.21:48
RPzeddii: cool. It reads like the right thing21:48
zeddiirebuilding and booting with it applied now.21:49
RPzeddii: so that leaves us stap broken on qemuarm21:49
RPand mips having highmen issues21:49
*** dv_ <dv_!> has quit IRC21:49
RPzeddii: 512 pushes mips into highmem range which is likely where the issues come from21:49
zeddiiah yes.21:50
zeddiiI'll start a 32 bit arm build once I get the kprobes fix built. and then mips on my 2nd builder.21:50
RPzeddii: cool. I think I need to take a break (32 bit arm building as there is a toolchain testsuite issues there too)21:51
zeddiiI'll get myself setup for those last two.21:51
*** rburton <rburton!> has quit IRC21:58
*** dv_ <dv_!> has joined #yocto22:04
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:05
*** agust <agust!> has quit IRC22:19
zeddiiRP: kprobes message is gone here. testing systemtap and will send a SRCREV update later.22:49
RPzeddii: sounds good, thanks!22:49
*** kroon <kroon!> has joined #yocto22:55
*** anujm <anujm!~anujm@> has joined #yocto22:56
*** CoRfr_ <CoRfr_!> has joined #yocto23:00
*** CoRfr_ is now known as CoRfr23:00
*** anujm <anujm!~anujm@> has quit IRC23:01
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:04
*** anujm <anujm!~anujm@> has joined #yocto23:05
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has quit IRC23:05
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto23:11
aehs29best advice on adding something back after it was in _remove?23:23
*** kroon <kroon!> has quit IRC23:50

Generated by 2.11.0 by Marius Gedminas - find it at!