Friday, 2021-02-05

*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC00:04
*** kiwi_29 <kiwi_29!> has quit IRC00:04
*** goliath <goliath!> has quit IRC00:05
*** beneth <beneth!> has left #yocto00:05
*** ThomasD13 <ThomasD13!> has quit IRC00:24
*** ThomasD13 <ThomasD13!> has joined #yocto00:25
*** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has quit IRC00:38
*** abelal <abelal!~quassel@> has quit IRC00:39
*** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has joined #yocto00:40
*** abelal <abelal!~quassel@> has joined #yocto00:41
*** yann <yann!~yann@> has quit IRC00:41
*** yann <yann!~yann@> has joined #yocto00:49
*** bobo__ <bobo__!> has quit IRC01:00
*** bobo <bobo!> has quit IRC01:00
*** vmeson <vmeson!> has quit IRC01:02
*** Kyubi <Kyubi!> has joined #yocto01:06
*** kiwi_29 <kiwi_29!> has joined #yocto01:08
*** Kyubi <Kyubi!> has quit IRC01:08
*** kiwi_29 <kiwi_29!> has quit IRC01:11
*** vineela <vineela!~vtummala@> has quit IRC01:15
*** vmeson <vmeson!> has joined #yocto01:16
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto01:21
*** radsquirrel <radsquirrel!~radsquirr@2603:3015:e15:5bf2:d0b3:d9ff:fede:b022> has quit IRC01:28
*** dvhart <dvhart!~dvhart@> has quit IRC01:31
*** radsquirrel <radsquirrel!~radsquirr@2603:3015:e15:5bf2:d0b3:d9ff:fede:b022> has joined #yocto01:31
*** mccc <mccc!> has quit IRC01:31
*** Agent13 <Agent13!> has quit IRC01:32
*** mccc <mccc!> has joined #yocto01:33
*** dvhart <dvhart!~dvhart@> has joined #yocto01:38
*** manuel_ <manuel_!> has quit IRC02:02
*** dvhart <dvhart!~dvhart@> has quit IRC02:02
*** Wouter01000 <Wouter01000!> has quit IRC02:05
*** Wouter01000 <Wouter01000!> has joined #yocto02:05
*** kiwi_29 <kiwi_29!> has joined #yocto02:16
*** kiwi_29 <kiwi_29!> has quit IRC02:20
*** ahadi <ahadi!~ahadi@> has quit IRC02:29
*** ahadi <ahadi!~ahadi@> has joined #yocto02:30
*** kpo__ <kpo__!> has quit IRC02:40
*** kpo__ <kpo__!> has joined #yocto02:41
*** Kyubi <Kyubi!~Kyubi@> has quit IRC02:44
*** tgoodwin <tgoodwin!> has quit IRC02:45
*** dev1990 <dev1990!> has joined #yocto02:46
*** kiwi_29 <kiwi_29!> has joined #yocto02:46
*** kiwi_29 <kiwi_29!> has quit IRC02:52
*** aquijoule__ <aquijoule__!> has joined #yocto03:01
*** aquijoule_ <aquijoule_!> has quit IRC03:04
*** ahadi <ahadi!~ahadi@> has quit IRC03:05
*** kiwi_29 <kiwi_29!> has joined #yocto03:06
*** ahadi <ahadi!> has joined #yocto03:06
*** sakoman <sakoman!~steve@> has quit IRC03:07
*** kiwi_29 <kiwi_29!> has quit IRC03:09
*** Minjae_Kim <Minjae_Kim!1b7af247@gateway/web/cgi-irc/> has quit IRC03:57
*** Kyubi <Kyubi!> has joined #yocto03:57
*** Minjae_Kim <Minjae_Kim!1b7af247@gateway/web/cgi-irc/> has joined #yocto03:58
*** Kyubi <Kyubi!> has quit IRC04:02
*** ahadi <ahadi!> has quit IRC04:02
*** ahadi <ahadi!> has joined #yocto04:03
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto04:11
*** mccc <mccc!> has quit IRC04:23
*** mccc <mccc!> has joined #yocto04:23
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC04:25
*** fatalhalt <fatalhalt!> has joined #yocto04:26
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto04:47
*** kiwi_29 <kiwi_29!> has joined #yocto05:10
*** kiwi_29 <kiwi_29!> has quit IRC05:15
*** feddischson <feddischson!> has joined #yocto05:59
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC06:04
*** dvhart <dvhart!~dvhart@> has joined #yocto06:04
*** dvhart <dvhart!~dvhart@> has quit IRC06:07
*** jobroe <jobroe!> has joined #yocto06:11
*** beneth <beneth!> has joined #yocto06:15
*** Kyubi <Kyubi!~Kyubi@> has quit IRC06:27
*** AndersD <AndersD!> has joined #yocto06:29
*** alessioigor <alessioigor!> has joined #yocto06:33
*** alessioigor <alessioigor!> has quit IRC06:33
*** minimaxwell <minimaxwell!> has joined #yocto06:49
*** rcoote <rcoote!~rcoote@> has joined #yocto06:50
*** minimaxw1ll <minimaxw1ll!> has joined #yocto06:53
*** minimaxwell <minimaxwell!> has quit IRC06:55
*** minimaxw1ll is now known as minimaxwell06:55
*** kpo__ <kpo__!> has quit IRC06:58
*** kpo__ <kpo__!> has joined #yocto06:59
*** bobo <bobo!> has joined #yocto07:06
*** bobo__ <bobo__!> has joined #yocto07:11
*** RobertBerger <RobertBerger!> has joined #yocto07:30
*** thekappe <thekappe!c65a42b1@> has joined #yocto07:37
thekappeHello guys ! In my kernel recipe folder I have two subfolders: files (with patches) and configs (with .cfg), how can I add both of them to FILESEXTRAPATHS_prepend ?07:38
*** mckoan|away is now known as mckoan07:39
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:42
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:49
LetoThe2ndyo dudX07:50
*** w00die <w00die!~w00die@> has quit IRC07:51
*** w00die <w00die!~w00die@> has joined #yocto07:53
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:54
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:55
*** bobo <bobo!> has quit IRC07:56
mckoanhi LetoThe2nd07:56
LetoThe2ndhowdy mckoan07:56
*** bobo__ <bobo__!> has quit IRC07:56
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC07:57
*** elGamal <elGamal!> has joined #yocto07:57
*** manuel_ <manuel_!> has joined #yocto07:58
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto08:04
*** goliath <goliath!> has joined #yocto08:09
*** dvorkindmitry <dvorkindmitry!~dv@> has joined #yocto08:11
*** manuel_ <manuel_!> has quit IRC08:11
*** imaami <imaami!> has quit IRC08:13
*** imaami <imaami!> has joined #yocto08:13
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto08:15
*** rperier_ is now known as rperier08:16
*** rperier <rperier!> has quit IRC08:16
*** rperier <rperier!~quassel@unaffiliated/bambee> has joined #yocto08:16
RPthekappe: add each one separated by a ":" ?08:17
thekappeRP, thanks !08:18
*** B0ned1ger <B0ned1ger!> has quit IRC08:18
dvorkindmitryis there -native recipe example? can't find the good one.08:21
LetoThe2nddvorkindmitry: one that is explicitly -native, or one that is native enabled?08:26
dvorkindmitryLetoThe2nd, I don't really know. I need the script from recipe A to be used while building recipe B binary.08:28
LetoThe2nddvorkindmitry: if A is technically also buildable for the target, then its probably enough to jsut add BBCLASSEXTEND = "native".08:29
LetoThe2nddvorkindmitry: look at bc, for example.08:29
*** elGamal <elGamal!> has quit IRC08:30
*** lpoulain| is now known as lpoulain08:30
dvorkindmitryLetoThe2nd, I added BBCLASSEXTEND = "native" to recipe A. But I can't find the script installed into {D} from recipe A do_install() in the work directories of recipe B.08:31
LetoThe2nddvorkindmitry: well did you add DEPENDS = "A-native"?08:31
dvorkindmitryLetoThe2nd, I did08:32
dvorkindmitryI have no FILES... section in recipe A, but it doesn't give me any error messages and looks like it doesn't do packaging!08:33
dvorkindmitryit does ... install and deploy (used in DEPLOYdir too). no packaging. I suspect, I forgot to add some property to the A recipe08:35
LetoThe2ndi would try cleaning A-native, rebuild B and see what happens. if nothing shows up then you have to dig deeper, yes.08:35
dvorkindmitryI already did. No effect08:36
dvorkindmitryrecipe B rally depends on A, A looks instaled. But no files from it in B recipe dirs08:36
LetoThe2nddvorkindmitry: ah. they should not show up in the recipe dir, but in the sysroots that B uses. you hopefully looked in the right places?08:37
dvorkindmitryI did find <recipeAdir> -name "filenamefromB" - nothing08:40
dvorkindmitrysorry, vise-versa... :)08:41
dvorkindmitrywhat looks suspitious for me is that I have do_install() { install myscript } and have image/...myscript, but no packaging dir for this A recipe08:42
LetoThe2ndwithout seeing the recipe i personally can't guess more, sorry. others probably can, but its beyond my knowledge.08:43
rburtondvorkindmitry: you can see what the recipe installed to the sysroot by looking in tmp/sysroot-components/(host arch)/A-native/08:47
*** thekappe <thekappe!c65a42b1@> has quit IRC08:48
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:52
*** bps <bps!~bps@> has joined #yocto08:56
*** JaMa <JaMa!> has quit IRC09:04
*** JaMa <JaMa!> has joined #yocto09:04
rburtonkhem: do you plan on merging my meta-py fixes? our CI is broken.09:09
rburtonhm i forgot to [meta-python] tag them09:09
*** rcoote <rcoote!~rcoote@> has quit IRC09:10
*** gpanders <gpanders!> has quit IRC09:10
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:d544:4576:4fb6:d14> has joined #yocto09:11
*** bps <bps!~bps@> has quit IRC09:12
*** bps <bps!~bps@> has joined #yocto09:12
*** jobroe <jobroe!> has quit IRC09:13
*** gpanders <gpanders!> has joined #yocto09:14
*** jobroe <jobroe!> has joined #yocto09:14
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:18
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:d544:4576:4fb6:d14> has quit IRC09:20
qschulzdvorkindmitry: not sure there's packaging for native recipes?09:27
*** yizhao <yizhao!~zhaoyi@> has joined #yocto09:27
*** polaris <polaris!> has joined #yocto09:39
*** sTKs <sTKs!~weechat@2001:818:e634:e700:81cb:5262:bdd:4b02> has joined #yocto09:44
*** B0ned1ger2 <B0ned1ger2!> has quit IRC09:53
*** B0ned1ger <B0ned1ger!> has joined #yocto09:53
marexHi, there is one thing I am curious about09:54
marexif I track kernel patches in a metalayer09:54
marexassume I have foo-patches.scc which lists the patchset and then matching patches in the same directory, 000*-whatever.patch09:55
marexnow, a new kernel version is rolled out, I generate those patches with git format-patch09:55
marexI end up with a diff full of +- lines for From with a different hash, possibly Subject where [PATCH nn/mm] is modified, and also some index ... entries09:56
marexI wonder, is there a tool to scrub those useless changes to clean up the sync diff ?09:56
RPmarex: hard part is deciding which bits are useless09:57
marexRP: the patch context is generally useless, since its text unrelated to the patch content09:58
marexright ?09:58
RPmarex: it has a use in that it helps the system understand where the patch content needs to go. Its noise in that it obscures what you happen to want in this case.09:59
marexRP: I mean things like 'From b7cefab79b977ec289a3254b1f5135af6e98d4da Mon Sep 17 00:00:00 2001'10:00
marexthat is just noise and doesnt help anything, really10:00
RPmarex: is there something in diffutills which would strip things down to bare patches?10:00
RPmarex: git adds these things as it can help it apply the patches under some circumstances10:01
marexRP: I was looking for such a thing for a while, I can't seem to find anything10:01
marexI guess I can somehow tweak git config to generate patches without some of that stuff, or filter it manually with sed10:02
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC10:05
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto10:06
*** oberstet <oberstet!~oberstet@> has joined #yocto10:11
*** wooosaiiii <wooosaiiii!> has quit IRC10:31
*** bps <bps!~bps@> has quit IRC10:39
*** Bunio_FH <Bunio_FH!> has quit IRC10:41
*** Bunio_FH <Bunio_FH!> has joined #yocto10:42
*** dreyna <dreyna!> has quit IRC10:50
*** Anarky <Anarky!> has joined #yocto10:57
*** bps <bps!~bps@> has joined #yocto11:03
*** Bunio_FH <Bunio_FH!> has quit IRC11:12
*** Bunio_FH <Bunio_FH!> has joined #yocto11:19
qschulzis there a way to get a sysroot of one recipe with all debug symbols (basically all -dbg packages of everything in DEPENDS of said recipe)?11:22
RPqschulz: the debug info is only packaged, not put into sysroots so you'd need an image recipe with debug image enabled installing that one recipe11:26
rburtonyou can turn off stripping of the sysroot if you really need it though11:31
rburtonwhen i was digging at pseudo I had INHIBIT_SYSROOT_STRIP_pn-pseudo-native = "1"11:32
rburtonsounds like what you want is a debug image though, generated like an image but with all symbols for gdb to ues11:33
*** ThomasD13 <ThomasD13!> has quit IRC11:33
rburtonor, the debuginfod stuff dorinda is working on :)11:33
RPthe debug image is the fastest way I know of to get it with the existing code11:34
qschulzrburton: this INHIBIT_SYSROOT_STRIP_pn-pseudo-native applies to sysroot-destdir dir of pseudo-native right?11:38
RPqschulz: yes11:41
qschulzok so that's not really what I wanted but that is interesting to know. (in the end we went for a debug image enabled "rootfs")11:46
rburtonoh new uboot11:47
rburtonmarex: any plans to upgrade uboot in oe-core?11:49
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC11:54
*** lxc <lxc!> has joined #yocto11:55
lxchow to specify a dependency to a native compiler? DEPENDS = "gcc-native"?11:55
rburtonthe native compiler is assumed to exist11:57
rburton(on the host)11:58
RPhmm, one ltp run on the arm server 3.75 hours, the other was nearly 7 :/11:59
* RP is going to merge glibc 2.33, looks like it builds cleanly12:00
RPjonmason: I reran the failing ltps and they went green FWIW12:03
*** kpo__ <kpo__!> has quit IRC12:03
*** kpo__ <kpo__!> has joined #yocto12:04
jonmasonCool, so it's not occuring every time12:04
marexrburton: doesnt AUH do that ?12:04
rburtonmarex: uboot is on my list of things that should likely be tested before pushing :)12:05
marexrburton: tested in what way ? :)12:05
marexrburton: I am running it on the boards I care about already12:05
marexrburton: switching the SRC_URI is enough12:06
rburtonmarex: can you send the patch :)12:06
marexrburton: doesnt AUH do that ?12:06
marexI was hoping this automation should do it12:06
RPmarex: the AUH can prepare the patches but we do ask that a human does check and confirm its a good idea12:07
RPmarex: you can replicate the work of the AUH by using devtool upgrade locally iirc12:07
marexRP: ah, was the patch posted ?12:08
*** manuel_ <manuel_!> has joined #yocto12:10
*** lxc <lxc!> has quit IRC12:11
marexRP: rburton: btw Im tracking a local layer with linux 5.10.y and mesa 20.3.y for dunfell here, is there some better place to put it, so its useful for others that want LTS version of core, but more up to date kernel and graphics stack ?12:20
*** tgoodwin <tgoodwin!> has joined #yocto12:21
JaMaanyone noticed icu build failing in dunfell like this?12:24
JaMa../data/ recipe for target 'out/build/icudt66l/windowsZones.res' failed12:24
JaMamake[1]: *** [out/build/icudt66l/windowsZones.res] Segmentation fault12:24
JaMasometimes there is "Bus error" instead of segmentation fault12:24
marexJaMa: I am just building it, in previous builds I didnt see it12:31
marexJaMa: could it be HW error on the build box ?12:31
JaMait might, but I'm seeing it only in icu (3 times since last dunfell update yesterday)12:32
marexJaMa: is that native or target build ?12:33
JaMaseen it for qemuarm and rpi412:33
RPmarex: poky-contrib under stable/<something> ?12:34
marexJaMa: I'm just building arm32, so lets see12:34
RPJaMa: not seen that12:34
JaMabut it's relatively rare as it failed 3 times in 100+ builds here and I haven't reproduced it locally yet (only on jenkins)12:34
marexRP: meta-stable ? :)12:35
RPmarex: absolutely not12:35
marexhehehe :-)12:38
marexRP: in fact, I have to wonder, is there still any need for linux-yocto ? wouldn't it make more sense to just pull plain linux-stable ?12:39
RPmarex: that somewhat undervalues the work that goes into testing and maintaining the config data and patches in linux-yocto12:42
JaMaRP: looks like posix format will be the default in newer tar versions, but the docs also say "This format is quite recent, so not all tar implementations are able to handle it properly." so maybe the centos7 might still handle it differently :/12:44
marexRP: cant those extras be applied on linux-stable all the same ?12:45
RPpaulbarker: thanks12:46
paulbarkermarex: linux-yocto is better tested but if you want a vanilla kernel and are happy to do any necessary testing yourself then that layer may save you the time of maintaining the recipes12:47
paulbarkermarex: Let's chat after FOSDEM, perhaps we can consolidate those layers12:48
paulbarkerI'm a bit too busy today and this weekend but after that will have a look around that layer12:49
marexpaulbarker: ideally into something which gets updated often12:49
marexand automatically12:49
marexpaulbarker: I have my own update script too12:49
RPI have talked about getting linux-yocto-dev running on the autobuilder fwiw12:50
RPJaMa: that sounds problematic :(12:51
paulbarkerRP: Unless we want to carry linux-yocto recipes for everything as far back as 4.4.y then I don't think it'll address what I need12:51
paulbarkerDefinitely helpful to have that tested on the AB though, don't get me wrong12:52
RPJaMa: I guess we need to establish if centos7 tar supports posix archives12:52
marexpaulbarker: if we can put some linux-stable into poky-contrib and keep it updated as soon as new version is out, great12:52
marexthat should be possible to automate with auh12:52
RPpaulbarker: right, it won't solve every need but for cutting edge it might help some cases12:52
paulbarkermarex: poky-contrib is absolutely not the place to put this, it needs to be a layer we can add12:52
manuel_Is anyone building with yocto on Alpine Linux?12:52
RPpaulbarker: I want to get better about handling upstream changes more quickly12:53
paulbarkermanuel_: I tried building on Alpine once but had various issues with musl incompatibilities12:53
marexRP: dont we already have devupstream bbclass for that ?12:53
manuel_paulbarker: I see, thanks. Would love to see Crops be based on Alpine instead ?Ubuntu?. :)12:54
paulbarkermanuel_: I don't understand your question there sorry. CROPS needs to use a distro which we know can handle Yocto Project builds12:54
marexpaulbarker: if we can keep in maintained, separate layer is fine12:55
paulbarkermarex: My limiting factor is a machine to do CI builds on. I should have that addressed within a month or so and then will be able to fully automate updating & test building the layer12:55
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto12:56
*** leonanavi <leonanavi!~Leon@> has joined #yocto12:56
*** leon-anavi <leon-anavi!~Leon@> has quit IRC12:56
manuel_paulbarker: Yes, having Yocto projects build successfully on Alpine would of course be a requirement for basing CROPS on Alpine.12:57
marexpaulbarker: lets revisit that later12:58
paulbarkermarex: Sounds like a good plan12:58
*** B0ned1ger <B0ned1ger!> has quit IRC12:59
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto13:00
RPmarex: that only works to a point but yes, it could be part of it13:01
*** polaris <polaris!> has quit IRC13:06
*** lxc <lxc!> has joined #yocto13:19
lxcwhen I run devtool I get the following;13:19
lxcException: ModuleNotFoundError: No module named '_sysconfigdata'13:19
*** sakoman <sakoman!~steve@> has joined #yocto13:29
*** SmutLord^ <SmutLord^!extor@unaffiliated/extor> has quit IRC13:38
*** SmutLord^ <SmutLord^!extor@unaffiliated/extor> has joined #yocto13:38
JaMalxc: it's known issue already fixed in newer oe, I assume you used dunfell, see the patches on ML13:48
JaMaRP: I'll try with some container/VM with centos713:49
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC13:54
*** warthog9 <warthog9!> has quit IRC14:15
*** GeneralStupid <GeneralStupid!> has joined #yocto14:23
GeneralStupidHi, i recently installed the avahi-daemon on my yocto package. It is not starting automatically via systemd (startup fails) if i try it manually i get fcntl(F_SETLKW) failed: Permission denied14:25
*** frsc <frsc!> has joined #yocto14:28
*** mbulut <mbulut!> has joined #yocto14:35
dvorkindmitryI gave up trying to understand why this recipe A required for build recipe B does not install anything into B's root:
JPEWpaulbarker: The patches all look good except for the logging one which breaks the standalone bitbake server14:37
lxcJaMa yes running dunfell.14:39
paulbarkerJPEW: I get backtraces without that patch so something is wrong14:40
rburtondvorkindmitry: why are you manually deploying?14:40
dvorkindmitryrburton, what you mean "manually" ?14:41
dvorkindmitryis there are something that could be ommited?14:42
rburtonwhy do you have a do_deploy at all14:42
*** lxc <lxc!> has quit IRC14:42
dvorkindmitryrburton, case I need exact directory structure. some installed cripts rely on relative paths14:43
RPpaulbarker, JPEW: sounds like in one case we get the python logger, in the other its a bitbake logger where debug is different14:44
*** mbulut <mbulut!> has quit IRC14:46
*** lxc <lxc!> has joined #yocto14:49
*** mbulut <mbulut!> has joined #yocto14:50
JPEWRP: Ya... it's a bit unfortunate that bitbake overrides logging.debug with a different signature :/14:50
lxccan bitbake deploy a recipe on target with scp? or am I required to use devtool?14:50
*** mbulut <mbulut!> has quit IRC14:50
*** Guest14662 <Guest14662!> has joined #yocto14:53
dvorkindmitryrburton, so... do you have any ideas? I have rA/image/sp_tools/ file, but this file is not installed into rB/* during the recipe B build process. Although I have DEPENDS += "A-native" in recipe B14:54
GeneralStupidlxc: you usually flash that image, e.g. you could use rauc for update14:54
JaMaRP: marex: the icu failure seems to be related to from rburton :)14:55
lxcIn devtool I can do this;14:55
lxcdevtool deploy-target <recipe> <target>14:55
lxcIs there something similar in bitbake? Or I need to use devtool as frontend to bitbake?14:55
GeneralStupidlxc:  you can create a custom image via bitbake recipe. One which is predefined (i guess?) is core-image-basic15:01
lxcI know how to create image. I am running an image on target, and during development want to upgrade a certain package.15:01
*** Guest14662 <Guest14662!> has quit IRC15:01
GeneralStupidlxc: ah i see. afaik you could create an rpm file of that application15:02
lxcok, but that require me to have the package manager as well then15:03
GeneralStupidi compile the application(s) with the generated SDK and use scp. But i deploy images on my jenkins after merging15:03
GeneralStupidlxc: exactly... I want that... But i want to get other stuff working first :)15:03
GeneralStupidlxc: iam planning to put FPGA bitstreams in a package, to be able to upgrade it simply via rpm... But i dont have a connection for it right now...15:05
*** dlan <dlan!~dennis@> has joined #yocto15:07
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto15:07
*** RobertBerger <RobertBerger!> has quit IRC15:07
qschulzdvorkindmitry: your script is not part of SYSROOTDIRS15:09
qschulzand I'm guessing you want this script to be run at build time and not runtime, then you need a native recipe which is installing this script and in recipe B have DEPENDS = "A-native"15:10
qschulzwell, technically on your case it'll be SYSROOT_DIRS_NATIVE but still your script won't be part of it15:11
qschulz(ah, forgot to read your message to rburton, so you got the native part right already)15:11
qschulzdvorkindmitry: your justification for using do_deploy is still dubiuous, care to explain a bit more why you need so many files in your deploydir?15:12
dvorkindmitryqschulz, so you mean I just have to install into traditional dir, like /usr/... or something?15:12
qschulzdvorkindmitry: that, or add your path to SYSROOT_DIRS_NATIVE15:12
dvorkindmitryqschulz, the scripts are written by another company, they are using it in they projects. some of them are Too much related to relative pathes. Instead of making patches for all this scripts (that is updated from time to time) I prefer to keep directory structure15:14
*** mbulut <mbulut!> has joined #yocto15:14
*** B0ned1ger2 <B0ned1ger2!> has quit IRC15:19
GeneralStupidDo i have to take another avahi-deamon package if i use systemd?15:20
dvorkindmitryqschulz, may I add my special dir into SYSROOT_DIRS_NATIVE directly in the recipe?15:29
zeddiianyone else seeing the latest binutils bump in master inexplicably not find bison during the binutils-cross build ?15:30
* zeddii tries to hack it15:30
*** dvhart <dvhart!~dvhart@> has joined #yocto15:37
*** mbulut <mbulut!> has joined #yocto15:38
*** gnac <gnac!> has quit IRC15:40
*** dvhart <dvhart!~dvhart@> has quit IRC15:45
*** dvhart <dvhart!~dvhart@> has joined #yocto15:47
*** warthog9 <warthog9!> has joined #yocto15:48
*** AndersD <AndersD!> has quit IRC15:50
RPzeddii: I did not see that15:51
zeddiiRP: yah, it has to be my re-used tmp/build somehow, since obviously it wouldn't be in master if it was triggering everywhere.15:53
zeddiibut I've now cleanalled on everything I can think of, and just keep hitting15:53
zeddiibison-native is in the depends, but when I search the recipe sysroot, it isn't in the native dirs, so something is off the rails. I'll rm -rf and see if that helps15:54
RPzeddii: you could have tried a bitbake bison-native binutils-cross-XXX -c clean15:54
zeddiidid that, but actually, I didn't do the binutils-cross-x86_64 clean in my case, so I just tried that before the rm -rf15:55
zeddiiwill see what bison-cross thinks of that!15:55
zeddii(I just did the cleanall on binutils-cross, didn't realize the variant)15:56
RPzeddii: binutils-cross would just error wouldn't it?15:57
zeddiiyah, according to my history, was just binutils I did the cleanall. must be monday.15:59
JPEWRP, paulbarker: We probably need to do a global find-and-replace to change all the places using the bitbake style logger.debug to logger.bbdebug (or similar)?15:59
*** leonanavi <leonanavi!~Leon@> has quit IRC16:02
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto16:02
qschulzdvorkindmitry: yes, in the recipe16:02
qschulzGeneralStupid: work out the permission issue first, it's probably just that that is the issue16:03
RPJPEW: that is going to be a lot of sites I suspect :(16:05
RPJPEW: also, probably better to add a debug2 and then change all the debug(1, to debug(16:06
*** mbulut <mbulut!> has quit IRC16:08
JPEWRP: Ya, that works16:08
*** minimaxwell <minimaxwell!> has quit IRC16:11
JPEWLooks like about 244 locations16:20
RPJPEW: have you a second to sanity check my logic with something in bitbake?16:23
RPJPEW: I'm trying to understand - it shows two events being printed at once to a pipe <event>partial data<event>more full data</event>16:27
RPJPEW: code is in bit/bitbake-worker16:28
RPJPEW: its hard to read as there are two queues, the one where the worker passes to the server and the one where the worker children pass to the worker16:28
JPEWworker_fire() and worker_child_fire() ?16:29
RPJPEW: right16:29
RPJPEW: I'm struggling to spot where the race is happening though16:29
* JPEW reads16:31
JPEWRp: So, if I read correctly, the default behavior is to push data to a queue and a background thread will write it to the pipe16:33
RPJPEW: in the worker parent, yes16:34
JPEWAnd when a task is forked off, it changes to directly write to the pipe from the child process?16:34
JPEWAh, a new pipe setup between the parent and the child16:35
*** extorr <extorr!extor@unaffiliated/extor> has joined #yocto16:35
RPJPEW: yes, a new pipe is setup between the child and the parent16:36
RPJPEW: I am noticing that the parent pipes to other children are not closed in new children16:36
*** leon-anavi <leon-anavi!~Leon@> has quit IRC16:36
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto16:36
*** SmutLord^ <SmutLord^!extor@unaffiliated/extor> has quit IRC16:37
*** bps <bps!~bps@> has quit IRC16:37
JPEWOk, an the the parent(?) selects() on all the child pipes and forwards the events through it's pipe?16:38
RPJPEW: yes16:39
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC16:39
JPEWSo is the un-pickling error in the the child, the worker process, or the worker's parent?16:39
RPJPEW: the error message matches the line in runqueue so in the server16:43
RPbb.msg.fatal("RunQueue", "failed load pickle '%s': '%s'" % (e, self.queue[7:index]))16:43
RPJPEW: i.e. worker's parent16:44
*** mbulut <mbulut!> has joined #yocto16:46
JPEWHmm, the parent uses stdout as the pipe?16:50
JPEWErr, sorry the *worker* uses stdout as the pipe16:50
RPJPEW: yes :/16:51
RPJPEW: whilst that has its risks, the logs look like multiple <event></event> colliding :/16:52
*** boucman_work <boucman_work!~boucman@wesnoth/developer/boucman> has joined #yocto16:53
JPEWRP: Ya, for sure. Is there any indication in where those events would be originating from (e.g. child or worker?)16:53
boucman_workHello everybody16:53
RPJPEW: they look child to me but they could be being sent on from the worker's queue or the child16:54
boucman_workIs there an easy way, given a package name, to know where the corresponding package is (i.e the .rpm/.deb/.ipk file ?16:54
boucman_workextending PV etc for me16:54
boucman_work(I want to use it in image-recipe context, so it can be a python call)16:54
*** bobo <bobo!> has joined #yocto16:54
*** bobo__ <bobo__!> has joined #yocto16:54
JPEWRP: How reproducible is this?16:55
RPJPEW: not very but has happened on several ltp builds recently16:55
RPJPEW: I don't understand what is happening :(16:55
JPEWI don't either but we can probably narrow it down a little16:55
JPEWIf we put some sanity code in the runQueueWorkerPipe() to make sure the "prepickled" message from the child has one and only one "<event>" at the beginning of the string it would narrow it down16:56
tlwoernerlxc: yes use devtool deploy-target16:57
RPJPEW: that sounds reasonable16:58
tlwoernerlxc: devtool deploy-target pushes whatever it finds in $TMPDIR/work/<something>/<recipe>/<version>/image to the target for a given recipe16:59
*** mckoan is now known as mckoan|away16:59
tlwoernerand it's smart enough to keep track of what was pushed "the last time" so it can know what to unload before the next "devtool deploy-target" or "devtool undeploy-target"17:00
JPEWRP: something like: assert msg.startswith("<event>") and msg.count("<event>") == 117:00
tlwoernerlxc: so it's like building a package, scp'ing the package to the target, and installing the package… but without having to go through the package mgmt system (and it's smart enough to know how to uninstall too)17:01
tlwoernerlxc: see perhaps?17:02
*** vineela <vineela!~vtummala@> has joined #yocto17:02
tlwoernerlxc: the only downside with "devtool deploy-target" is that it installs *everything* in <recipe>/…/image, including documentation etc17:03
RPJPEW: right, that makes sense17:03
RPJPEW: fwiw one of the call sites triggering this is meta/lib/oeqa/core/target/, the logger.debug('Partial data from SSH call...)17:04
*** paul__ <paul__!> has quit IRC17:07
JPEWHmm, could be a CLOEXEC error17:09
RPJPEW: I just found the other message is coming from make_logger_bitbake_compatible in lib/oeqa/utils/__init__ which seems apt given the discussion earlier17:12
JPEWErr, ya... how fun!17:13
*** mbulut <mbulut!> has quit IRC17:14
RPJPEW: the other message it was colliding with is                 logger.debug('time: %s, endtime: %s' % (time.time(), endtime)) from a few lines above the Partial data line17:16
JPEWRP: Would that be in the child process>?17:17
RPJPEW: Yes, these would be in the child. Given they're in the same function and logically follow each other it probably rules out a few things too17:18
*** w00die <w00die!~w00die@> has quit IRC17:19
*** Kyubi <Kyubi!> has joined #yocto17:20
*** w00die <w00die!~w00die@> has joined #yocto17:20
JaMaRP: I'm testing the tar in centos7 and I think autobuilder is already using different tar implementation, isn't it? Because with the default tar 1.26 (included in centos:centos7 docker image) it fails with tar: unrecognized option '--sort=name'17:20
*** Kyubi <Kyubi!> has quit IRC17:21
RPJaMa: ah. Then what did I test with? :/17:22
* JPEW gets some food17:23
*** bps <bps!~bps@> has joined #yocto17:23
JPEWRP: I wonder if the InterruptedError is interrupting the write to the pipe17:24
RPJPEW: would having an exception handler there change the behaviour of a write call. Surely the write() calls autoretry?17:29
JaMa from rburton also says "We now depend on tar 1.28, so talking about older tar versions is just confusing." so maybe it's already upgraded on centos7 builder somehow17:31
JPEWRP: Ah, but it *can't* if it's already partially written17:32
JPEW*written some of the data17:33
RPJaMa: centos7 uses buildtools17:33
JPEWIt has to just return with how much has been written17:33
RPJaMa: I'm now very puzzled as to how I came across the issue though17:33
JPEWworker_child_fire() needs to loop to make sure all the data gets written, even though it's non -blocking17:33
JPEWErr, blocking17:33
JPEWBecause you can get a short write on a pipe even with a blocking FD, if you had a partial write and then a signal occurred17:34
RPJPEW: ah, right. If it can make short writes, that would explain it17:34
RPJPEW: well deduced :)17:34
JaMaRP: me too :)17:35
JPEWWhich, is a lot more likely to happen when running the LTP test on QEMU and the system because of a lot of output CPU load making the pipe more likely to fill(?)17:35
RPJaMa: do you know which version of tar changed the default format?17:36
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto17:38
*** boucman_work <boucman_work!~boucman@wesnoth/developer/boucman> has quit IRC17:38
RPJaMa: is there a way to see which format tar is using by default? I just checked and I did also test what I was working on with a tumbleweed autobuilder worker17:38
RPwhich has tar 1.3217:38
RPJPEW: the ltp tests do seem to chuck more data around17:39
JPEWRP: Cool, I bet that's it. Probably still worth having the sanity check17:39
RPJPEW: you never see python .write() calls checking length or a retry write() loop or helper17:41
RPJPEW: I guess you don't see fdopen used much17:46
JPEWRP: Ya. I don't think signal come up much either... most are fatal by default anyway17:47
JPEWI'll write a little PoC after lunch17:48
*** bps <bps!~bps@> has quit IRC17:49
JaMaRP: the default is still gnu (since long time), the default wasn't changed to posix even in 20.10 ubuntu yet, the build-time configured default is shown at the end of tar --help17:50
JaMa20.10 ubuntu is still on 1.30, so 1.32 in tumbleweed might already have posix17:51
*** Agent13 <Agent13!> has joined #yocto17:53
*** vineela <vineela!~vtummala@> has quit IRC17:54
RPJaMa: that might be how we got here17:54
RPJaMa: sorry for the misinformation, I could have sworn I used centos717:54
*** vineela <vineela!~vtummala@> has joined #yocto17:55
RPJPEW: :)17:58
JaMaRP: so can I try to submit change from gnu to posix? I already have a patch18:02
JaMaI'm checking the default in tumbeweed docker18:02
RPJaMa: which version of tar added posix support?18:03
*** boucman <boucman!~boucman@wesnoth/developer/boucman> has joined #yocto18:04
JaMait was already in 1.26 in centos7, only the --sort=name was missing18:04
RPJaMa: ok, in that case we're good18:04
RPJaMa: we should be able to change it18:04
*** vineela <vineela!~vtummala@> has quit IRC18:10
RPjonmason: need to get ross to fix that esdk2 error that happened again on meta-arm ;-)18:14
*** dvhart <dvhart!~dvhart@> has quit IRC18:19
*** dvhart <dvhart!~dvhart@> has joined #yocto18:20
jonmasonedk2 is such a PITA18:20
jonmasoneven worse, we never see issues when compiling in our CI18:21
Agent13Anyone here a devtools user/guru?18:23
*** luis__ <luis__!~luis@2001:8a0:dddc:7a00:94f:964e:8139:1489> has joined #yocto18:27
*** dreyna <dreyna!> has joined #yocto18:27
*** luis__ <luis__!~luis@2001:8a0:dddc:7a00:94f:964e:8139:1489> has quit IRC18:28
*** dreyna <dreyna!> has quit IRC18:29
*** dreyna <dreyna!> has joined #yocto18:29
*** kiwi_29 <kiwi_29!> has joined #yocto18:31
*** bps <bps!~bps@> has joined #yocto18:31
*** aleblanc <aleblanc!> has joined #yocto18:36
*** bps <bps!~bps@> has quit IRC18:37
*** yizhao1 <yizhao1!> has joined #yocto18:41
jordemortdon't know if this is the best place to ask or if i should find a freescale-specific place, but i'm trying to change my UBOOT_CONFIG to "nand" as seen in and u-boot is failing to build because it can't find "mx7dsabresd_nand_config" - which seems understandable, because i can't find it or anything that appears to generate it in the18:43
jordemorttree either18:43
*** yizhao <yizhao!~zhaoyi@> has quit IRC18:43
jordemortneither in that nor in the sources it pulls18:43
*** vineela <vineela!~vtummala@> has joined #yocto18:43
jordemortany clues on where that file is supposed to be coming from would be appreciated; i can't find many of the other variants it seems to reference there either18:44
*** sTKs <sTKs!~weechat@2001:818:e634:e700:81cb:5262:bdd:4b02> has quit IRC18:46
*** leon-anavi <leon-anavi!~Leon@> has quit IRC18:48
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto18:48
*** kiwi_29 <kiwi_29!> has quit IRC18:53
*** jobroe <jobroe!> has quit IRC18:54
*** kiwi_29 <kiwi_29!> has joined #yocto18:55
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:e2bc:3fed:317c:3efb> has quit IRC18:55
*** yizhao1 <yizhao1!> has quit IRC18:57
*** yizhao <yizhao!~zhaoyi@> has joined #yocto18:59
JPEWRP: Ah ok. It is a problem with short writes, but only when you make big writes. It's a combination of the kernel and python collaborating in a strange way:
*** kiwi_29 <kiwi_29!> has quit IRC19:06
*** emrius <emrius!> has joined #yocto19:07
emriusHey there, I need to toggle a flag in linux in gpio.h `GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME`. See this line:19:10
emriusI already have a bbappend where I configure linux kernel configs. Thus, I guess this also belongs in there.19:11
emriusDo I need to set some env variable such as `LINUX_KERNEL_EXTRA_ARGS` or so? I remember something similar to that but can't seem to find the exact point where to toggle that flag.19:12
emriusThat's the one I meant. Is that the right place to put that? I guess there should rather be a CC compiler extra args variable or so19:13
*** armpit <armpit!~armpit@2601:202:4180:a5c0:315d:c5e7:1295:54a9> has quit IRC19:13
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC19:20
*** yizhao1 <yizhao1!> has joined #yocto19:24
*** yizhao <yizhao!~zhaoyi@> has quit IRC19:26
*** Agent13 <Agent13!> has quit IRC19:33
*** lxc <lxc!> has quit IRC19:41
*** yizhao1 <yizhao1!> has quit IRC19:41
*** yizhao <yizhao!~zhaoyi@> has joined #yocto19:44
*** vineela <vineela!~vtummala@> has quit IRC19:46
*** vineela <vineela!~vtummala@> has joined #yocto19:47
*** kiwi_29 <kiwi_29!> has joined #yocto19:51
*** kiwi_29 <kiwi_29!> has quit IRC19:55
*** fray <fray!> has quit IRC20:00
*** fray <fray!> has joined #yocto20:00
kergothokay this is weird. if i set DEBUG_PREFIX_MAP_class-target to -fdebug-prefix-map=${B}=/foo, the work-shared path to a gcc binary gets truncated.. or rather, gets TMPDIR removed20:03
kergothi.e. /work-shared/gcc-9.3.0-r0/gcc-9.3.0/libatomic/gload.c rather than /mel/kergoth/mel/cb-toolchain/its-790/build/tmp-glibc/work-shared/gcc-9.3.0-r0/gcc-9.3.0/libatomic/gload.c20:03
kergotheven though that path doesn't include ${B} at all.20:03
kergothand the replacement string, /foo, isn't in the result. yet still the path changes20:04
kergothAnyone have any ideas?20:04
*** leon-anavi <leon-anavi!~Leon@> has quit IRC20:06
*** vineela <vineela!~vtummala@> has quit IRC20:14
*** emrius <emrius!> has quit IRC20:14
*** minimaxwell <minimaxwell!> has joined #yocto20:28
*** dvhart <dvhart!~dvhart@> has quit IRC20:35
*** mprokos <mprokos!> has joined #yocto20:37
*** mprokos is now known as rabbit991120:37
rabbit9911I have been looking at nix a little. Any thoughts about adding nixpkg support along side ipk/deb/rpm?20:37
*** minimaxwell <minimaxwell!> has quit IRC20:41
*** minimaxwell <minimaxwell!> has joined #yocto20:43
*** manu_ <manu_!> has joined #yocto20:45
*** dvhart <dvhart!~dvhart@> has joined #yocto20:49
*** armpit <armpit!> has joined #yocto20:49
*** kiwi_29 <kiwi_29!> has joined #yocto20:53
JPEWrabbit9911: I think someone was recently looking at making the packaging system more pluggable so that you could maintain such a thing on your own more easily20:56
JPEWI think their goal was APK20:56
*** Agent13 <Agent13!> has joined #yocto20:56
JPEWI suspect the core project necessarily needs to keep the number of package formats it support to a minimum.... we have a hard enough time with deb as it is20:57
boucmanHello everybody20:57
boucmanIs there an easy way, given a package name, to know where the corresponding package is (i.e the .rpm/.deb/.ipk file ?20:57
boucmanextending PV etc for me20:57
boucman(I want to use it in image-recipe context, so it can be a python call)20:58
JPEWboucman: Maybe.... why?20:58
boucmanI want to add partial update to meta-swupdate20:58
boucmanswupdate itself has already what I need, so i'm adding the yocto part20:59
rabbit9911JPEW: That makes sense. I will dwell on it. I was thinking of using it similar to what the yocto SDK is used for.20:59
boucmanbasically, I want to embedd a package in a .swu image then deploy on the target20:59
boucman(most of the time it will be a .tar package, since that's what makes most sense in this case)20:59
JPEWboucman: If you dig through package.bbclass you might find something useful21:00
boucmanI have been trying to dig through the do_rootfs logic to try to figure out how packages are found (in particular wrt PREFERRED_VERSION) but no luck21:01
boucmani'll look into package.bbclass21:01
JPEWboucman: The package manager handle that (e.g. opkg, dnf, apt)21:02
JPEWBasically, OE just creates a package repository21:02
JPEW(e.g. a feed) and tells the underlying tool to install a bunch of packages21:02
boucmanyes and no... at some point oe needs to "force" version, so PREFERRED_VERSION is obeyed, right ?21:02
boucmanbut yeah, unfortunately you might be right... so no where to look for that21:03
JPEWboucman: Ya... I don't exactly know were that happens21:03
boucmanmaybe I'll dig in the package_tar logic... since there is no package manager, I might have more luck21:03
JPEWboucman: Right, I think the problem you are likely to run into is that you'll always be second guessing what the package file names are21:04
boucmani'm a bit afraid of that, yes21:04
JPEWboucman: But... perhaps there is a way to get that information from the package manager itself when you build the swu file?21:05
JPEWe.g. "give me the exact file name of the 'busybox' package"21:05
boucmanmaybe, I havn't looked into using the PM itself yet... and that would be different for each PM21:06
boucman(unless there is a generic wrapper, but I would have stumbled onto it at this point, I think...)21:06
GeneralStupidI have an issue, that is that systemd-sysusers is telling me during startup that he cant lock /etc/passwd . Does anyone have a suggestion for me? Is it ok to use yocto useradd class with systemd?21:06
*** dvhart <dvhart!~dvhart@> has quit IRC21:06
*** dvhart <dvhart!~dvhart@> has joined #yocto21:09
*** minimaxwell <minimaxwell!> has quit IRC21:09
*** kiwi_29 <kiwi_29!> has quit IRC21:11
*** Kyubi <Kyubi!~Kyubi@> has quit IRC21:13
*** aleblanc <aleblanc!> has quit IRC21:13
*** kiwi_29 <kiwi_29!> has joined #yocto21:14
JPEWGeneralStupid: Should be fine. I'm doing it and it works OK21:20
khemrburton:  should be in today21:20
*** fray <fray!> has quit IRC21:21
RPJPEW: it is a rather odd combination of things. hopefully the patch I've added will help21:22
khemkergoth:  what issue do you run into with DEBUG_PREFIX_MAP21:22
kergothkhem: if you were in this channel earlier i elaborated. its' really strange behavior.21:23
kergothkhem: if i set DEBUG_PREFIX_MAP_class-target to -fdebug-prefix-map=${B}=/foo, the work-shared path to a gcc binary gets truncated.. or rather, gets TMPDIR removed21:23
kergothi.e. /work-shared/gcc-9.3.0-r0/gcc-9.3.0/libatomic/gload.c rather than /mel/kergoth/mel/cb-toolchain/its-790/build/tmp-glibc/work-shared/gcc-9.3.0-r0/gcc-9.3.0/libatomic/gload.c21:23
kergotheven though that path doesn't include ${B} at all.21:23
khema release after perhaps 10 years ?21:23
kergothand the replacement string doesn't show up in those entries at all21:23
kergothnow, that replacement *does* correctly apply to other source files21:23
kergothjust not these.. which it shouldn't, but why are they affected at all?21:24
*** vineela <vineela!vtummala@nat/intel/x-hatxzrkddwngieht> has joined #yocto21:24
khemkergoth:  I think it operates on WORKDIR21:24
kergothkhem: i'm directly printing the paths coming out of dwarfsrcfiles21:25
kergothnot looking at the resulting installed files21:25
kergothso why would the stored source file paths in the binary be altered like that? it's weird21:25
kergothunless package.bbclass is doing something else funky that i'm missing, but the parsing of the output of that tool is straightforward..21:26
khemsee meta/recipes-devtools/gcc/gcc-runtime.inc21:26
kergothi know, that's what i'm working on21:26
kergothi overrode DEBUG_PREFIX_MAP to only include that one entry, yet paths that don't contain the specified path are being altered somehow21:26
kergothi'm working on fixing the issue where gcc sources are not being included in the debug packages, but i can't fix the gcc paths from work-shared because they end up "/work-shared/gcc...."21:27
kergotheven though none of the mapping specify that21:27
kergothI dunno, I might have to call it a day and try again tomorrow21:27
jordemortfigured out my u-boot thing, i was using the wrong u-boot sources21:27
jordemortbut now this is driving me insane
jordemorti am getting a KeyError from sstate_report_unihash for my build user's UID, for a package i have not touched21:28
jordemortevery once in a while this happens and the only answer i've found is "blow away your sstate" but i would really really like to figure out how to prevent it from happening21:28
jordemortagain, this an untouched unmodified recipe, i haven't screwed up in do_install or anything, my build has just decided to randomly start choking on it for no discernible reason21:29
kergothjordemort: what release/branch?21:30
jordemortkergoth: dunfell21:30
jordemorti have a theory that it's related to RPM signing? because sometimes GPG dies in the middle of signing a package, also for unknown reasons; perhaps if that happens it leaves behind something with a bad UID maybe?21:32
khemkergoth:  I think I dont yet fully grasp the problem21:34
kergothI'll post a gist. I'm building gcc-runtime with package.bbclass adjusted to dump the source paths referenced by the binaries the build produces, and these paths are being modified in ways inconsistent with the specified debug-prefix-map21:37
kergothto sum up21:37
*** kiwi_29 <kiwi_29!> has quit IRC21:37
*** tgoodwin <tgoodwin!> has quit IRC21:37
*** kiwi_29 <kiwi_29!> has joined #yocto21:37
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC21:39
*** boucman <boucman!~boucman@wesnoth/developer/boucman> has quit IRC21:40
kergothkhem: there you can see the changed paths resulting from setting the map this way, but the first two entries shouldn't have changed at all, as they didn't contain the paths specified in the prefix map!21:42
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:dddd::1> has joined #yocto21:44
*** gnac <gnac!> has joined #yocto21:51
*** fray <fray!> has joined #yocto21:51
*** boucman <boucman!~boucman@wesnoth/developer/boucman> has joined #yocto21:52
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC21:54
*** kiwi_29 <kiwi_29!> has quit IRC21:54
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto21:55
*** kiwi_29 <kiwi_29!> has joined #yocto21:55
*** dvhart <dvhart!~dvhart@> has quit IRC21:58
vdlis it bad to define WKS_FILE in the image recipe?21:58
*** dmoseley <dmoseley!~dmoseley@> has quit IRC21:59
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto22:02
*** dvhart <dvhart!~dvhart@> has joined #yocto22:03
kergothvdl: generally yes, as it makes the image machine specific, whereas any combination of distro/machine/image are supposed to work22:05
vdlkergoth: I see. but it seems weird to me to defined different machines for my board's SD card, flash, and e.g. usb stick. isn't it?22:06
*** mbulut <mbulut!> has joined #yocto22:08
*** boucman <boucman!~boucman@wesnoth/developer/boucman> has quit IRC22:11
*** beneth <beneth!> has left #yocto22:22
*** mattsm <mattsm!> has quit IRC22:32
*** mattsm <mattsm!> has joined #yocto22:32
*** RzR is now known as rZr22:33
*** mattsm <mattsm!> has quit IRC22:38
*** mattsm <mattsm!> has joined #yocto22:39
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC22:44
*** kiwi_29 <kiwi_29!> has quit IRC22:46
*** kiwi_29 <kiwi_29!> has joined #yocto22:46
*** feddischson <feddischson!> has quit IRC22:51
*** kiwi_29 <kiwi_29!> has quit IRC23:02
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC23:05
*** bobo__ <bobo__!> has quit IRC23:07
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC23:08
*** bobo <bobo!> has quit IRC23:08
*** kpo__ <kpo__!> has quit IRC23:11
*** kpo__ <kpo__!> has joined #yocto23:12
*** dvhart <dvhart!~dvhart@> has quit IRC23:15
*** dvhart <dvhart!~dvhart@> has joined #yocto23:18
*** Agent13 <Agent13!> has quit IRC23:19
*** oberstet <oberstet!~oberstet@> has quit IRC23:30

Generated by 2.17.2 by Marius Gedminas - find it at!