Wednesday, 2020-09-16

*** vineela <vineela!~vtummala@> has quit IRC00:16
khemjonmason: on 2019 I had meta-zephyr working for a demo00:22
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC00:26
*** otavio <otavio!~otavio@> has joined #yocto00:28
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto00:28
*** kiwi_29 <kiwi_29!> has joined #yocto00:47
*** kiwi_29 <kiwi_29!> has quit IRC00:51
jonmasonkhem: was there any trick to it?  I cannot seem to get it to compile01:09
khemdont remember anything special01:36
khembut a lot of water has flown since so there might new errors what problems do you see01:36
khemI remember tweaking TCLIBC bits for baremetal a bit but I upstreamed those to oe-core01:36
jonmasonI tried monty and poky, but hit some m4 compilation error.  The tried the dunfell branch, found and fixed a pyelftools dep, then hit a "can't find the cross compiler" error01:48
*** sakoman <sakoman!> has quit IRC03:36
khemm4 error chimes a bell03:52
*** NiksDev <NiksDev!~NiksDev@> has quit IRC04:35
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto04:35
*** beneth <beneth!> has joined #yocto05:05
*** ssajal <ssajal!> has joined #yocto05:31
*** AndersD <AndersD!> has joined #yocto05:36
*** AndersD <AndersD!> has quit IRC05:51
*** agust <agust!> has joined #yocto05:55
*** rcoote <rcoote!> has joined #yocto05:57
*** goliath <goliath!> has joined #yocto06:00
*** manuel1985 <manuel1985!> has joined #yocto06:09
*** pohly <pohly!> has joined #yocto06:14
*** manuel1985 <manuel1985!> has quit IRC06:14
*** manuel1985 <manuel1985!> has joined #yocto06:15
*** sxiii <sxiii!> has quit IRC06:18
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC06:19
*** manuel1985 <manuel1985!> has quit IRC06:19
*** manuel1985 <manuel1985!> has joined #yocto06:20
*** manuel1985 <manuel1985!> has quit IRC06:21
*** manuel1985 <manuel1985!> has joined #yocto06:22
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC06:34
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto06:34
*** zandrey_ <zandrey_!> has joined #yocto06:40
*** zandrey <zandrey!> has quit IRC06:44
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto06:47
*** manuel1985 <manuel1985!> has joined #yocto06:51
*** beneth <beneth!> has left #yocto06:55
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:56
*** mckoan|away is now known as mckoan07:05
*** sagner <sagner!> has joined #yocto07:11
*** yann <yann!~yann@> has joined #yocto07:30
*** Moh3N <Moh3N!2ed17334@> has joined #yocto07:41
Moh3NHi , How I can use jenkins for automate building my yocto project ?? is there any good document or tutorial??07:43
*** chris_ber <chris_ber!~quassel@> has joined #yocto07:51
*** sxiii <sxiii!~sw@2a02:20c8:5640::2> has joined #yocto08:01
*** florian_kc is now known as florian08:02
*** Moh3N <Moh3N!2ed17334@> has quit IRC08:04
*** zandrey <zandrey!> has joined #yocto08:07
*** zandrey_ <zandrey_!> has quit IRC08:10
*** sno <sno!> has quit IRC08:10
*** sno <sno!> has joined #yocto08:13
*** xtron1 <xtron1!~xtron@> has joined #yocto08:25
*** awe001 <awe001!~awe00@unaffiliated/awe00> has joined #yocto08:26
*** xtron1 <xtron1!~xtron@> has quit IRC08:28
*** jmiehe <jmiehe!> has joined #yocto08:28
*** zandrey_ <zandrey_!> has joined #yocto08:43
*** zandrey <zandrey!> has quit IRC08:46
*** hpsy <hpsy!~hpsy@> has joined #yocto09:06
*** f0h <f0h!> has quit IRC10:18
*** jimr <jimr!~jimr@> has joined #yocto10:23
*** f0h <f0h!> has joined #yocto10:24
*** zandrey_ <zandrey_!> has quit IRC10:25
*** jimr <jimr!~jimr@> has quit IRC10:34
*** lxc <lxc!> has joined #yocto11:22
lxcStumbled into issue where bitbake git fetcher deadlocks. This happens when main main repo submodule itself. Looks like an issue with lock file design in DL/git2 folder.11:25
*** zandrey <zandrey!~zandrey@> has joined #yocto11:31
*** berton <berton!~berton@> has joined #yocto11:39
RPlxc: I can see how that would happen :(11:40
lxcAs an example, consider the following google repository,, the doc folder in that repository is a submodule to the repo it self. Running the bitbake git fetcher on this repo causes it to deadlock due to it lock file construction.11:43
RPlxc: you have to question whether repository design like that makes sense :/11:44
lxcSelf-referencing submodule:
RPlxc: I'm not sure what we can do here at the bitbake level either :/11:44
lxcAgree, I have not seen that submodule pattern before. But since it exists and dead-locking is bad...11:45
RPlxc: we can probably detect it and just error out?11:46
lxcWell, that is better but does not make it work. The command line git does not have any issues with this design.11:47
*** sagner <sagner!> has quit IRC11:47
RPlxc: well, sure, but is adding all the complexity to handle this (with things like mirroring) really worth the maintenance load for this corner case?11:48
*** sagner <sagner!> has joined #yocto11:50
lxcMinimum is at least to error out and avoid dead lock. Can't judge if the increased complexity is worth it.12:04
*** leonardo38 <leonardo38!52c11cb8@> has joined #yocto12:05
RPlxc: It probably needs a bug opening for it12:18
RPlxc: do you fancy fixing it? :)12:19
lxcWell new to the yocto scene so not sure how to submit one... thru the mailing list or on git or how?12:20
RPlxc: it would be through a patch sent to the bitbake-devel mailing list12:21
lxchaha, I was not planning to fix it, don't have one. I just observed the bug.12:21
RPbonus marks for adding tests to lib/bb/tests/fetch.py12:21
RPlxc: ah, for bugs, file at https://bugzilla.yoctoproject.org12:22
lxcBug 1404512:29
*** vineela <vineela!~vtummala@> has joined #yocto12:32
RPlxc: thanks. Not sure if/when we'll get to it but its worth tracking as we shouldn't deadlock12:33
lxcis there a tutorial for how to build an lxc with the core-image?12:41
*** leonardo38 <leonardo38!52c11cb8@> has quit IRC12:47
*** Konsgnx <Konsgnx!> has joined #yocto12:50
*** AndersD <AndersD!> has joined #yocto12:58
*** maudat <maudat!> has joined #yocto13:00
RPJaMa: does that patchset address the issues the autobuilder ran into last time?13:00
RPJaMa: this is for 3.2?13:00
*** AndersD_ <AndersD_!> has joined #yocto13:00
*** vineela <vineela!~vtummala@> has quit IRC13:02
*** AndersD <AndersD!> has quit IRC13:02
*** vineela <vineela!~vtummala@> has joined #yocto13:06
fullstopSo I rebuilt the world last night, and now 70% of the sstate targets match on the other machine.13:11
fullstopI have also seen where NATIVELSBSTRING seems to change between universal and ubuntu-16.04 seemingly at random.13:11
fullstopThe PC with 70% match does not appear to grab the uninative binaries?13:13
RPfullstop: once the uninative is in DL_DIR, you probably wouldn't see it fetch again13:18
RPfullstop: are the sigs difference in the two different builds?13:18
fullstopfirst run of bitbake: NATIVELSBSTRING      = "ubuntu-16.04"13:18
fullstopsecond run of bitbake: NATIVELSBSTRING      = "universal"13:19
RPfullstop: I think there is a UI glitch where the first run doesn't display that correctly :/13:19
fullstopall I did was bitbake -n recipename13:19
fullstopso I'm chasing a ghost13:19
RPfullstop: I suspect so :(13:19
RPits possible its having wider effects but I just don't know13:20
RPI have noticed it but never figured out what is going on :(13:20
*** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:8cbe:5797:375a:2468> has quit IRC13:20
*** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:99e9:1c8a:8ebf:fa95> has joined #yocto13:20
RPThat should probably have an open bug13:20
fullstopIs that string used at all in deriving the signatures?13:22
fullstopRP: the second machine is running inside of a container, so I can blow it all away and start from scratch.  It's really not downloading the uninative binaries and elects to build gcc.13:25
RPfullstop: that string is used but I think by that time its been expanded (its after its shown on the UI)13:27
RPfullstop: it should need to get uninative from somewhere...13:28
fullstopbefore or after it downloads all of the stuff from sstate-cache?13:28
fullstopI stopped bitbake once it started downloading gcc/binutils/and friends.13:28
RPfullstop: it should be expanded before it accesses sstate13:30
RPCheck the logs and see which sstate urls its looking for?13:30
JaMaRP: I've split the problematic parts from this and the oe-selftest results are the same with this patchset and current master (oe-selftest - FAIL - Required tests failed (successes=408, skipped=3, failures=3, errors=1)) so I hope I've caugth all issues from last time13:31
fullstopRP: sstate-cache/c1/a4/sstate:libtool-cross:cortexa5t2hf-neon-vfpv4-poky-linux-gnueabi:2.4.6:r0:cortexa5t2hf-neon-vfpv4:...13:31
fullstopIt really looks like it's wanting to build a cross compiler.13:32
JaMaRP: I don't mind if it slips to 3.3 if you're concerned about this for 3.213:33
RPJaMa: I'll run it through testing and see what happens. If there are issues we'll defer13:35
JaMaRP: perfect, thanks13:35
RPfullstop: can you find something native which would have the NATIVELSBSTRING in though13:36
JaMabtw: when migrating one of my LuneOS builds from zeus to dunfell I've noticed interesting side-effect of using OEHashEquiv without public HashServe13:36
RPfullstop: the question for libtool-cross is does the hash match between the two builds?13:36
JaMaI had up2date sstate-cache in one workspace, moved it to the other one (without migrating hashserve.db) and the other one wasn't able to reuse much from sstate-cache (was building e.g. libtool-cross already), correct me if I'm wrong, but is it probably because the libtool-cross in sstate-cache had the signature which was equivalent with the current one from oe-core recipe, but because I didn't use the same13:38
JaMaHashServe my other build wasn't able to use it?13:38
RPJaMa: right, that is what would happen13:39
JaMaOK, so all the build time savings from OEHashEquiv on one builder will be spent on another builder unless they all share HashServe as well13:40
RPJaMa: yes13:40
RPwe have no way to export the equivalence into sstate at present13:41
RPfullstop: I wonder if your issue is related. Are you using a local hashequiv server?13:41
fullstopRP: I am not, and every signature that I look at seems different between the two machines.13:42
*** psnsilva_ <psnsilva_!> has joined #yocto13:42
RPfullstop: ok, pick something early in the build. You need to find the first ones which differ13:42
*** ericch <ericch!> has joined #yocto13:43
RPfullstop: you may also get clues if you bitbake-diffsigs A B between two of them13:43
fullstopgcc-runtime okay?13:43
*** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:99e9:1c8a:8ebf:fa95> has quit IRC13:43
RPfullstop: its a good one, yes13:43
JaMado you have some statistics from AB about HashEquiv? or load/bandwidth on ?13:43
lxcanyway to get more logs from do_unpack? Having a stalled one I want to see why that is.13:44
RPJaMa: no. Can barely keep it running, let alone look at stats :(13:44
fullstopdo_deploy_source_date_epoch and do_fetch are identical13:44
fullstopbut do_compile and do_configure do not match13:44
JaMaRP: ok, understood :/13:44
RPlxc: looked at WORKDIR/temp/log.do_unpack for that recipe?13:44
RPfullstop: ok, have a look at configure since its earlier13:45
RPeither it will have differences or it will point at dependencies that differ13:45
*** psnsilva__ <psnsilva__!~psnsilva@2001:818:dae7:b100:99e9:1c8a:8ebf:fa95> has joined #yocto13:45
fullstopRP: I'm not quite sure how to do that13:46
JaMaI'm wondering if HashServe has similar limitation like PrService, that it would be useful to have some "official" builders RW access and then local developer builds just RO, so that they can find equivalent sstate from official sstate-cache shared from official builders, but without adding their own local hashes from their local tests13:47
*** psnsilva_ <psnsilva_!> has quit IRC13:47
frayJaMa, I just want to ship a DB with an sstate-cache.. so that the local builders DBs can match a RO sstate-cache..13:48
JaMaanyway I've already disables sstate-cache sharing from LuneOS builds, because we have enough network glithes on the server to make SSTATE_MIRROR more pain than gain13:48
frayproblem is when a builders output gets added to the sstate-cache, how do you sync it..13:48
RPJaMa: A RO hash equiv would be really useful, there is an open bug for it13:50
JaMayes, it's the same issue as in with PR servise13:50
JaMaideally there should be RO master and RW local slave (or how we're supposed to call them now), that the local PR or Hash service would check the local db first, then query the "official" RO master and if it doesn't find answer there as well, create new local entry, but I understand that this is a lot of work and would complicate things significantly13:53
*** sakoman <sakoman!> has joined #yocto13:53
JPEWJaMa: Ya, that's how you want to implement it. That way, bitbake doesn't really have to be aware of "RO" servers; it's all on the server side to fetch from an upstream server13:54
JPEWThe hard part is that we do a lot of work to make the initial hash fetch fast, and I haven't figured out a way to make that fast when you have to go query an upstream server for it13:55
JaMauntil someone suggests more than 2 levels of hierarchy :)13:55
JPEWJaMa: Ya, I don't think multiple levels is really that different once you get the first level working13:56
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC13:57
JaMaimagine HashEquiv Root servers running next to DNS Root servers hashing all the pr0n from internet to de-duplicate it..13:57
qschulzndec: RP: what's the deadline for the sphinx doc review/fixes?13:58
ndeclast month :)13:58
frayI always considered PR service like a DNS.. your local is RW, everything upstream of you is RO.. upstream of you would be for each sstaet-cache.. hashequiv likely is no different.. one per mirror13:58
JaMathat's plenty of time :)13:58
fraythe catch is for performance, if you load at startup, then you miss anything updated while you run.. if you query each time it's slow..13:59
JPEWJaMa: The server doesn't do any hashing. It's actually probably a lot simpler that you might be imagining :)13:59
ndecqschulz: we are about to merge the sphinx branch into master , in bitbake. which means we believe we are 'done' with the migration. granted that there can be a few bugs here or there..13:59
qschulzndec: yeah anyway it would be just cosmetic/small fixes if I find the time to go through it14:00
ndecqschulz: for yocto-docs, we will merge sphinx, as soon as we get an update from timo for the toaster manual (I sent a review earlier today)14:00
*** sxiii <sxiii!~sw@2a02:20c8:5640::2> has quit IRC14:00
JPEWfray: Right. If anyone has a bright idea for how to deal with that first flood of queries quickly when there is an upstream RO, the actual changes to add an upstream server are pretty simple14:00
RPqschulz: there are still many fixes to be found, we'll be taking those as they come in14:00
ndecqschulz: right. the most important was to merge into master and 'switch' officially. we will surely take additional fixes..14:00
qschulzndec: RP: that's all I wanted to know. No need to hurry but still worth spending some time here and there. Thx! Happy to see it coming together :)14:02
RPqschulz: help would be much appreciated as the docs work is just burning me out :(14:02
qschulzRP: yeah it's tedious.. if you consent, sending virtual corona-free hugs14:07
JaMaJPEW: my understanding is that OEOuthashBasic does the hashing and HashServe just manages groups of equivalent hashes14:07
RPqschulz: thanks :)14:08
RPqschulz: I know the note sections are missing markup and links if you're looking for patterns of issues to fix14:08
*** tlwoerner_ <tlwoerner_!~trevor@> has joined #yocto14:08
RPand I think links in general need a lot of sanity checking14:08
*** tlwoerner_ <tlwoerner_!~trevor@> has left #yocto14:09
qschulzRP: could there be some monkey testing with selenium or something like to check for dead links? (probably not worth the effort now but as some regular checks in the long term?)14:10
qschulzRP: thx for the suggestions14:10
RPqschulz: yes, I was thinking of finding some tool to check the links14:10
fullstopRP: I may have found something..  sqlite3-native:do_deploy_source_date_epoch is different between the two.14:11
RPfullstop: that would be significant14:13
fullstopWhat exactly does that represent?14:13
RPfullstop: its the date stamp used for build reproducibility14:13
RPnext, to figure out why its differing14:14
fullstopI'm almost following you.. but the date stamp of what?14:14
*** psnsilva__ <psnsilva__!~psnsilva@2001:818:dae7:b100:99e9:1c8a:8ebf:fa95> has quit IRC14:14
*** psnsilva__ <psnsilva__!> has joined #yocto14:15
JPEWJaMa: Correct. Really, it just records them in the table and the "grouping" is done by a SQL query14:15
RPfullstop: it depends on how its being fetched. from git, or the tarball14:15
fullstopRP: one step back.. why not fetched from sstate?14:16
fullstopthe recipe gets it from${SQLITE_PV}.tar.gz14:16
RPfullstop: if the hashes for the tasks are different, it will see that as an sstate miss14:17
RPthe question is therefore why the task hashes are different14:17
fullstopfetch, patch, deploy source, configure?  is that the order?14:19
*** vineela <vineela!~vtummala@> has quit IRC14:19
RPfullstop: think so14:21
fullstopon the primary host: DEBUG: Reported task 2d1b02d40dd24af10f44538fac59e2b560c19d79bd806b344f40f51aeb4bceb7 as unihash f769ef0fea2cb342629b4d822bdeac77bb8ecadfa99442af8914c5b2db3fb8cc to unix:///home/prox/yocto/poky/build/hashserve.sock14:21
fullstopI don't see anything logged on the other machine regarding hashes, but maybe I can dump that somehow14:22
RPfullstop: ok, you *do* have hashequiv enabled14:22
RPfullstop: this is the issue JaMa was talking about I think14:23
fullstop#BB_HASHSERVE = "auto"14:23
fullstopIt's not explicitly enabled, unless it is enabled by default14:23
RPfullstop: we enabled it by default in dunfell14:23
fullstopOkay, so that's why this behavior is new14:23
JaMaIMHO only in poky, not in default setup (not sure what fullstop is using)14:23
JaMameta/conf/bitbake.conf:BB_SIGNATURE_HANDLER ?= "OEBasicHash"14:24
JaMaeven in master14:24
*** rpcme <rpcme!> has joined #yocto14:25
fullstopI am using poky14:26
ndecRP: qschulz : i ran sphinx linkcheck on bitbake tree, and got the following error:14:27
ndeci am running it on yocto-docs now.14:27
ndechmm. with the full output it's better:14:28
qschulzndec: cool!14:29
RPndec: what about the #XXX references in links though?14:29
RPndec: that doesn't look too bad to fix up at least14:29
ndecRP: what do you mean with #XXX14:30
qschulzndec: I'd assume the alternative to #FIXME?14:30
qschulzbut I might be completely off :)14:30
rpcmeHello all - I have an AGL related question, hopefully someone here can help with this.  I am getting this error from 'useradd' - works fine on pure Yocto.
fullstopWhat are advisable options here?  Go back to the BB_SIGNATURE_HANDLER used in 2.7.x?14:31
RPndec: I'm blanking on the name for them14:31
ndecyou mean the 'custom' labels as opposed to autosection labels?14:31
JaMafullstop: sharing the same BB_HASHSERVER between all your builders if possible14:32
fullstopI'll have to read up on that and figure out how that works.14:33
fullstopWhat do I need to run on the host?14:33
qschulzRP: anchors?14:33
RPndec: html anchors. I'm fairly sure we have a lot of them which are broken14:33
fullstopBB_HASHSERVER has exactly one hit in google.  Ha!14:33
RPqschulz: yes, just got there myself :)14:33
ndecRP: is angstrom website down permanently? it's referenced in the bitbake manual. perhaps we could use another example instead, like AGL?14:33
RPndec: we should switch, yes14:34
ndecRP: linkcheck found "(line 1958) broken - Anchor 're' not found"14:34
RPndec: also noticed references to gcc-cross-initial and so on14:34
JaMafullstop: bitbake-hashserv14:34
ndecso looks like it finds problems with anchors.14:34
*** emrius <emrius!> has joined #yocto14:34
RPndec: does it check the internal links?14:34
ndecit's a bit slow to run.. but it's running on yocto-docs. i will share the output14:34
emriushey everyone, I'd like to add tmate ( to my image. Does somebody have a recipe at hand already? :)14:35
RPfullstop: try BBHASHSERVE ?14:35
ndecRP: qschulz : here is the output..14:36
qschulzemrius: apparently not in layers defined there. You can use devtool add <git-url> to start one for the boilerplate14:36
emriusJaMa thanks, I did check oe layers but didn't find anything there14:36
emriusqschulz thanks! will do!14:37
ndecit does not check internal links.. so we need to run a link checker on the website site once it's published.14:37
*** rpcme <rpcme!> has quit IRC14:37
fullstopRP: okay, so I need to start this process on the primary build server and configure that machine to use it, followed by pointing other machines to that same host / port?14:37
RPfullstop: yes, they all need to point at the same server14:38
qschulzndec: or host it with python -m http.server?14:39
ndecyes, sure.14:39
ndeci meant on the output html.14:39
fullstopRP: and "auto" automatically runs bitbake-hashserv temporarily while bitbake is running?14:39
*** carlsb3rg <carlsb3rg!c147afcf@> has quit IRC14:39
qschulzndec: gotcha14:39
RPndec: I suspect the results will scare us. That link doesn't look too bad to work through14:39
RPfullstop: yes14:39
ndecRP: and btw, these errors probably exist *today* in the current docs.. they were not added by sphinx migration..14:40
RPndec: hmm, given the problems I've see, yes and no14:40
RPsome yes, we'll have added new ones14:40
*** emrius <emrius!> has quit IRC14:43
*** j241 <j241!> has joined #yocto14:44
ndecRP: "(line  158) broken - 404 Client Error: Not Found for url:" this one is yours ;)14:44
ndecin ref-manual/resources.rst14:44
RPndec: ah.14:46
*** luneff <luneff!~yury@> has joined #yocto14:47
*** kaspter <kaspter!~Instantbi@> has quit IRC14:47
RPndec: fix pushed14:48
fullstopRP: a full rebuild is required to populate the hashdb, yes?14:52
RPfullstop: effectively14:52
fullstopokay, I will run that tonight.  I set up a systemd service to run bitbake-hashserv.14:53
*** luneff <luneff!~yury@> has quit IRC14:54
*** sr71919 <sr71919!uid463993@gateway/web/> has quit IRC15:00
*** vineela <vineela!~vtummala@> has joined #yocto15:01
*** tolszak <tolszak!> has joined #yocto15:06
*** AndersD_ <AndersD_!> has quit IRC15:08
*** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has joined #yocto15:11
*** j241 <j241!> has quit IRC15:12
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto15:13
*** w00die <w00die!~w00die@> has quit IRC15:29
*** w00die <w00die!~w00die@> has joined #yocto15:31
ndecRP: the patch "[docs][sphinx][PATCH] sphinx: dev-manual: Clarify that virtual providers do not apply to runtime dependencies" which is on the list, just applies.. and looks good to me. i pushed it to sphinx branch.15:34
RPndec: ah, cool15:34
ndeci think this is our first sphinx patch ;)15:34
ndecwhere we diverge from docbook..15:34
RPndec: I suspect I did that with populate_sdk_ext but still cool15:35
*** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has quit IRC15:37
*** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has joined #yocto15:37
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:38
*** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has joined #yocto15:40
kergothHmm, should make a list of variables to eventually rename and deprecate to improve clarity and consistency. TOOLCHAIN_*_TASK for one.15:44
RPkergoth: there are quite a few :/15:44
kergothyep. wouldn't be fun, but could help new users a bit in the long term15:45
frayvariable renaming (I'm all for it) would be a reason to move to '4.0'..15:45
kergothnot a bad idea15:45
kergothwould be nice to try to add consistency in our word ordering in variable names if we can while we're at it15:45
kergothsometimes it's object-verb and sometimes vice versa, and related15:46
fray...and make sure all of the variables are properly documented...15:46
kergothi.e. sometimes we use the earlier words as a namespace, but not always15:46
RPkergoth: I was thinking about "TMPDIR" and "WORKDIR/temp" the other day15:49
kergothUgh, yes, i've wnated to do something about that for like 10 years now15:49
kergothgod, i feel old now15:49
RPobviously need to change it to TMP/TMPVER/TEMPNAME/WORKTEMP/LOGTMP :)15:50
kergothspeaking of weird variable names, the portage legacy is worth thinking about renaming. 'D' 'S' 'T'..15:50
RPkergoth: 10 years of Yocto, let alone OE. We are getting old...15:51
RPkergoth: I quite like D and S15:51
fraylol, I've been doing Linux (professionally) since 1998 or so.. an embedded Linux since 200015:52
kergothit has a certain simplicity for sure, but it's also not particularly consistent with the variables we use everywhere else. don't feel too strongly about it, but worth a review15:52
frayI don't mind the D and S..15:52
frayone of those, you just need to 'learn' things.. and I'm OK with that since it also maps to debian and there are analogs in the RPM world as well15:52
*** verrueckerhund <verrueckerhund!> has joined #yocto15:53
RPkergoth: its worth thinking about. T is nearly transparent to users and probably should be changed. There are other things I dislike much more than D/S15:53
fray(I never did figure out why they used 'D' (DEST) and not 'I' (install)) but anyway15:53
kergothwould be best to focus on the actively misleading first, and go to unclear and/or confusing later :)15:54
kergothwith all of our copious spare time..15:54
kergothIt'd be nice to try to entice more juniors to come on board and assist with that sort of janitorial-type task, but it's tough, even folks new to yocto are usually on the job trying to accomplish a specific task, not just playing around anymore :)15:55
RPkergoth: right. Also, the work in migration for a variable change is very non-trivial15:56
kergothTrue, we'd need to add fray's variable usage warning stuff and a clear path and example to follow15:57
RPkergoth: I'm quite sad at how much work the docs transition is and how few people have any time to help (but I know why)15:57
RPkergoth: its the docs implications which worry me, in some ways more than the code15:59
*** crazoes[m] <crazoes[m]!crazoesmat@gateway/shell/> has quit IRC16:00
*** pohly <pohly!> has quit IRC16:07
*** verrueckerhund <verrueckerhund!> has quit IRC16:08
*** mckoan is now known as mckoan|away16:09
*** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto16:11
*** awe001 <awe001!~awe00@unaffiliated/awe00> has quit IRC16:13
*** jmiehe <jmiehe!> has quit IRC16:17
JaMatalking about naming, is anyone really fond of using .rootfs inside out image filenames? And if yes, do you think -testdata.json and -qemuboot.conf files should include it as well or not?16:19
RPJaMa: it does actually say what it is but I know what you mean :/16:20
*** sagner <sagner!> has quit IRC16:22
JaMa"what it is" is true only as long as you're building just one rootfs image, once you build different images for different partitions and then combine them into some other format e.g. with wic, then calling them all rootfs isn't right16:22
JaMaor when initramfs image has .rootfs as well16:23
RPJaMa: right, those make much less sense16:25
RPJaMa: its a very old holdover to when these were rootfs16:25
JaMain this I have added them also to .iso, .hddimg, qemuboot, testdata, but then dropped this from patchset, because it doesn't feel right16:26
RPJaMa: you're right, we should probably get rid of it entirely16:27
JaMaat least it should be easier to just set IMAGE_NAME_SUFFIX to empty now when it will be separate variable16:27
RPJaMa: yes, true16:30
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC16:33
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has joined #yocto16:34
*** rcoote <rcoote!> has quit IRC16:36
*** vineela <vineela!~vtummala@> has quit IRC16:44
*** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC16:46
*** zandrey <zandrey!~zandrey@> has quit IRC16:53
*** chris_ber <chris_ber!~quassel@> has quit IRC16:55
JaMawhat is used to provide nodejs-native when AB is executing devtool.DevtoolAddTests.test_devtool_add_npm and recipetool.RecipetoolTests.test_recipetool_create_npm tests?17:03
RPJaMa: we configure it to skip those17:03
RPJaMa: I do want to revisit that17:04
JaMaaha, in the old logs from AB I've seen just 2 different tests being skipped in "oe-selftest --skip-tests distrodata.Distrodata.test_checkpkg buildoptions.SourceMirroring.test_yocto_source_mirror -T machine -T toolchain-user -T toolchain-system" maybe it was before nodejs tests were added17:05
JaMawill check on some newer build report17:05
RPJaMa: it runs different commands depending on the version its building17:06
JaMathanks will install mesa headers and add these 2 to skip and might get green build with poky master :)17:08
RPJaMa: :) I don't like using the skips but it was better to have the tests than not17:08
*** vineela <vineela!vtummala@nat/intel/x-rqwvozltvytiggry> has joined #yocto17:18
*** lxc <lxc!> has quit IRC17:19
* RP merges bitbake sphinx changes17:21
RPjonmason, rburton: any progress on the meta-arm warning?17:35
rburton<cough> what one17:36
* rburton looks17:36
rburtoni think its the one i've already moved to major severity17:36
rburtoni'll escalate17:37
kergoth in case anyone else missed this from a few days ago17:38
* kergoth yawns17:39
RPrburton: thanks17:45
*** fatalhalt <fatalhalt!> has joined #yocto18:06
khemkergoth: yeah consolidation in silicon industry is on, like it was case in automobiles in later part of 20th century18:13
*** Klanticus <Klanticus!> has joined #yocto18:29
kanavin_homehalstead: so is there a smtp server that is operational?18:51
*** lxc <lxc!> has joined #yocto19:02
lxcTryig to add DEPENDS for libasan via gcc-sanitizers, but get an error message. What is required to get libasan in sysroot?19:02
RPlxc: is it being built in gcc-sanitizers?19:07
khemyou would need a dep on libasan-dev19:08
RPkhem: build time, not runtime?19:10
RPhalstead: did you have to restart janitors on f32 as well?19:10
khemfor runtime libasan in rdeps or perhaps app linling to it can pull it19:10
lxcgcc-sanitizers was skipped: incompatible with host i686-poky-linux-musl (not in COMPATIBLE_HOST)19:11
lxcOk, so glibc required, not working then with musl19:11
halsteadkanavin_home, really should be. That's how the mail gets off of the worker. Try instead. Perhaps there is an issue with the split horizon dns.19:13
RPJPEW: more syncthread issues and we know the autobuilder has a deletion backlog so there is io load :(19:14
RPkhem: I think they're asking for the build time DEPENDS though19:15
* RP wishes he knew what to do about SyncThread, other than remove it19:15
khemwhen in doubt always go for removal19:16
kanavin_homehalstead: on ubuntu1804-ty-3, does not respond, but does19:16
kanavin_homehalstead: it would be better to not hardcode the ip address though19:17
kanavin_homeakanavin@ubuntu1804-ty-3:~/auto-upgrade-helper$ nslookup mail.yoctoproject.org19:17
kanavin_homeNon-authoritative answer:19:17
kanavin_homeName:   mail.yoctoproject.org19:17
khemRP: ideas on the MACHINE = SDKMACHINE patch ?19:19
JPEWRP, khem: I suspect removing the threads will just move the timeout19:20
*** master007 <master007!~master007@> has joined #yocto19:20
RPkhem: I want to look at what is going on there19:21
*** nslu2-log <nslu2-log!> has joined #yocto19:21
RPJPEW: I suspect so too which is why I've not done it19:21
RPkhem: should gcc-runtime ptesting chew disk io heavily?19:21
RPkhem: we need to find where the machine contamination is coming from and why the selftests don't spot it19:24
khemRP: I think logically the patch is right, since for nativesdk we should have MACHINE var dep but I think it will be good to find the reason why, but I guess its flowing via OVERRIDES19:25
RPkhem: why should we have a vardep?19:26
RPDoes anyone know how ionice interacts with the extX disk journal?19:26
khemRP:its in overrides for nativesdk19:27
khemand I guess overrides value changes when MACHINE is changed19:27
khemso perhaps MACHINE=a bitbake nativesdk-<recipe> MACHINE=b bitbake nativesdk-<recipe> might reproduce it19:28
RPhmm, seems to echo my worries19:30
*** khem <khem!~khem@unaffiliated/khem> has quit IRC19:32
zeddiihas anyone ever seen this out of bitbake:19:33
zeddiiNOTE: Executing Tasks19:33
zeddii[Errno 11] write could not complete without blocking19:33
*** pohly <pohly!> has joined #yocto19:34
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto19:35
RPzeddii: interesting. no.19:36
zeddiiaaaand now it cleared. was only giving me that for about 10 minutes.19:37
RPJPEW: I'm guessing that the writes to the disk all end up in the journal thread for the disk and lose their io priority and gain the io priority of the jbd process :/19:37
zeddiithe only hit I got on the error message was from some logging discussions.19:38
zeddiiah, its back. whee.19:38
RPzeddii: what is it building?19:38
RPsounds like the pipes to the workers/cooker are being overloaded with log data19:39
*** vineela <vineela!vtummala@nat/intel/x-rqwvozltvytiggry> has quit IRC19:39
RPhmm, we do that often enoug19:39
zeddiiit's on a builder that I've been using all day. trying to get a core image that can boot and runtime test Xen.19:39
zeddiiand now, that.19:39
zeddiivery odd.19:40
RPzeddii: its odd its not even up to the building part19:40
zeddiilots of disk, fully idle machine.19:40
zeddiiI know! and it just popped in out of nowhere.19:40
zeddiibut that's how my day has been.19:40
zeddiihah. failed once more. ran it again. and it worked. something is definitely contending on this box. I'll see what I can figure out.19:41
zeddiiit is a multiconfig build, but otherwise, pretty simple.19:42
RPhalstead: Could we try switching the /home partition to writeback journal only?19:53
halsteadRP yes. I do that for distros that have it as an install option. I'll set it up for all the workers.19:55
RPhalstead: Ah! this may explain why we're seeing the problem particularly on the fedora workers19:57
RPhalstead: if we could switch those over that'd be great, it might well avoid the problems we're seeing19:58
halsteadI think the SUSE installer has the option. I'll get the other ones.19:58
RPhalstead: thanks, this could explain a few things20:01
*** zandrey <zandrey!> has joined #yocto20:16
RPsgw: swapped out openssh for dropbear in my qemumips sato-sdk image and serial login takes 20s instead of 45s. Why is serial login depending on ssh daemon?20:17
*** yann <yann!~yann@> has quit IRC20:29
paulgstrace is your friend?20:35
paulgsome kind of network lookup it would seem.20:36
frayRP is it a dependency on "login", moved from one version to another?20:36
fullstopRP: I kicked off a new full build on the primary server and waited until after it had finished sqlite3-native, and then built that target on the other machine.  It pulled everything from the sstate-cache, so using bitbake-hashserv is working as expected.20:38
paulgI dunno if this is related, but back in the day, I changed the hostname (well, really net-cat'd the same image to another turd) and changed /etc/hostname but didn't change /etc/hosts for 127.x entries20:39
paulgnoted that serial logins took longer  -  never went past tracking it down to /etc/hosts entries for 127.x20:39
paulgsounds rather similar.20:40
paulgor, completely unrelated!20:40
RPpaulg: I'm just trying to think of how you strace the first boot serial login :)20:41
RPfullstop: that is good news :)20:42
RPpaulg: that does sound kind of similar...20:42
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has quit IRC20:47
*** lxc <lxc!> has quit IRC20:49
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has joined #yocto20:57
*** Konsgnx <Konsgnx!> has quit IRC21:00
*** pohly <pohly!> has quit IRC21:03
*** nslu2-log_ <nslu2-log_!> has joined #yocto21:07
*** nslu2-log <nslu2-log!> has quit IRC21:08
*** nslu2-log_ is now known as nslu2-log21:09
*** sxiii <sxiii!> has joined #yocto21:09
*** berton <berton!~berton@> has quit IRC21:17
*** maudat <maudat!> has quit IRC21:23
RPpaulg: hostname and hosts appear to match and have the right mappings but it could well be something silly like that21:47
*** psnsilva_ <psnsilva_!~psnsilva@2001:818:dae7:b100:31e0:7192:2b55:e4ad> has joined #yocto21:48
paulgRP, yeah - it was a long time ago and I wish I could help with more context, but brain-flush has claimed any further details.21:50
*** psnsilva__ <psnsilva__!> has quit IRC21:50
paulglike a lot of things in life, I just recall getting savaged by it.21:50
zandreyRP: can it be because the rand entropy is not gathered quick enough? I saw some delays in starts because of this21:51
zandreydo you have haveged package installed?21:52
RPzandrey: virtio rng passthrough is there and enabled21:56
*** creich <creich!> has quit IRC21:56
RPquestion is how/why would a serial getty depend on the ssh daemon21:56
zandreyRP: okay.21:56
zandreyi just saw that getty gets delayed in the startup by ssh server, and that one get delayed because the entropy was not enough21:57
zandreyand i do recall i had similar results with openssh - around 1 min to console21:58
zandreythis was however almost 2 years ago, and i do not recall much details now on how i did traced it down and brought haveged to address the entropy, effectively speeding-up the openssh to start21:59
zandreyi guess if the randr is ok - there is not much for me to suggest further22:00
*** radsquirrel <radsquirrel!> has quit IRC22:02
RPzandrey: its a good suggestion, thanks. I'm just not sure it is that22:04
halsteadkanavin_home, I've fixed the split DNS config and added a host override for smtp1. Although we should still remove all references to smtp122:05
*** radsquirrel <radsquirrel!> has joined #yocto22:07
*** nslu2-log_ <nslu2-log_!> has joined #yocto22:19
*** nslu2-log <nslu2-log!> has quit IRC22:21
*** radsquirrel <radsquirrel!> has joined #yocto22:21
*** agust <agust!> has quit IRC22:21
*** nslu2-log_ is now known as nslu2-log22:21
*** radsquirrel <radsquirrel!> has quit IRC22:22
* RP is getting totally lost. I know I need to fix something, I just can't remember what :/22:23
kanavin_homehalstead: thanks, I will send a patch to autobuilder that replaces the reference22:27
halsteadThanks for getting this fixed kanavin_home.22:27
RPsakoman: I've put a fix into helper for the python3 result tool error, its as yet untested though22:30
sakomanRP: just a matter of time till a worker with an old distro is used!22:32
sakomanI'll use the patch in my builds too22:36
*** nslu2-log_ <nslu2-log_!> has joined #yocto22:37
*** dmoseley <dmoseley!~dmoseley@> has quit IRC22:38
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto22:39
*** nslu2-log <nslu2-log!> has quit IRC22:39
*** nslu2-log <nslu2-log!> has joined #yocto22:40
*** nslu2-log_ <nslu2-log_!> has quit IRC22:43
*** NiksDev <NiksDev!~NiksDev@> has quit IRC22:45
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto22:45
RPsakoman: thanks, sounds good22:52
*** psnsilva__ <psnsilva__!> has joined #yocto23:06
*** psnsilva_ <psnsilva_!~psnsilva@2001:818:dae7:b100:31e0:7192:2b55:e4ad> has quit IRC23:10
*** goliath <goliath!> has quit IRC23:24
*** Klanticus <Klanticus!> has quit IRC23:34

Generated by 2.17.2 by Marius Gedminas - find it at!