| *** vineela <vineela!~vtummala@134.134.139.74> has quit IRC | 00:16 | |
| khem | jonmason: on 2019 I had meta-zephyr working for a demo | 00:22 |
|---|---|---|
| *** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 00:26 | |
| *** otavio <otavio!~otavio@181.220.78.182> has joined #yocto | 00:28 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 00:28 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 00:47 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 00:51 | |
| jonmason | khem: was there any trick to it? I cannot seem to get it to compile | 01:09 |
| khem | dont remember anything special | 01:36 |
| khem | but a lot of water has flown since so there might new errors what problems do you see | 01:36 |
| khem | I remember tweaking TCLIBC bits for baremetal a bit but I upstreamed those to oe-core | 01:36 |
| jonmason | I 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" error | 01:48 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 03:36 | |
| khem | m4 error chimes a bell | 03:52 |
| *** NiksDev <NiksDev!~NiksDev@192.91.101.32> has quit IRC | 04:35 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.12> has joined #yocto | 04:35 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 05:05 | |
| *** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-11-174-88-220-58.dsl.bell.ca> has joined #yocto | 05:31 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:36 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 05:51 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto | 05:55 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 05:57 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 06:00 | |
| *** manuel1985 <manuel1985!~manuel@089144218249.atnat0027.highway.a1.net> has joined #yocto | 06:09 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto | 06:14 | |
| *** manuel1985 <manuel1985!~manuel@089144218249.atnat0027.highway.a1.net> has quit IRC | 06:14 | |
| *** manuel1985 <manuel1985!~manuel@089144218249.atnat0027.highway.a1.net> has joined #yocto | 06:15 | |
| *** sxiii <sxiii!~sw@cm-84.214.223.252.getinternet.no> has quit IRC | 06:18 | |
| *** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC | 06:19 | |
| *** manuel1985 <manuel1985!~manuel@089144218249.atnat0027.highway.a1.net> has quit IRC | 06:19 | |
| *** manuel1985 <manuel1985!~manuel@089144218249.atnat0027.highway.a1.net> has joined #yocto | 06:20 | |
| *** manuel1985 <manuel1985!~manuel@089144218249.atnat0027.highway.a1.net> has quit IRC | 06:21 | |
| *** manuel1985 <manuel1985!~manuel@089144218249.atnat0027.highway.a1.net> has joined #yocto | 06:22 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 06:34 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 06:34 | |
| *** zandrey_ <zandrey_!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 06:40 | |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 06:44 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 06:47 | |
| *** manuel1985 <manuel1985!~manuel@089144218249.atnat0027.highway.a1.net> has joined #yocto | 06:51 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 06:55 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:56 | |
| *** mckoan|away is now known as mckoan | 07:05 | |
| *** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has joined #yocto | 07:11 | |
| *** yann <yann!~yann@88.120.44.86> has joined #yocto | 07:30 | |
| *** Moh3N <Moh3N!2ed17334@46.209.115.52> has joined #yocto | 07:41 | |
| Moh3N | Hi , 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@213.138.44.181> has joined #yocto | 07:51 | |
| *** sxiii <sxiii!~sw@2a02:20c8:5640::2> has joined #yocto | 08:01 | |
| *** florian_kc is now known as florian | 08:02 | |
| *** Moh3N <Moh3N!2ed17334@46.209.115.52> has quit IRC | 08:04 | |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 08:07 | |
| *** zandrey_ <zandrey_!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 08:10 | |
| *** sno <sno!~sno@p5b25b0d4.dip0.t-ipconnect.de> has quit IRC | 08:10 | |
| *** sno <sno!~sno@p5b25b0d4.dip0.t-ipconnect.de> has joined #yocto | 08:13 | |
| *** xtron1 <xtron1!~xtron@103.113.103.49> has joined #yocto | 08:25 | |
| *** awe001 <awe001!~awe00@unaffiliated/awe00> has joined #yocto | 08:26 | |
| *** xtron1 <xtron1!~xtron@103.113.103.49> has quit IRC | 08:28 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 08:28 | |
| *** zandrey_ <zandrey_!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 08:43 | |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 08:46 | |
| *** hpsy <hpsy!~hpsy@92.118.12.85> has joined #yocto | 09:06 | |
| *** f0h <f0h!~f0h@farfarello.0xf0.eu> has quit IRC | 10:18 | |
| *** jimr <jimr!~jimr@185.189.115.113> has joined #yocto | 10:23 | |
| *** f0h <f0h!~f0h@farfarello.0xf0.eu> has joined #yocto | 10:24 | |
| *** zandrey_ <zandrey_!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 10:25 | |
| *** jimr <jimr!~jimr@185.189.115.113> has quit IRC | 10:34 | |
| *** lxc <lxc!d9d0c05b@217-208-192-91-no98.tbcn.telia.com> has joined #yocto | 11:22 | |
| lxc | Stumbled 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@193.8.40.126> has joined #yocto | 11:31 | |
| *** berton <berton!~berton@181.220.78.182> has joined #yocto | 11:39 | |
| RP | lxc: I can see how that would happen :( | 11:40 |
| lxc | As an example, consider the following google repository, https://github.com/gflags/gflags, 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 |
| RP | lxc: you have to question whether repository design like that makes sense :/ | 11:44 |
| lxc | Self-referencing submodule: https://github.com/gflags/gflags/blob/master/.gitmodules | 11:44 |
| RP | lxc: I'm not sure what we can do here at the bitbake level either :/ | 11:44 |
| lxc | Agree, I have not seen that submodule pattern before. But since it exists and dead-locking is bad... | 11:45 |
| RP | lxc: we can probably detect it and just error out? | 11:46 |
| lxc | Well, 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!~ags@31-10-206-124.static.upc.ch> has quit IRC | 11:47 | |
| RP | lxc: 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!~ags@31-10-206-124.static.upc.ch> has joined #yocto | 11:50 | |
| lxc | Minimum 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@82.193.28.184> has joined #yocto | 12:05 | |
| RP | lxc: It probably needs a bug opening for it | 12:18 |
| RP | lxc: do you fancy fixing it? :) | 12:19 |
| lxc | Well new to the yocto scene so not sure how to submit one... thru the mailing list or on git or how? | 12:20 |
| RP | lxc: it would be through a patch sent to the bitbake-devel mailing list | 12:21 |
| lxc | haha, I was not planning to fix it, don't have one. I just observed the bug. | 12:21 |
| RP | bonus marks for adding tests to lib/bb/tests/fetch.py | 12:21 |
| RP | lxc: ah, for bugs, file at https://bugzilla.yoctoproject.org | 12:22 |
| lxc | Bug 14045 | 12:29 |
| *** vineela <vineela!~vtummala@134.134.139.72> has joined #yocto | 12:32 | |
| RP | lxc: thanks. Not sure if/when we'll get to it but its worth tracking as we shouldn't deadlock | 12:33 |
| lxc | is there a tutorial for how to build an lxc with the core-image? | 12:41 |
| *** leonardo38 <leonardo38!52c11cb8@82.193.28.184> has quit IRC | 12:47 | |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 12:50 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 12:58 | |
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has joined #yocto | 13:00 | |
| RP | JaMa: does that patchset address the issues the autobuilder ran into last time? | 13:00 |
| RP | JaMa: this is for 3.2? | 13:00 |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 13:00 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has quit IRC | 13:02 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 13:02 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has joined #yocto | 13:06 | |
| fullstop | So I rebuilt the world last night, and now 70% of the sstate targets match on the other machine. | 13:11 |
| fullstop | I have also seen where NATIVELSBSTRING seems to change between universal and ubuntu-16.04 seemingly at random. | 13:11 |
| fullstop | The PC with 70% match does not appear to grab the uninative binaries? | 13:13 |
| RP | fullstop: once the uninative is in DL_DIR, you probably wouldn't see it fetch again | 13:18 |
| RP | fullstop: are the sigs difference in the two different builds? | 13:18 |
| fullstop | first run of bitbake: NATIVELSBSTRING = "ubuntu-16.04" | 13:18 |
| fullstop | second run of bitbake: NATIVELSBSTRING = "universal" | 13:19 |
| RP | fullstop: I think there is a UI glitch where the first run doesn't display that correctly :/ | 13:19 |
| fullstop | all I did was bitbake -n recipename | 13:19 |
| fullstop | oh | 13:19 |
| fullstop | so I'm chasing a ghost | 13:19 |
| RP | fullstop: I suspect so :( | 13:19 |
| RP | its possible its having wider effects but I just don't know | 13:20 |
| RP | I 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 IRC | 13:20 | |
| *** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:99e9:1c8a:8ebf:fa95> has joined #yocto | 13:20 | |
| RP | That should probably have an open bug | 13:20 |
| fullstop | Is that string used at all in deriving the signatures? | 13:22 |
| fullstop | RP: 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 |
| RP | fullstop: that string is used but I think by that time its been expanded (its after its shown on the UI) | 13:27 |
| RP | fullstop: it should need to get uninative from somewhere... | 13:28 |
| fullstop | before or after it downloads all of the stuff from sstate-cache? | 13:28 |
| fullstop | I stopped bitbake once it started downloading gcc/binutils/and friends. | 13:28 |
| RP | fullstop: it should be expanded before it accesses sstate | 13:30 |
| RP | Check the logs and see which sstate urls its looking for? | 13:30 |
| JaMa | RP: 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 time | 13:31 |
| fullstop | RP: sstate-cache/c1/a4/sstate:libtool-cross:cortexa5t2hf-neon-vfpv4-poky-linux-gnueabi:2.4.6:r0:cortexa5t2hf-neon-vfpv4:... | 13:31 |
| fullstop | It really looks like it's wanting to build a cross compiler. | 13:32 |
| JaMa | RP: I don't mind if it slips to 3.3 if you're concerned about this for 3.2 | 13:33 |
| RP | JaMa: I'll run it through testing and see what happens. If there are issues we'll defer | 13:35 |
| JaMa | RP: perfect, thanks | 13:35 |
| RP | fullstop: can you find something native which would have the NATIVELSBSTRING in though | 13:36 |
| JaMa | btw: when migrating one of my LuneOS builds from zeus to dunfell I've noticed interesting side-effect of using OEHashEquiv without public HashServe | 13:36 |
| RP | fullstop: the question for libtool-cross is does the hash match between the two builds? | 13:36 |
| JaMa | I 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 same | 13:38 |
| JaMa | HashServe my other build wasn't able to use it? | 13:38 |
| RP | JaMa: right, that is what would happen | 13:39 |
| JaMa | OK, so all the build time savings from OEHashEquiv on one builder will be spent on another builder unless they all share HashServe as well | 13:40 |
| RP | JaMa: yes | 13:40 |
| RP | we have no way to export the equivalence into sstate at present | 13:41 |
| RP | fullstop: I wonder if your issue is related. Are you using a local hashequiv server? | 13:41 |
| fullstop | RP: I am not, and every signature that I look at seems different between the two machines. | 13:42 |
| *** psnsilva_ <psnsilva_!~psnsilva@207.15.249.5.rev.vodafone.pt> has joined #yocto | 13:42 | |
| RP | fullstop: ok, pick something early in the build. You need to find the first ones which differ | 13:42 |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 13:43 | |
| RP | fullstop: you may also get clues if you bitbake-diffsigs A B between two of them | 13:43 |
| fullstop | gcc-runtime okay? | 13:43 |
| *** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:99e9:1c8a:8ebf:fa95> has quit IRC | 13:43 | |
| RP | fullstop: its a good one, yes | 13:43 |
| JaMa | do you have some statistics from AB about HashEquiv? or load/bandwidth on typhoon.yocto.io ? | 13:43 |
| lxc | anyway to get more logs from do_unpack? Having a stalled one I want to see why that is. | 13:44 |
| RP | JaMa: no. Can barely keep it running, let alone look at stats :( | 13:44 |
| fullstop | do_deploy_source_date_epoch and do_fetch are identical | 13:44 |
| fullstop | but do_compile and do_configure do not match | 13:44 |
| JaMa | RP: ok, understood :/ | 13:44 |
| RP | lxc: looked at WORKDIR/temp/log.do_unpack for that recipe? | 13:44 |
| RP | fullstop: ok, have a look at configure since its earlier | 13:45 |
| RP | either it will have differences or it will point at dependencies that differ | 13:45 |
| *** psnsilva__ <psnsilva__!~psnsilva@2001:818:dae7:b100:99e9:1c8a:8ebf:fa95> has joined #yocto | 13:45 | |
| fullstop | RP: I'm not quite sure how to do that | 13:46 |
| JaMa | I'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 tests | 13:47 |
| *** psnsilva_ <psnsilva_!~psnsilva@207.15.249.5.rev.vodafone.pt> has quit IRC | 13:47 | |
| fray | JaMa, 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 |
| JaMa | anyway 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 gain | 13:48 |
| fray | problem is when a builders output gets added to the sstate-cache, how do you sync it.. | 13:48 |
| RP | JaMa: A RO hash equiv would be really useful, there is an open bug for it | 13:50 |
| JaMa | yes, it's the same issue as in https://bugzilla.yoctoproject.org/show_bug.cgi?id=5399 with PR servise | 13:50 |
| JaMa | ideally 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 significantly | 13:53 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:53 | |
| JPEW | JaMa: 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 server | 13:54 |
| JPEW | The 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 it | 13:55 |
| JaMa | until someone suggests more than 2 levels of hierarchy :) | 13:55 |
| JPEW | JaMa: Ya, I don't think multiple levels is really that different once you get the first level working | 13:56 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 13:57 | |
| JaMa | imagine HashEquiv Root servers running next to DNS Root servers hashing all the pr0n from internet to de-duplicate it.. | 13:57 |
| qschulz | ndec: RP: what's the deadline for the sphinx doc review/fixes? | 13:58 |
| ndec | last month :) | 13:58 |
| fray | I 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 mirror | 13:58 |
| JaMa | that's plenty of time :) | 13:58 |
| fray | the 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 |
| JPEW | JaMa: The server doesn't do any hashing. It's actually probably a lot simpler that you might be imagining :) | 13:59 |
| ndec | qschulz: 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 |
| qschulz | ndec: yeah anyway it would be just cosmetic/small fixes if I find the time to go through it | 14:00 |
| ndec | qschulz: 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 IRC | 14:00 | |
| JPEW | fray: 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 simple | 14:00 |
| RP | qschulz: there are still many fixes to be found, we'll be taking those as they come in | 14:00 |
| ndec | qschulz: right. the most important was to merge into master and 'switch' officially. we will surely take additional fixes.. | 14:00 |
| qschulz | ndec: 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 |
| RP | qschulz: help would be much appreciated as the docs work is just burning me out :( | 14:02 |
| qschulz | RP: yeah it's tedious.. if you consent, sending virtual corona-free hugs | 14:07 |
| JaMa | JPEW: my understanding is that OEOuthashBasic does the hashing and HashServe just manages groups of equivalent hashes | 14:07 |
| RP | qschulz: thanks :) | 14:08 |
| RP | qschulz: I know the note sections are missing markup and links if you're looking for patterns of issues to fix | 14:08 |
| *** tlwoerner_ <tlwoerner_!~trevor@206.248.190.95> has joined #yocto | 14:08 | |
| RP | and I think links in general need a lot of sanity checking | 14:08 |
| *** tlwoerner_ <tlwoerner_!~trevor@206.248.190.95> has left #yocto | 14:09 | |
| qschulz | RP: 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 |
| qschulz | RP: thx for the suggestions | 14:10 |
| RP | qschulz: yes, I was thinking of finding some tool to check the links | 14:10 |
| fullstop | RP: I may have found something.. sqlite3-native:do_deploy_source_date_epoch is different between the two. | 14:11 |
| RP | fullstop: that would be significant | 14:13 |
| fullstop | What exactly does that represent? | 14:13 |
| RP | fullstop: its the date stamp used for build reproducibility | 14:13 |
| RP | next, to figure out why its differing | 14:14 |
| fullstop | I'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 IRC | 14:14 | |
| *** psnsilva__ <psnsilva__!~psnsilva@207.15.249.5.rev.vodafone.pt> has joined #yocto | 14:15 | |
| JPEW | JaMa: Correct. Really, it just records them in the table and the "grouping" is done by a SQL query | 14:15 |
| RP | fullstop: it depends on how its being fetched. from git, or the tarball | 14:15 |
| fullstop | RP: one step back.. why not fetched from sstate? | 14:16 |
| fullstop | the recipe gets it from http://www.sqlite.org/2020/sqlite-autoconf-${SQLITE_PV}.tar.gz | 14:16 |
| RP | fullstop: if the hashes for the tasks are different, it will see that as an sstate miss | 14:17 |
| RP | the question is therefore why the task hashes are different | 14:17 |
| fullstop | fetch, patch, deploy source, configure? is that the order? | 14:19 |
| *** vineela <vineela!~vtummala@134.134.139.72> has quit IRC | 14:19 | |
| RP | fullstop: think so | 14:21 |
| fullstop | on the primary host: DEBUG: Reported task 2d1b02d40dd24af10f44538fac59e2b560c19d79bd806b344f40f51aeb4bceb7 as unihash f769ef0fea2cb342629b4d822bdeac77bb8ecadfa99442af8914c5b2db3fb8cc to unix:///home/prox/yocto/poky/build/hashserve.sock | 14:21 |
| fullstop | I don't see anything logged on the other machine regarding hashes, but maybe I can dump that somehow | 14:22 |
| RP | fullstop: ok, you *do* have hashequiv enabled | 14:22 |
| fullstop | wait | 14:22 |
| RP | fullstop: this is the issue JaMa was talking about I think | 14:23 |
| fullstop | #BB_HASHSERVE = "auto" | 14:23 |
| fullstop | It's not explicitly enabled, unless it is enabled by default | 14:23 |
| RP | fullstop: we enabled it by default in dunfell | 14:23 |
| fullstop | Okay, so that's why this behavior is new | 14:23 |
| JaMa | IMHO only in poky, not in default setup (not sure what fullstop is using) | 14:23 |
| JaMa | meta/conf/bitbake.conf:BB_SIGNATURE_HANDLER ?= "OEBasicHash" | 14:24 |
| JaMa | even in master | 14:24 |
| *** rpcme <rpcme!23860dea@035-134-013-234.res.spectrum.com> has joined #yocto | 14:25 | |
| fullstop | I am using poky | 14:26 |
| ndec | RP: qschulz : i ran sphinx linkcheck on bitbake tree, and got the following error: | 14:27 |
| ndec | https://www.irccloud.com/pastebin/fGb2nS5G/ | 14:27 |
| ndec | i am running it on yocto-docs now. | 14:27 |
| ndec | hmm. with the full output it's better: | 14:28 |
| ndec | https://www.irccloud.com/pastebin/9qhIVG4V/ | 14:28 |
| qschulz | ndec: cool! | 14:29 |
| RP | ndec: what about the #XXX references in links though? | 14:29 |
| RP | ndec: that doesn't look too bad to fix up at least | 14:29 |
| ndec | RP: what do you mean with #XXX | 14:30 |
| qschulz | ndec: I'd assume the alternative to #FIXME? | 14:30 |
| qschulz | but I might be completely off :) | 14:30 |
| rpcme | Hello 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. https://gist.github.com/rpcme/0bf012cd125e644dc42e24a81432761f | 14:30 |
| fullstop | What are advisable options here? Go back to the BB_SIGNATURE_HANDLER used in 2.7.x? | 14:31 |
| RP | ndec: I'm blanking on the name for them | 14:31 |
| ndec | you mean the 'custom' labels as opposed to autosection labels? | 14:31 |
| JaMa | fullstop: sharing the same BB_HASHSERVER between all your builders if possible | 14:32 |
| fullstop | I'll have to read up on that and figure out how that works. | 14:33 |
| fullstop | What do I need to run on the host? | 14:33 |
| qschulz | RP: anchors? | 14:33 |
| RP | ndec: html anchors. I'm fairly sure we have a lot of them which are broken | 14:33 |
| fullstop | BB_HASHSERVER has exactly one hit in google. Ha! | 14:33 |
| RP | qschulz: yes, just got there myself :) | 14:33 |
| ndec | RP: is angstrom website down permanently? it's referenced in the bitbake manual. perhaps we could use another example instead, like AGL? | 14:33 |
| RP | ndec: we should switch, yes | 14:34 |
| ndec | RP: linkcheck found "(line 1958) broken https://docs.python.org/3/library/re.html#re - Anchor 're' not found" | 14:34 |
| RP | ndec: also noticed references to gcc-cross-initial and so on | 14:34 |
| JaMa | fullstop: bitbake-hashserv | 14:34 |
| ndec | so looks like it finds problems with anchors. | 14:34 |
| *** emrius <emrius!c3b060cc@eduroam-mapped-204.ethz.ch> has joined #yocto | 14:34 | |
| RP | ndec: does it check the internal links? | 14:34 |
| ndec | it's a bit slow to run.. but it's running on yocto-docs. i will share the output | 14:34 |
| emrius | hey everyone, I'd like to add tmate (https://tmate.io/) to my image. Does somebody have a recipe at hand already? :) | 14:35 |
| RP | fullstop: try BBHASHSERVE ? | 14:35 |
| JaMa | emrius: https://layers.openembedded.org/layerindex/branch/master/recipes/ | 14:35 |
| RP | BB_HASHSERVE | 14:35 |
| ndec | RP: qschulz : here is the output.. | 14:36 |
| qschulz | emrius: apparently not in layers defined there. You can use devtool add <git-url> to start one for the boilerplate | 14:36 |
| emrius | JaMa thanks, I did check oe layers but didn't find anything there | 14:36 |
| ndec | https://pastebin.com/TXnwpiCX | 14:36 |
| emrius | qschulz thanks! will do! | 14:37 |
| ndec | it 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!23860dea@035-134-013-234.res.spectrum.com> has quit IRC | 14:37 | |
| fullstop | RP: 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 |
| RP | fullstop: yes, they all need to point at the same server | 14:38 |
| qschulz | ndec: or host it with python -m http.server? | 14:39 |
| qschulz | "host" | 14:39 |
| ndec | yes, sure. | 14:39 |
| ndec | i meant on the output html. | 14:39 |
| fullstop | RP: and "auto" automatically runs bitbake-hashserv temporarily while bitbake is running? | 14:39 |
| *** carlsb3rg <carlsb3rg!c147afcf@193.71.175.207> has quit IRC | 14:39 | |
| qschulz | ndec: gotcha | 14:39 |
| RP | ndec: I suspect the results will scare us. That link doesn't look too bad to work through | 14:39 |
| RP | fullstop: yes | 14:39 |
| ndec | RP: and btw, these errors probably exist *today* in the current docs.. they were not added by sphinx migration.. | 14:40 |
| RP | ndec: hmm, given the problems I've see, yes and no | 14:40 |
| RP | some yes, we'll have added new ones | 14:40 |
| *** emrius <emrius!c3b060cc@eduroam-mapped-204.ethz.ch> has quit IRC | 14:43 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has joined #yocto | 14:44 | |
| ndec | RP: "(line 158) broken https://docs.yoctoproject.org/singleindex - 404 Client Error: Not Found for url: https://docs.yoctoproject.org/singleindex" this one is yours ;) | 14:44 |
| ndec | in ref-manual/resources.rst | 14:44 |
| RP | ndec: ah. | 14:46 |
| *** luneff <luneff!~yury@80.72.17.178> has joined #yocto | 14:47 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 14:47 | |
| RP | ndec: fix pushed | 14:48 |
| fullstop | RP: a full rebuild is required to populate the hashdb, yes? | 14:52 |
| RP | fullstop: effectively | 14:52 |
| fullstop | okay, I will run that tonight. I set up a systemd service to run bitbake-hashserv. | 14:53 |
| *** luneff <luneff!~yury@80.72.17.178> has quit IRC | 14:54 | |
| *** sr71919 <sr71919!uid463993@gateway/web/irccloud.com/x-sqoihgmflnteirji> has quit IRC | 15:00 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has joined #yocto | 15:01 | |
| *** tolszak <tolszak!~tolszak@apn-31-0-21-12.dynamic.gprs.plus.pl> has joined #yocto | 15:06 | |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 15:08 | |
| *** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has joined #yocto | 15:11 | |
| *** j241 <j241!~Adium@20.ip-51-79-160.net> has quit IRC | 15:12 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 15:13 | |
| *** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 15:29 | |
| *** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 15:31 | |
| ndec | RP: 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 |
| RP | ndec: ah, cool | 15:34 |
| ndec | i think this is our first sphinx patch ;) | 15:34 |
| ndec | where we diverge from docbook.. | 15:34 |
| RP | ndec: I suspect I did that with populate_sdk_ext but still cool | 15:35 |
| *** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has quit IRC | 15:37 | |
| *** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has joined #yocto | 15:37 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 15:38 | |
| *** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has joined #yocto | 15:40 | |
| kergoth | Hmm, should make a list of variables to eventually rename and deprecate to improve clarity and consistency. TOOLCHAIN_*_TASK for one. | 15:44 |
| RP | kergoth: there are quite a few :/ | 15:44 |
| kergoth | yep. wouldn't be fun, but could help new users a bit in the long term | 15:45 |
| fray | variable renaming (I'm all for it) would be a reason to move to '4.0'.. | 15:45 |
| kergoth | not a bad idea | 15:45 |
| kergoth | would be nice to try to add consistency in our word ordering in variable names if we can while we're at it | 15:45 |
| kergoth | sometimes it's object-verb and sometimes vice versa, and related | 15:46 |
| fray | ...and make sure all of the variables are properly documented... | 15:46 |
| kergoth | i.e. sometimes we use the earlier words as a namespace, but not always | 15:46 |
| RP | kergoth: I was thinking about "TMPDIR" and "WORKDIR/temp" the other day | 15:49 |
| kergoth | Ugh, yes, i've wnated to do something about that for like 10 years now | 15:49 |
| kergoth | god, i feel old now | 15:49 |
| RP | obviously need to change it to TMP/TMPVER/TEMPNAME/WORKTEMP/LOGTMP :) | 15:50 |
| kergoth | speaking of weird variable names, the portage legacy is worth thinking about renaming. 'D' 'S' 'T'.. | 15:50 |
| RP | kergoth: 10 years of Yocto, let alone OE. We are getting old... | 15:51 |
| RP | kergoth: I quite like D and S | 15:51 |
| fray | lol, I've been doing Linux (professionally) since 1998 or so.. an embedded Linux since 2000 | 15:52 |
| kergoth | it 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 review | 15:52 |
| fray | I don't mind the D and S.. | 15:52 |
| fray | one 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 well | 15:52 |
| *** verrueckerhund <verrueckerhund!54bfccc6@p54bfccc6.dip0.t-ipconnect.de> has joined #yocto | 15:53 | |
| RP | kergoth: 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/S | 15:53 |
| fray | (I never did figure out why they used 'D' (DEST) and not 'I' (install)) but anyway | 15:53 |
| kergoth | agreed | 15:53 |
| kergoth | would be best to focus on the actively misleading first, and go to unclear and/or confusing later :) | 15:54 |
| kergoth | with all of our copious spare time.. | 15:54 |
| fray | _copious_ | 15:54 |
| kergoth | It'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 |
| RP | kergoth: right. Also, the work in migration for a variable change is very non-trivial | 15:56 |
| kergoth | True, we'd need to add fray's variable usage warning stuff and a clear path and example to follow | 15:57 |
| RP | kergoth: 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 |
| RP | kergoth: its the docs implications which worry me, in some ways more than the code | 15:59 |
| *** crazoes[m] <crazoes[m]!crazoesmat@gateway/shell/matrix.org/x-oynemuzxdwztrsic> has quit IRC | 16:00 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC | 16:07 | |
| *** verrueckerhund <verrueckerhund!54bfccc6@p54bfccc6.dip0.t-ipconnect.de> has quit IRC | 16:08 | |
| *** mckoan is now known as mckoan|away | 16:09 | |
| mckoan|away | e | 16:09 |
| *** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto | 16:11 | |
| *** awe001 <awe001!~awe00@unaffiliated/awe00> has quit IRC | 16:13 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:17 | |
| JaMa | talking 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 |
| RP | JaMa: it does actually say what it is but I know what you mean :/ | 16:20 |
| *** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has quit IRC | 16: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 right | 16:22 |
| JaMa | or when initramfs image has .rootfs as well | 16:23 |
| RP | JaMa: right, those make much less sense | 16:25 |
| RP | JaMa: its a very old holdover to when these were rootfs | 16:25 |
| JaMa | https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/artifacts&id=aa06e7f0b1bce9aef67a89fba07abe14ef3b81aa | 16:26 |
| JaMa | in this I have added them also to .iso, .hddimg, qemuboot, testdata, but then dropped this from patchset, because it doesn't feel right | 16:26 |
| RP | JaMa: you're right, we should probably get rid of it entirely | 16:27 |
| JaMa | at least it should be easier to just set IMAGE_NAME_SUFFIX to empty now when it will be separate variable | 16:27 |
| RP | JaMa: yes, true | 16:30 |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.98.213> has quit IRC | 16:33 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.98.213> has joined #yocto | 16:34 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 16:36 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has quit IRC | 16:44 | |
| *** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC | 16:46 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 16:53 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 16:55 | |
| JaMa | what 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 |
| RP | JaMa: we configure it to skip those | 17:03 |
| RP | JaMa: I do want to revisit that | 17:04 |
| JaMa | aha, 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 added | 17:05 |
| JaMa | will check on some newer build report | 17:05 |
| RP | JaMa: it runs different commands depending on the version its building | 17:06 |
| RP | JaMa: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json#n170 | 17:07 |
| JaMa | thanks will install mesa headers and add these 2 to skip and might get green build with poky master :) | 17:08 |
| RP | JaMa: :) I don't like using the skips but it was better to have the tests than not | 17:08 |
| *** vineela <vineela!vtummala@nat/intel/x-rqwvozltvytiggry> has joined #yocto | 17:18 | |
| *** lxc <lxc!d9d0c05b@217-208-192-91-no98.tbcn.telia.com> has quit IRC | 17:19 | |
| * RP merges bitbake sphinx changes | 17:21 | |
| RP | jonmason, rburton: any progress on the meta-arm warning? | 17:35 |
| rburton | <cough> what one | 17:36 |
| * rburton looks | 17:36 | |
| rburton | i think its the one i've already moved to major severity | 17:36 |
| rburton | i'll escalate | 17:37 |
| kergoth | https://www.anandtech.com/show/16080/nvidia-to-acquire-arm-for-40-billion in case anyone else missed this from a few days ago | 17:38 |
| * kergoth yawns | 17:39 | |
| RP | rburton: thanks | 17:45 |
| *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined #yocto | 18:06 | |
| khem | kergoth: yeah consolidation in silicon industry is on, like it was case in automobiles in later part of 20th century | 18:13 |
| *** Klanticus <Klanticus!~quassel@187-19-90-24.customer.ntelecom.com.br> has joined #yocto | 18:29 | |
| kanavin_home | halstead: so is there a smtp server that is operational? | 18:51 |
| *** lxc <lxc!d9d0c05b@217-208-192-91-no98.tbcn.telia.com> has joined #yocto | 19:02 | |
| lxc | Tryig to add DEPENDS for libasan via gcc-sanitizers, but get an error message. What is required to get libasan in sysroot? | 19:02 |
| RP | lxc: is it being built in gcc-sanitizers? | 19:07 |
| khem | you would need a dep on libasan-dev | 19:08 |
| RP | khem: build time, not runtime? | 19:10 |
| RP | halstead: did you have to restart janitors on f32 as well? | 19:10 |
| khem | for runtime libasan in rdeps or perhaps app linling to it can pull it | 19:10 |
| khem | linking | 19:10 |
| lxc | gcc-sanitizers was skipped: incompatible with host i686-poky-linux-musl (not in COMPATIBLE_HOST) | 19:11 |
| lxc | Ok, so glibc required, not working then with musl | 19:11 |
| halstead | kanavin_home, mail.yoctoproject.org really should be. That's how the mail gets off of the worker. Try 172.29.10.25 instead. Perhaps there is an issue with the split horizon dns. | 19:13 |
| RP | JPEW: more syncthread issues and we know the autobuilder has a deletion backlog so there is io load :( | 19:14 |
| RP | khem: I think they're asking for the build time DEPENDS though | 19:15 |
| * RP wishes he knew what to do about SyncThread, other than remove it | 19:15 | |
| khem | when in doubt always go for removal | 19:16 |
| kanavin_home | halstead: on ubuntu1804-ty-3, mail.yoctoproject.org:25 does not respond, but 172.29.10.25:25 does | 19:16 |
| kanavin_home | halstead: it would be better to not hardcode the ip address though | 19:17 |
| kanavin_home | akanavin@ubuntu1804-ty-3:~/auto-upgrade-helper$ nslookup mail.yoctoproject.org | 19:17 |
| kanavin_home | Server: 127.0.0.53 | 19:17 |
| kanavin_home | Address: 127.0.0.53#53 | 19:17 |
| kanavin_home | Non-authoritative answer: | 19:17 |
| kanavin_home | Name: mail.yoctoproject.org | 19:17 |
| kanavin_home | Address: 198.145.29.25 | 19:17 |
| khem | RP: ideas on the MACHINE = SDKMACHINE patch ? | 19:19 |
| JPEW | RP, khem: I suspect removing the threads will just move the timeout | 19:20 |
| *** master007 <master007!~master007@125.63.125.42> has joined #yocto | 19:20 | |
| RP | khem: I want to look at what is going on there | 19:21 |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto | 19:21 | |
| RP | JPEW: I suspect so too which is why I've not done it | 19:21 |
| RP | khem: should gcc-runtime ptesting chew disk io heavily? | 19:21 |
| RP | khem: we need to find where the machine contamination is coming from and why the selftests don't spot it | 19:24 |
| khem | RP: 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 OVERRIDES | 19:25 |
| RP | khem: why should we have a vardep? | 19:26 |
| RP | Does anyone know how ionice interacts with the extX disk journal? | 19:26 |
| khem | RP:its in overrides for nativesdk | 19:27 |
| khem | and I guess overrides value changes when MACHINE is changed | 19:27 |
| khem | so perhaps MACHINE=a bitbake nativesdk-<recipe> MACHINE=b bitbake nativesdk-<recipe> might reproduce it | 19:28 |
| RP | hmm, https://unix.stackexchange.com/questions/491805/ext4-jbd2-and-i-o-priority seems to echo my worries | 19:30 |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 19:32 | |
| zeddii | has anyone ever seen this out of bitbake: | 19:33 |
| zeddii | NOTE: Executing Tasks | 19:33 |
| zeddii | [Errno 11] write could not complete without blocking | 19:33 |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto | 19:34 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 19:35 | |
| RP | zeddii: interesting. no. | 19:36 |
| zeddii | aaaand now it cleared. was only giving me that for about 10 minutes. | 19:37 |
| RP | JPEW: 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 |
| zeddii | the only hit I got on the error message was from some logging discussions. | 19:38 |
| zeddii | ah, its back. whee. | 19:38 |
| RP | zeddii: what is it building? | 19:38 |
| RP | sounds like the pipes to the workers/cooker are being overloaded with log data | 19:39 |
| zeddii | core-image-minimal | 19:39 |
| *** vineela <vineela!vtummala@nat/intel/x-rqwvozltvytiggry> has quit IRC | 19:39 | |
| RP | hmm, we do that often enoug | 19:39 |
| zeddii | it'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 |
| zeddii | https://pastebin.com/ZP8ranmX | 19:39 |
| zeddii | and now, that. | 19:39 |
| zeddii | very odd. | 19:40 |
| RP | zeddii: its odd its not even up to the building part | 19:40 |
| zeddii | lots of disk, fully idle machine. | 19:40 |
| zeddii | I know! and it just popped in out of nowhere. | 19:40 |
| zeddii | but that's how my day has been. | 19:40 |
| zeddii | hah. 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 |
| zeddii | it is a multiconfig build, but otherwise, pretty simple. | 19:42 |
| RP | halstead: Could we try switching the /home partition to writeback journal only? | 19:53 |
| halstead | RP yes. I do that for distros that have it as an install option. I'll set it up for all the workers. | 19:55 |
| RP | halstead: Ah! this may explain why we're seeing the problem particularly on the fedora workers | 19:57 |
| RP | halstead: if we could switch those over that'd be great, it might well avoid the problems we're seeing | 19:58 |
| halstead | I think the SUSE installer has the option. I'll get the other ones. | 19:58 |
| RP | halstead: thanks, this could explain a few things | 20:01 |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 20:16 | |
| RP | sgw: 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@88.120.44.86> has quit IRC | 20:29 | |
| paulg | strace is your friend? | 20:35 |
| paulg | some kind of network lookup it would seem. | 20:36 |
| fray | RP is it a dependency on "login", moved from one version to another? | 20:36 |
| fullstop | RP: 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 |
| paulg | I 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 entries | 20:39 |
| paulg | noted that serial logins took longer - never went past tracking it down to /etc/hosts entries for 127.x | 20:39 |
| paulg | sounds rather similar. | 20:40 |
| paulg | or, completely unrelated! | 20:40 |
| RP | paulg: I'm just trying to think of how you strace the first boot serial login :) | 20:41 |
| RP | fullstop: that is good news :) | 20:42 |
| RP | paulg: that does sound kind of similar... | 20:42 |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 20:47 | |
| *** lxc <lxc!d9d0c05b@217-208-192-91-no98.tbcn.telia.com> has quit IRC | 20:49 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 20:57 | |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 21:00 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC | 21:03 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 21:07 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 21:08 | |
| *** nslu2-log_ is now known as nslu2-log | 21:09 | |
| *** sxiii <sxiii!~sw@cm-84.214.223.252.getinternet.no> has joined #yocto | 21:09 | |
| *** berton <berton!~berton@181.220.78.182> has quit IRC | 21:17 | |
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has quit IRC | 21:23 | |
| RP | paulg: hostname and hosts appear to match and have the right mappings but it could well be something silly like that | 21:47 |
| *** psnsilva_ <psnsilva_!~psnsilva@2001:818:dae7:b100:31e0:7192:2b55:e4ad> has joined #yocto | 21:48 | |
| paulg | RP, 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__!~psnsilva@207.15.249.5.rev.vodafone.pt> has quit IRC | 21:50 | |
| paulg | like a lot of things in life, I just recall getting savaged by it. | 21:50 |
| zandrey | RP: can it be because the rand entropy is not gathered quick enough? I saw some delays in starts because of this | 21:51 |
| zandrey | do you have haveged package installed? | 21:52 |
| RP | zandrey: virtio rng passthrough is there and enabled | 21:56 |
| *** creich <creich!~creich@p200300f6af3ce810000000000000039b.dip0.t-ipconnect.de> has quit IRC | 21:56 | |
| RP | question is how/why would a serial getty depend on the ssh daemon | 21:56 |
| zandrey | RP: okay. | 21:56 |
| zandrey | i just saw that getty gets delayed in the startup by ssh server, and that one get delayed because the entropy was not enough | 21:57 |
| zandrey | and i do recall i had similar results with openssh - around 1 min to console | 21:58 |
| zandrey | this 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 start | 21:59 |
| zandrey | i guess if the randr is ok - there is not much for me to suggest further | 22:00 |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has quit IRC | 22:02 | |
| RP | zandrey: its a good suggestion, thanks. I'm just not sure it is that | 22:04 |
| halstead | kanavin_home, I've fixed the split DNS config and added a host override for smtp1. Although we should still remove all references to smtp1 | 22:05 |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has joined #yocto | 22:07 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 22:19 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 22:21 | |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has joined #yocto | 22:21 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 22:21 | |
| *** nslu2-log_ is now known as nslu2-log | 22:21 | |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has quit IRC | 22:22 | |
| * RP is getting totally lost. I know I need to fix something, I just can't remember what :/ | 22:23 | |
| kanavin_home | halstead: thanks, I will send a patch to autobuilder that replaces the reference | 22:27 |
| halstead | Thanks for getting this fixed kanavin_home. | 22:27 |
| RP | sakoman: I've put a fix into helper for the python3 result tool error, its as yet untested though | 22:30 |
| sakoman | RP: just a matter of time till a worker with an old distro is used! | 22:32 |
| sakoman | I'll use the patch in my builds too | 22:36 |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 22:37 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 22:38 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 22:39 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 22:39 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto | 22:40 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has quit IRC | 22:43 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.12> has quit IRC | 22:45 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.101.30> has joined #yocto | 22:45 | |
| RP | sakoman: thanks, sounds good | 22:52 |
| *** psnsilva__ <psnsilva__!~psnsilva@207.15.249.5.rev.vodafone.pt> has joined #yocto | 23:06 | |
| *** psnsilva_ <psnsilva_!~psnsilva@2001:818:dae7:b100:31e0:7192:2b55:e4ad> has quit IRC | 23:10 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 23:24 | |
| *** Klanticus <Klanticus!~quassel@187-19-90-24.customer.ntelecom.com.br> has quit IRC | 23:34 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!