Friday, 2020-09-25

*** agust <agust!> has quit IRC00:01
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto00:02
*** kiwi_29 <kiwi_29!> has quit IRC00:09
*** kiwi_29 <kiwi_29!> has joined #yocto00:20
*** kiwi_29 <kiwi_29!> has quit IRC00:31
*** kiwi_29 <kiwi_29!> has joined #yocto00:41
*** kiwi_29 <kiwi_29!> has quit IRC00:57
*** kiwi_29 <kiwi_29!> has joined #yocto00:58
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC01:03
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto01:05
*** PaowZ__ <PaowZ__!~Vince@> has joined #yocto01:07
*** CTer_ <CTer_!~clemens.t@> has joined #yocto01:07
*** PaowZ_ <PaowZ_!~Vince@> has quit IRC01:10
*** CTer <CTer!~clemens.t@> has quit IRC01:10
*** kiwi_29 <kiwi_29!> has quit IRC01:11
*** kiwi_29 <kiwi_29!> has joined #yocto01:11
*** ericch <ericch!> has quit IRC01:22
*** jimr <jimr!> has quit IRC01:25
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC01:40
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto01:40
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC01:56
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto01:57
*** sxiii <sxiii!> has quit IRC02:04
*** sxiii <sxiii!> has joined #yocto02:05
*** kaspter <kaspter!~Instantbi@> has quit IRC02:46
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:46
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC02:50
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto02:55
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC03:02
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto03:04
*** goliath <goliath!> has quit IRC03:15
*** King_In3 <King_In3!~King_InuY@> has joined #yocto03:25
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC03:27
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC03:28
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto03:29
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC03:57
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto03:57
*** jobroe <jobroe!> has joined #yocto04:21
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:29
*** kpo_ <kpo_!> has quit IRC04:54
*** kpo_ <kpo_!> has joined #yocto04:54
*** ctlnwr <ctlnwr!~catalin@> has joined #yocto04:57
*** ctlnwr_ <ctlnwr_!~catalin@> has joined #yocto04:57
*** AndersD <AndersD!> has joined #yocto05:05
*** stew-dw <stew-dw!~stew-dw@> has quit IRC05:06
*** beneth <beneth!> has joined #yocto05:08
*** stew-dw <stew-dw!~stew-dw@2607:fb90:9820:87ad:875d:cc7e:3120:8572> has joined #yocto05:08
*** sxiii <sxiii!> has quit IRC05:13
*** sxiii <sxiii!> has joined #yocto05:16
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC05:19
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto05:20
*** sxiii <sxiii!> has quit IRC05:26
*** sxiii <sxiii!> has joined #yocto05:27
*** feddischson <feddischson!> has joined #yocto05:30
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC05:33
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto05:35
*** sxiii <sxiii!> has quit IRC05:40
*** ThomasD13 <ThomasD13!> has joined #yocto05:47
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC05:48
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto05:49
*** pohly <pohly!> has joined #yocto05:55
*** kaspter <kaspter!~Instantbi@> has quit IRC06:06
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:06
*** kpo_ <kpo_!> has quit IRC06:14
*** kpo_ <kpo_!> has joined #yocto06:14
*** agust <agust!> has joined #yocto06:17
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:19
yannwhat's the status for 3.1.3 ?  on track for release today ?06:22
*** chris_ber <chris_ber!~quassel@> has joined #yocto06:33
* mcfrisk wonders if finding and fixing bitbake and build script race conditions will be my job until retirement in 25 years? It's been the last 20 or so already. Even bazel had race conditions in bazel installation itself which had decided to download java code into $HOME and failed to auto-update them on build servers. all hope lost?06:44
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/> has joined #yocto06:45
*** mckoan|away is now known as mckoan06:45
* mcfrisk also wonders when SW crash root causes will finally be detected before seeing them in real product testing. static analyzers and compilers are able to find roughly 95% of them at compile time but developers seem to be really ignorant at those tools. Things like checking return values or pointers in C/C++ are really simple things which everyone seems to get wrong. Not much has improved in last 20 07:00
* mcfrisk years, which means next 25 years until my retirement will bethe same story. Or can go and rust really break through and get rid of these? java didn't seem to help much, seen so many null pointer crashes there... I think I need a beer already07:00
*** AndersD <AndersD!> has quit IRC07:03
*** stew-dw <stew-dw!~stew-dw@2607:fb90:9820:87ad:875d:cc7e:3120:8572> has quit IRC07:10
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto07:10
*** stew-dw <stew-dw!~stew-dw@2607:fb90:17c9:5517:98b9:fd98:9ae9:5600> has joined #yocto07:14
RPkergoth: we should definitely start using that for BBHandledException07:17
RPmcfrisk: The time I've been spending with intermittent failures does start to get to you after a while!07:18
*** dmoseley <dmoseley!~dmoseley@> has quit IRC07:21
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto07:22
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto07:22
*** stew-dw <stew-dw!~stew-dw@2607:fb90:17c9:5517:98b9:fd98:9ae9:5600> has quit IRC07:23
*** stew-dw <stew-dw!~stew-dw@> has joined #yocto07:28
mcfriskRP: ignorance is bliss. if one stops ignoring issues and treats all of them as bugs to fix, it easily becomes a full time job and a career. with the broad deployment of continuous integration and test setups, jeez, so many problems become very visible in projects and organizations. Trick is to get order of magnitude improvements and fix the root causes before they cause issues. static analysis for C and07:31
mcfriskC++, validation for build scripts?07:31
RPmcfrisk: how many issues do you see from bitbake itself? Just wondering how we're doing...07:32
*** PaowZ_ <PaowZ_!~Vince@> has joined #yocto07:33
mcfriskRP: a bit too many, actually. doing zeus to dunfell updates, it's too easy to get bitbake to 'crash' or hang when meta layers are all messed/mixed up. Once those are sorted, things on yocto and open source side are better. It's usually the company specific SW and build scripts which have races and issues. Though lately also meta-java...07:36
*** PaowZ__ <PaowZ__!~Vince@> has quit IRC07:37
mcfriskoh and the BSP layers.. they can screw everything up. I think some of mine are even corrupting sstate cache somehow. have to wipe tmp for all builds just be sure..07:38
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto07:39
*** ptsneves <ptsneves!b0dd7824@> has joined #yocto07:54
RPmcfrisk: bad metadata messing up sstate is a tough one. Do you have examples of crashing or hanging bitbake? That sounds like something we should try and avoid07:56
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/> has quit IRC07:58
mcfriskRP: bitbake crashes only when meta layers have odd things, wrong branch or some parsing errors. I'm often able to find out manually what the problems are. examples are lost already. Hangs, well also happen for same reasons sometimes. And then there is the 'bitbake -c devshell foo' open for more than 24 hours and exiting console just hangs bitbake. Have to kill processes or build container to recover.07:59
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/> has joined #yocto08:01
RPmcfrisk: well, this is open source and we are happy to try and improve things if we can08:01
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:08
manuel1985Any ideas on how to use that `aws` tool to download stuff from an s3 bucket from a yocto recipe?08:10
ptsnevesmanuel1985 it a jva tool right08:10
manuel1985I think it's python but let me look it up08:11
ptsnevesregadless the way to go is a native recipe08:11
manuel1985manuel@debian:~$ head -1 /usr/local/bin/aws08:12
manuel1985What do you mean with `native recipe`?08:13
*** xtron <xtron!~xtron@> has joined #yocto08:13
ptsnevesa recipe for the build system to use.08:13
ptsnevesso to run on the host08:13
manuel1985Yeah that's what I'm intending to do. The question is: Do I have `aws` available from a docker recipe? I would like to run `aws s3 cp s3://myfile ${WORKDIR}`. Didn't try yet, but I guess I don't have `aws` available in a recipe.08:14
*** xtron1 <xtron1!~xtron@> has joined #yocto08:16
ptsnevesmanuel1985 can you clarify what you mean by running from a docker recipe?08:17
*** florian_kc is now known as florian08:19
manuel1985I would like to put a `do_fetch()` function in my recipe which downloads this file from the s3 bucket. And in this function I'd call `aws`08:19
*** xtron <xtron!~xtron@> has quit IRC08:19
manuel1985I can't try it out right now, but I assume it won't work, because in an issue unrelated to this I once tried to run `docker pull` in the same way in a recipe, and I think it told me it can't find `docker` altough it's installed on the machine the build was running on08:20
rburtonright, inside builds you have minimal commands from the host08:20
rburtonso that you don't end up relying on stuff on the host which isn't tracked by dependencies08:21
rburtonthe hack is to add aws to HOSTTOOLS, but then you need to document that everyone using the recipe needs to install those things08:21
rburtonthe proper fix is a recipe that installs aws, and DEPEND on that08:21
rburtonfwiw, there is already a s3 fetcher08:22
rburtoni suspect it has aged badly as it assumes aws is present on $PATH so will hit the same issue, but that's easily fixed08:23
manuel1985Alright, gonna look for it :) That was valuable information, thanks for the insight on the inner workings of yocto! aws is available in my $PATH so hopefully I won't run into problems :)08:28
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC08:31
*** Jackiehjm <Jackiehjm!~quassel@> has joined #yocto08:32
rburton"inside builds you have minimal commands from the host" is saying that aws *won't* be on $PATH08:41
rburtonthus the hosttools hack08:41
rburtonthere should be an aws-native recipe that can get magically depended on08:42
*** fbre <fbre!91fdde45@> has joined #yocto08:49
fbreHi! I use dunfell. How do I add the kernel .bin file to the boot partition of my SD card?  I added INITRAMFS_IMAGE = "core-image-tiny-initramfs" and INITRAMFS_IMAGE_BUNDLE = "1" which bitbakes a file Image-initramfs-imx8mmevk.bin08:52
fbreBut the core-image-minimal-imx8mmevk.wic.gz doesn't seem to contain that Image-initramfs-imx8mmevk.bin08:53
fbreWith yocto "sumo" I found out I have to add this line to my conf file:   IMAGE_BOOTFILES += "${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin"08:54
fbreBut it doesn't have an effect with dunfell08:54
fbreAnyway, when I'm in u-boot and do "fatls mmc 1:1" I just see 2 files:  Image   and my device tree .dtb file08:59
*** Jackiehjm <Jackiehjm!~quassel@> has quit IRC09:01
qschulzImage is the kernel image?09:03
ernstpRP: I'm going to ping this again :-)
RPernstp: didn't we try testing that and it caused problems? :/09:05
ernstpRP: I'm not aware of that. I can search the ML09:06
RPernstp: I think my other concern would be special casing specific fetchers in the core code. That is usually a bad sign and we've usually been able to avoid doing it09:07
RPI wish I had the time to sit down and properly look at these things :(09:07
ernstpRP: 1) git protocol is blocked. 2) we download an git archive tar from a PREMIRROR, everyone is happy. 3) a recipe is updated with a new sha1 4) yocto tries to do "git fetch" in the archive, but it's configured for the git protocol and that's still blocked09:09
ernstpRP: so this is very much related to the PREMIRROR system, which is a bit more "core" than just the git fetcher itself09:10
RPernstp: are you doing 2) manually?09:11
ernstpRP: no that works out of the box09:11
ernstpRP: there are only a couple of recipes with git protocol gits09:12
ptsnevesernstp what are you trying to solve?09:12
*** hpsy <hpsy!~hpsy@> has quit IRC09:12
*** hpsy <hpsy!~hpsy@> has joined #yocto09:12
ernstpptsneves: I submitted a patch some time ago, pinged it again:
ptsnevesernstp from your description and commit message it sounds the behavior is already taken care by a fresh clone09:13
ptsneveswhich would be triggered if the hash was not found in the local downloads09:13
RPernstp: Can you at least resend the patch with more of the info above. That does make the situation clearer and helps. I'm not promising to merge it but it would help09:13
ernstpptsneves: you get ERROR: prelink-native-1.0+gitAUTOINC+05aeafd053-r0 do_unpack: Fetcher failure:09:13
ernstpfatal: reference is not a tree: 05aeafd053e56356ec8c62f4bb8f7b95bae192f309:13
RPernstp: I note I'm the owner of that bug :(09:14
ernstpRP: i get an email every time you push it to the next milestone :-)09:14
ptsnevesernstp it is interesting, because we were victims of a similar issue but found that the behavior in yocto was correct.09:14
RPernstp: I have way more bugs than its feasible for me to handle :(09:15
ernstpptsneves: it's annoying to have to go into Jenkins servers and clear their download cache etc...09:15
ernstpRP: yeah, I'll just ping you once every year :-)09:16
ernstpbut yeah I can resend it to the list, with a longer message09:16
qschulzfbre: then what's the issue?09:17
RPernstp: please do that rather than just ping :)09:17
ernstpthere was no testing I think:
RPernstp: or I forgot to report back :(09:19
ernstpRP: might need to rebase it also, master has of course moved...09:20
ptsnevesthe issue i have with that patch is that it couples the __init__ with git fetcher09:23
ptsnevestrying to see an alternative09:25
fbreaaaarghhh (facepalm) - the viariable is not IMAGE_BOOTFILES but IMAGE_BOOT_FILES X) :')09:26
fbreThat has changed from sumo to dunfell09:27
fbrenow it works09:27
ernstpptsneves: i wondered if it could be made more generic, but I wanted to be conservative and limit it as much as possible to reduce risk09:27
ptsneves> 1) git protocol is blocked. 2) we download an git archive tar from a PREMIRROR, everyone is happy. 3) a recipe is updated with a new sha1 4) yocto tries to do "git fetch" in the archive, but it's configured for the git protocol and that's still blocked09:29
ptsnevesfrom this description i do not understand why the git fetch does not try to fetch from the upstream mirror as in the first time09:30
ptsnevesit is the issue right?09:31
ernstpptsneves: yeah you run into a "Fetcher failure". The exception says "General fetcher exception when something happens incorrectly"09:44
ernstpptsneves: yeah ok there should be an additional item in the list09:45
ernstpit does fetch it from the upstream mirror but it does that to a different path, vs
*** fbre <fbre!91fdde45@> has quit IRC09:49
ernstpso that's what my patch does, it fixes that link09:49
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:54
*** manuel1985 <manuel1985!> has quit IRC10:03
*** ctlnwr <ctlnwr!~catalin@> has quit IRC10:07
*** ctlnwr_ <ctlnwr_!~catalin@> has quit IRC10:07
*** Klanticus <Klanticus!~quassel@> has joined #yocto10:12
*** manuel1985 <manuel1985!> has joined #yocto10:17
*** CTer_ <CTer_!~clemens.t@> has quit IRC10:18
yannanyone konws the status for 3.1.3 ?  on track for release today ?10:18
*** manuel1985 <manuel1985!> has quit IRC10:19
*** manuel1985 <manuel1985!> has joined #yocto10:20
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC10:21
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto10:21
*** ThomasD13 <ThomasD13!> has quit IRC10:28
*** sev_ <sev_!~sev@2003:a:12a:1300:8e16:45ff:fe1e:3785> has joined #yocto10:33
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC10:38
*** guerra <guerra!> has joined #yocto10:39
*** ptsneves <ptsneves!b0dd7824@> has quit IRC10:42
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto10:48
RPyann: QA report due next week. Its a little behind10:50
*** kpo_ <kpo_!> has quit IRC10:50
RPyann: it is built and in QA10:50
*** kpo_ <kpo_!> has joined #yocto10:51
*** pev <pev!> has joined #yocto10:52
yannis the tag available somewhere already ?  I'm preparing our first dunfell-based release and i'd prefer to use that one from the start10:54
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC10:54
yannfor now I've taken 44ab5a84770bf as closest guess I could make :)10:55
pevSo I built a generic core-image-minimal qemuarmv5 build in dunfell but I don't get a virtual console working although doing "runqemu ... nographic" is fine. Is that something that should be expected to work as per qemuarm core-image-minimal?11:08
rburtonif you pass nographic then you should get a login prompt, yes11:11
*** stew-dw <stew-dw!~stew-dw@> has quit IRC11:26
*** stew-dw_ <stew-dw_!~stew-dw@> has joined #yocto11:27
*** beneth <beneth!> has left #yocto11:36
*** radsquirrel <radsquirrel!> has quit IRC11:37
*** berton <berton!~berton@> has joined #yocto11:40
*** radsquirrel <radsquirrel!> has joined #yocto11:41
RPyann: the QA email has the revisions in (sent to the yocto list)11:45
RPyann: basically current tip of dunfell11:46
*** ak77 <ak77!c12e4b03@> has joined #yocto11:47
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto12:06
*** ctlnwr <ctlnwr!~catalin@> has joined #yocto12:24
*** ctlnwr_ <ctlnwr_!~catalin@> has joined #yocto12:24
yannRP:  I recieved the 3.2M3 notifications but not the 3.1.3 one12:44
*** carlsb3rg <carlsb3rg!c147afcf@> has joined #yocto12:44
carlsb3rgin my <machine>.conf, I specify a WKS_FILE. Where do I actually put the file?12:45
carlsb3rgI've copied the directdisk-bootloader-config.wks, and directdisk-bootloader-config.cfg from ~/poky/scripts/lib, but have no clue where to put them or whether this is the right way of doing things12:47
carlsb3rgmy main objective is to have a custom directdisk-bootloader-config.cfg without changing the one in the poky repo (since touching the poky repo is considered bad practice)12:49
yannRP: in the yocto-3.2_M3.rc2 thread you wrote "The 3.1.3 build should also be arriving shortly" but does not show anything more precise than "3.1.3 will be built soon" afterwards - and I still can't wrap my mind around the ML archive UI to be able to see the latest mails in the list12:50
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC13:00
*** stew-dw_ <stew-dw_!~stew-dw@> has quit IRC13:00
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto13:00
*** stew-dw <stew-dw!~stew-dw@2607:fb90:982a:7308:b6b7:6a91:ba07:3be8> has joined #yocto13:00
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC13:01
*** camus1 <camus1!~Instantbi@> has joined #yocto13:04
*** kaspter <kaspter!~Instantbi@> has quit IRC13:05
*** camus1 is now known as kaspter13:05
*** xtron1 is now known as xtron13:10
*** la_croix <la_croix!> has quit IRC13:12
*** rcw <rcw!~rcw@> has joined #yocto13:18
*** ericch <ericch!> has joined #yocto13:19
*** rcw <rcw!~rcw@> has quit IRC13:30
*** goliath <goliath!> has joined #yocto13:30
*** rcw <rcw!~rcw@> has joined #yocto13:31
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC13:47
*** maudat <maudat!> has joined #yocto13:53
*** camus1 <camus1!~Instantbi@> has joined #yocto14:00
*** kaspter <kaspter!~Instantbi@> has quit IRC14:00
*** camus1 is now known as kaspter14:00
*** vmeson <vmeson!> has quit IRC14:06
*** vmeson <vmeson!> has joined #yocto14:09
*** roussinm <roussinm!> has quit IRC14:18
*** jobroe <jobroe!> has quit IRC14:23
*** King_In3 <King_In3!~King_InuY@> has quit IRC14:23
*** WillMiles <WillMiles!~Will@> has joined #yocto14:25
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto14:27
*** ibinderwolf <ibinderwolf!> has quit IRC14:29
RPyann: the email didn't make it to the list :(14:34
RPyann: I've resent14:36
*** anonzadas <anonzadas!> has quit IRC14:36
*** anonzadas <anonzadas!> has joined #yocto14:37
yannRP: got it, thx!14:38
yannI was wondering, I remember sometimes seeing a meta-oe sha1 in such reports - what's the rule here ?14:39
RPyann: not sure meta-oe has ever been listed there14:40
RPyann: meta-oe isn't used in the autobuilders release build target14:40
yannok, I'm probably confusing with a different report14:42
RPwe probably should test more but it is what it is14:42
armpitmeta-oe should not have been in yocto list14:42
*** stephano <stephano!> has joined #yocto14:43
armpityann Khen sends out world build status from time to time14:43
armpitfor meta-oe14:43
RParmpit: Yann Khen? I've not heard of them before :)14:44
*** exoyds <exoyds!1fcdc9f8@> has joined #yocto14:44
armpithehe, forgot the comma14:44
armpitand misspelled14:44
armpityann, oecore is in the QA listing14:50
*** exoyds <exoyds!1fcdc9f8@> has quit IRC14:53
ad__hi, building dunfell from poky/crops, at the end, bitbake stays a lot of time (>30min) stop on "Summary: There were 39 WARNING messages shown." without completing. Is this normal ?14:53
RPad__: is it doing something with buildhistory? Its probably doing something but 30mins is a long time14:54
RPad__: its also possible there are processes which aren't exiting. What does ps ax show as running?14:54
*** Konsgnx <Konsgnx!> has joined #yocto14:55
sgwMorning folks14:55
RPmorning sgw14:55
sgwRP: I just send a couple of RFC patches for the target dumping14:55
ad__RP, it's stop in this way
yannad__: doesn't crops need to publish/copy-out sstate and such ?14:56
RPad__: hmm, so probably not buildhistory14:56
yann(for persistence between builds)14:56
*** pabigot <pabigot!> has joined #yocto14:56
*** kaspter <kaspter!~Instantbi@> has quit IRC14:57
ad__RP, ps aux | grep python  does not show any process14:58
ad__i only see containerd-shim and docker run14:58
RPsgw: you're implying we already have a set of commands and they're just not running?14:58
RPad__: I'm no crops expert but that sounds it should have exited then :/14:59
ad__i tried CTRL+C nothing happen, so, closed the terminal14:59
ad__let's see14:59
ad__now re-running14:59
*** Zajc <Zajc!~Zajc@> has joined #yocto15:00
*** roussinm <roussinm!> has joined #yocto15:02
ad__now on rebuild it completed fine15:02
ad__well, thanks anyway for the support15:02
ecdhezeddii: I found it, my defconfig file was not found because I had accidentally copy pasted a similar but not identical filename15:03
ecdhezeddii: it was obvious once I found the actuall directory that bitbake was looking in, but I still wish it had told me15:04
yannad__: that's really what a sstate rsync would look like :)15:04
ad__yann, ah ok, thanks. Will study on it.15:05
yann30min looks like a lot, but I've see some docker instances ('s) being really slow when it comes to copying data, even inside a single docker container15:05
*** agodard <agodard!> has joined #yocto15:06
yanncopying an unpacked yocto SDK (not even an extended one) does takes more than that time15:06
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto15:14
*** agodard <agodard!> has quit IRC15:15
RPecdhe: there is a patch for that in master now15:15
*** manuel1985 <manuel1985!> has quit IRC15:29
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC15:31
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto15:32
RPJPEW, fray: core-image-sato builds and passes testimage with path filtering :)15:34
JPEWRP: Cool15:34
* RP should probably do a binary image compare next, see if anything weird happened.15:35
RPthe more I look at the pseudo logs in WORKDIR, the more I think there are things which are very very wrong today when reusing builddirs15:35
*** rsalveti <rsalveti!uid117878@gateway/web/> has quit IRC15:38
kergothHmm, I bet the values returned by the config in python-native probably don't apply to a mingw prebuilt binary windows python installation. Guess I should test it, though15:39
*** PaowZ_ <PaowZ_!~Vince@> has quit IRC15:41
RPjonmason: do you have thoughts on the cortex-m0 patch in master-next?15:44
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:46
sgwRP: there seems to be two paths, one for testimage class that uses OEQemuTarget and the other for HW , which seems to have a QemuTarget class also15:53
sgwThe HW/QemuTarget path had a cmd dumper, but the OEQemuTarget did not.15:53
RPsgw: and that works over serial?15:55
*** manuel1985 <manuel1985!> has joined #yocto15:55
RP(the dump commands are run over the serial interface)15:57
sgwRP: yes the code I provided runs over the qemu serial, since I still had your Took x seconds to login code, I saw that multiple times.15:58
RPsgw: ok, cool. I'm just surprised its this simple!15:58
RPas ever its all about knowing which small number of magic lines to put where :)15:59
sgwTook me a while to figure out is was not going to be complex as I had to backtrace where things where coming from.15:59
RPsgw: we really need to simplify some of it16:00
sgwAnd then figuring out I did not have 'd' available to get the args and ...16:00
RPsgw: indeed, the lack of d can be a shock :)16:00
sgwYesh I thought having two qemu targets was wrong, they seem to serve very different purposes.  That's a longer term clean-up I think16:01
jonmasonRP: rburton mentioned that to me.  I was going to take a look after lunch.16:01
sgwIt initially confused me because the QemuTarget did have access to the Dumpers, but I figured out the OEQemuTarget is not of the same class, OEQemuTarget is of the OESSHTarget Class16:01
RPjonmason: ok, np. I just need a hint on whether it is right or not :)16:02
RPsgw: those names look quite poor :/16:02
sgwI will wait until next week and then and if anyone has comments then move it out of RFC, unless your comfortable with it now.16:03
RPsgw: I'll probably put it in testing for builds over the weekend16:03
sgwSounds fair, how often has the network failure been happening?16:03
RPsgw: it sounds good at least :)16:03
RPsgw: not very often, just often enough to be annoying16:03
RPonce every week or two16:03
jonmasonRP: the previous m0plus looked okay.  So I'm going to assume without looking that it should be fine.  But I'll have an answer in an hour or so16:04
RPjonmason: np, I just didn't know it ross had talked to you16:04
*** carlsb3rg <carlsb3rg!c147afcf@> has quit IRC16:05
jonmasonSimilarly, I have cortex m series queued but was waiting on the cortex a stuff to get sorted first16:05
jonmasonThat's also why I was messing with zephyr, as it's a good test bed16:05
RPjonmason: I've left that series as I don't think its right unfortunately :(16:05
RPif we make changes like that this late in the release I need to be convinced they're right and I'm not (I think I said as much) :/16:06
jonmasonI'm doing v3 now, I just keep getting pulled into other stuff.  It should be out today16:06
RPjonmason: ok16:07
jonmasonAnd if this needs to wait until after gatesgarth is released, that seems reasonable16:08
RPjonmason: If its just adding files we have a bit more flexibility, will depend on the changes16:09
jonmasonThen I'll take that into account and maybe do some of the organization in a follow-up series16:15
kergothHmm, I wonder if it'd be useful to create a recipetool or devtool command to take a specified .bb file and shove it into a temporary layer and build it there after adjusting priorities and verifying it'll be the selected provider, as an alternative to bitbake -b16:17
kergothcourse that assumes it's not in one already, so perhaps not16:18
ecdheis yocto sumo so old that I should be using something else?16:18
kergothjust thinking about quick and dirty work on a new recipetool-create'd recipe16:18
kergoth shows it was released on april 201816:18
kergothand has a current upstream support level of EOL16:18
ecdheA vendor shipped a bsp based on sumo in mid 201916:19
kergothbut it depends on your perspective, of course16:19
sgwRP: I am looking at something else regarding package.manifest creation, ideally a way to create a custom manifest.  I am thinking of 2 possibly ways, I am sure there are more.  1) bbclass that gets inherited or 2) extend the format_pkg_list() in lib/oe/ to take a custom ret_format and handle in there with getVar("TBD_CUSTOM_MANIFEST").  Thoughts?16:19
ecdheHow hard is it to upgrade?  I've never done it, but it looks like I might need to based on the fact that it can no longer pull source for stuff like htop and sudo16:19
RPsgw: I remember nothing about package manifests :/16:20
RPecdhe: have a read of the migration guides in the manual for thud and later ?16:20
RPIf you're just using standard yocto project its easier than a ton of BSPs and custom recipes16:21
ecdheRP, a board vendor shipped us a bsp based on sumo.  But I've got another board for which the vendor shipped buildroot.16:23
sgwRP: fair enough, I will dig around some and come up with a proposal, more about checking on creating interface that a bbclass could use vs have kind of script called from a variable to create the manifest16:23
RPecdhe: we can't know how hard that BSP will be to work with something more recent16:24
ecdheI wanted the new board to use yocto instead.  Since the new board's buildroot just downloads a U-Boot and kernel source tree and builds them, I cloned the first vendor's Sumo project and changed the git repos, defconfigs, device tree references etc, and have, for the most part, gotten yocto to execute the same basic build steps that buildroot was taking.16:25
ecdheRP: My build is failing at the moment because I can't acquire all the package source.16:25
RPecdhe: I'd probably have done something similar to that FWIW16:26
ecdheBut I'd really prefer to get my ported BSP fulling building on sumo before I migrate to a newer version16:26
RPecdhe: that would seem sensible16:26
ecdheSince I have the original sumo build environment (all 60 gigs) I might be interested in transplanting cached copies of the no-longer attainable source16:27
ecdheThen once I get a build I can migrate to Dunfell or so16:27
ecdheor even the pending October release16:28
RPecdhe: seems reasonable to me. dunfell is our LTS so I'd try and get to that at least16:29
*** pev <pev!> has quit IRC16:31
ecdheRP, my sumo build is failing saying it can't download
ecdheIf I find sudo-1.8.22.tar.gz in my old yocto workspace, do I just copy it to the same relative path in the new workspace?16:34
ecdheIt's in ./build/downloads/sudo-1.8.22.tar.gz16:35
ecdheor is there some other step that I'll need to take16:36
*** feddischson <feddischson!> has quit IRC16:36
*** manuel1985 <manuel1985!> has quit IRC16:36
RPecdhe: that will work. I'm surprised it doesn't find it from the yocto project mirrors16:37
qschulzRP: don't underestimate the power of badly written BSP layers and wrappers :)16:37
qschulzRP: I wouldn't be surprised if they replaced the mirrors with theirs or entirely removed them :)16:37
RPqschulz: I'm doing my best not to think too hard about it16:38
qschulzRP: hehehe, if that makes you sleep better :D16:38
qschulzecdhe: are you building on the same machine different Yocto projects? In that case, you can share the DL_DIR and SSTATE_DIR, it should be just fine (and if it isn't, scream at vendor)16:39
qschulzand not have to duplicate your download directory (and benefit from shared sstate cache dir :) )16:39
RPrburton: good news is that buildhistory on an image without my pseudo changes built in one builddir and one with the changes don't show any permissions issues. They do show pam differences :/16:40
*** mckoan is now known as mckoan|away16:42
RPJPEW: nice build corruption issue. PACKAGECONFIG_append_pn-shadow = " pam", bitbake shadow, remove that line, bitbake shadow, /etc/pam.d/* still present16:50
*** la_croix <la_croix!> has joined #yocto16:52
*** chris_ber <chris_ber!~quassel@> has quit IRC16:52
JPEWHmm, because ${D} isn't cleared out?16:56
*** kiwi_29 <kiwi_29!> has quit IRC16:57
qschulzjonmason: Reviewed-off-by? nice typo :D17:01
*** radsquirrel <radsquirrel!> has quit IRC17:02
rburtonRP: it does globbing in WORKDIR?17:02
RPrburton: yes, its clear when you read the recipe why it breaks17:02
RPits the second time recently I've seen this :(17:03
rburtonthat's a horrible thing to do17:03
RPI'm starting to think the fetcher shouldn't just dump files in WORKDIR17:03
JPEWRP: Oh, ya. That's a really gross way to do the recipe17:04
JPEWUsing PACKAGECONFIG in SRC_URI seems like a bit of a red flag17:05
RPI noticed a problem with the ssh pregen keys recipe where if you remove a file from the ssh sources directory, the file still ends up in the image :(17:05
RPits because the fetcher evidently doesn't/can't clean up WORKDIR17:06
RPthere SRC_URI = "file://sshdir/" so its a directory of files17:07
rburtonhm fun17:08
RPtwo issues are different but related :(17:09
rburtoni wonder how much will break if WORKDIR isn't actually the parent of S and friends17:11
rburtonie WORKDIR was /work/ alongside /temp/ and so on17:11
rburtonthen you could blast it away on re-fetch17:11
RPrburton: I think fetch just had to stop poking into WORKDIR. Maybe we mark recipes as "transitioned" with a flag that changes the fetcher behaviour?17:12
RPand then warn on the recipes which don't set it?17:12
*** kiwi_29 <kiwi_29!> has joined #yocto17:12
rburtonwhere would the fetcher put files otherwise?17:12
RPrburton: named directory configured by a variable? or just a common name?17:13
rburtoncall it WORKDIR and put it in /work/ ;)17:13
RP${WORKDIR}/fetched-files/ ?17:13
moto-timofor bug 13803, I noticed:17:14
moto-timoERROR: setUpModule (devtool) [ (subunit.RemotedTestCase)17:14
moto-timoWhat does the RemotedTestCase mean?17:14
RPmoto-timo: oe-selftest -j for parallelism17:14
RPmoto-timo: means subunit and testtools are proxing the test results over a pipe from multiple processes17:15
moto-timoRP: thanks. That might explain why I can't get the copytree (directory) target to work17:15
qschulzRP: ${WORKDIR}/oe-local-files ? that'd match what devtool is using :)17:15
RPqschulz: match an existing standard?! ;-)17:16
RPqschulz: seriously, thanks, I hadn't remembered it was doing that17:16
moto-timoI instrumented the heck out of the code, but it's only been passing in files shutil.copy2 mode and so even when I force copytree it's invalid17:16
moto-timook, I'll run with -j17:17
moto-timoor just send the patch17:17
qschulzRP: been bitten by it :D though... I hate how. We use SRC_URI = "file://oe-local-files.patch;patchdir=.." for patching files coming from upstream recipes....17:17
moto-timobut I'd rather see it working17:17
qschulzobviously this does not work with devtool putting the local files in a different "directory layout"17:18
qschulzRP: but honestly, +1 for putting files in a different dir than WORKDIR, it's super confusing17:19
*** kiwi_29 <kiwi_29!> has quit IRC17:20
qschulzRP: the issue is with recipes only having "file://"s where you'd actually have S = ${WORKDIR} and that wouldn't work. But that's pretty easy to error on since that wouldn't make any sense anymore17:21
qschulz(thinking out loud :) )17:21
*** radsquirrel <radsquirrel!> has joined #yocto17:34
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC17:39
*** kiwi_29 <kiwi_29!> has joined #yocto17:43
*** kpo_ <kpo_!> has quit IRC17:52
*** kpo_ <kpo_!> has joined #yocto17:53
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has quit IRC17:58
moto-timoat least the shutils.copytree is being called now, but it hasn't gotten to a test where __pycache__ would be copied yet. Getting close!18:05
*** radsquirrel <radsquirrel!> has quit IRC18:08
*** radsquirrel <radsquirrel!> has joined #yocto18:10
*** j241 <j241!> has joined #yocto18:14
*** WillMiles <WillMiles!~Will@> has quit IRC18:14
*** JonathanCrockett <JonathanCrockett!> has joined #yocto18:31
*** jrdn <jrdn!> has joined #yocto18:33
jrdnif devtool reset times out while trying to clean the sysroot how can I manually reset it?  I removed the workspace folder but devtool status still lists it as present18:34
ecdheRP: it built!  It built!18:48
ecdhenow, will it run?18:48
*** leon-anavi <leon-anavi!~Leon@> has quit IRC18:49
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto18:49
*** xtron <xtron!~xtron@> has quit IRC18:55
ecdheRP: eeeetts aliiiieeeeeve!!!!19:05
*** stephano <stephano!> has quit IRC19:28
jonmasonRP: just sent v2 out.  Hopefully it is more towards your liking :)19:30
RPecdhe: great!19:30
RPjonmason: thanks, will take a look19:30
*** kiwi_29 <kiwi_29!> has quit IRC19:34
*** sev_ <sev_!~sev@2003:a:12a:1300:8e16:45ff:fe1e:3785> has left #yocto19:34
*** kiwi_29 <kiwi_29!> has joined #yocto19:39
*** kiwi_29 <kiwi_29!> has quit IRC19:49
*** Ad0 <Ad0!~Ad0@> has quit IRC19:56
*** kiwi_29 <kiwi_29!> has joined #yocto19:57
*** Ad0 <Ad0!~Ad0@> has joined #yocto20:00
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto20:17
ecdheWithin a recipe that builds some C code, you might have serveral tasks, like do_fetch, do_configure, do_build, do_install, do_deploy.  Steps like fetch, build, install, deploy cause data to be copied/transformed from one domain/directory to another.20:28
*** pev <pev!> has joined #yocto20:29
ecdhein this situation, do_build ${S} => ${B}, do_install ${B} => ${D}, do_deploy ${B} => ${DEPLOY_DIR}20:29
ecdheWhat about when you're not building C code?  What if you're downloading a static file from a http server and putting it right into the deploy directory20:30
*** zkrx <zkrx!> has quit IRC20:31
ecdheThe do_fetch task would still bring the file from the remote webserver to ${S}20:31
ecdheBut in what task would you perform the ${S} => ${DEPLOY_DIR} copy?20:31
ecdheDoes it break convention too badly to have do_deploy() copy from ${S} instead of ${B}?20:32
*** zkrx <zkrx!> has joined #yocto20:35
*** zkrx <zkrx!> has quit IRC20:38
*** zkrx <zkrx!> has joined #yocto20:43
kergothecdhe: nothing wrong with that, plenty of recipes do it. a lot of upstream project buildsystems don't support a source vs build/object separation.20:43
*** manuel1985 <manuel1985!> has joined #yocto20:46
*** Konsgnx <Konsgnx!> has quit IRC21:01
*** berton <berton!~berton@> has quit IRC21:14
*** maudat <maudat!> has quit IRC21:16
*** kiwi_29 <kiwi_29!> has quit IRC21:19
*** kiwi_29 <kiwi_29!> has joined #yocto21:21
*** pohly <pohly!> has quit IRC21:26
ecdheThanks kergoth.  I just want to avoid making unmaintainable messes, and I haven't worked with yocto long enough to have an intuitive sense of smell for worst practices21:31
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC21:37
RPThe fun thing about testing do_unpack rm improvements is you break build directories quickly :(21:59
RPkergoth: think will work to fix do_unpack?22:10
*** ak77 <ak77!c12e4b03@> has quit IRC22:12
*** agust <agust!> has quit IRC22:15
*** kiwi_29 <kiwi_29!> has quit IRC22:40
pevdumb question : im trying to modify QB_OPT_APPEND in local.conf but can't see any changes taking effect when using "runqemu". Am I missing something obvious?22:45
*** kiwi_29 <kiwi_29!> has joined #yocto22:46
pevbitbake -e can determine its an extra operation when added but no change in value so I guess someone overwrites the value after local.conf is parsed. If so is there a "right" way to do this?22:46
kergothRP: seems reasonable. i'm assuming utils.remove() uses rm, not python? i'd have used pathlib personally, but that's personal preference, the concept is sound. the other thing i'd wonder is whether anyone is using prefuncs on do_unpack, as the order would change if that's the case. i doubt anyone is, though :)22:47
*** ericch <ericch!> has quit IRC22:48
*** rcw <rcw!~rcw@> has quit IRC22:58
*** kiwi_29 <kiwi_29!> has quit IRC23:10
*** nrossi1 <nrossi1!nrossimatr@gateway/shell/> has joined #yocto23:10
*** zbooth <zbooth!~zbooth@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto23:11
*** nrossi <nrossi!nrossimatr@gateway/shell/> has quit IRC23:13
*** zbooth- <zbooth-!~zbooth@2600:1f16:181:f300:d350:982:b6f5:216c> has quit IRC23:13
*** j241 <j241!> has quit IRC23:13
*** j241 <j241!> has joined #yocto23:14
*** JonathanCrockett <JonathanCrockett!> has quit IRC23:15
RPkergoth: I have found meson.bbclass is making some assumptions but that is easily fixed23:17
RPkergoth: utils.remove uses a mixture of things depending on what we've found is fastest23:17
RPkergoth: we have a different fun class of bug. Modify do_unpack and it will rerun but prepare_recipe_sysroot does not. It will however uninstall "bad" dependencies from the sysroot23:29

Generated by 2.17.2 by Marius Gedminas - find it at!