Wednesday, 2020-12-09

*** kiwi_29 <kiwi_29!> has quit IRC00:01
*** kiwi_29 <kiwi_29!> has joined #yocto00:02
*** kiwi_29 <kiwi_29!> has joined #yocto00:03
hadiNeed some guidance. I want to use the src rpm package to create a debugFS. But the source RPM only contains subset of files. Is there any way I could pull in the whole content including and other C,header file. This will allow our designer to point their IDE to a DEBUGFS directory where all the src -rpm are  installed. Kind of a source00:03
hadilevel snapshot of all packages.  Any help will be appreciated.00:03
*** hpsy1 <hpsy1!~hpsy@> has joined #yocto00:07
*** hpsy <hpsy!~hpsy@> has quit IRC00:07
*** Kyubi <Kyubi!~Kyubi@> has quit IRC00:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto00:18
*** wzmuda <wzmuda!> has quit IRC00:20
*** Kyubi_ <Kyubi_!~Kyubi@2601:640:101:c8cf:c18c:1824:59c8:fbfc> has joined #yocto00:28
*** Kyubi__ <Kyubi__!~Kyubi@> has joined #yocto00:30
*** Kyubi <Kyubi!~Kyubi@> has quit IRC00:30
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC00:32
*** Kyubi_ <Kyubi_!~Kyubi@2601:640:101:c8cf:c18c:1824:59c8:fbfc> has quit IRC00:33
*** nerdboy <nerdboy!~sarnold@> has joined #yocto00:35
*** leon-anavi <leon-anavi!~Leon@> has quit IRC00:36
*** nerdboy <nerdboy!~sarnold@> has quit IRC00:39
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto00:39
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has quit IRC00:44
*** kiwi_29 <kiwi_29!> has quit IRC00:48
*** vineela <vineela!~vtummala@> has quit IRC00:51
*** rokm <rokm!> has quit IRC00:54
*** rokm <rokm!> has joined #yocto00:54
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has joined #yocto01:19
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC01:24
*** mbulut <mbulut!> has quit IRC01:30
*** ericch <ericch!> has quit IRC01:37
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:55
*** kiwi_29 <kiwi_29!> has joined #yocto02:02
*** kiwi_29 <kiwi_29!> has quit IRC02:07
*** JaMa <JaMa!> has joined #yocto02:09
*** kiwi_29 <kiwi_29!> has joined #yocto02:16
*** kaspter <kaspter!~Instantbi@> has quit IRC02:20
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:20
*** Kyubi__ <Kyubi__!~Kyubi@> has quit IRC02:28
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:4f7:596d:bf31:3950:5bda> has quit IRC02:28
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto02:29
*** kaspter <kaspter!~Instantbi@> has quit IRC02:30
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:30
*** meow` <meow`!~sbourdeli@> has quit IRC02:30
*** meow` <meow`!~sbourdeli@> has joined #yocto02:33
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC02:43
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:4f7:596d:bf31:3950:5bda> has joined #yocto02:43
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has quit IRC02:44
*** sakoman <sakoman!> has quit IRC02:44
*** nerdboy <nerdboy!~sarnold@> has joined #yocto02:45
*** nerdboy <nerdboy!~sarnold@> has quit IRC02:47
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto02:47
*** kiwi_29 <kiwi_29!> has quit IRC02:53
*** meow` <meow`!~sbourdeli@> has quit IRC03:02
*** hadi <hadi!a5e1d930@> has quit IRC03:03
*** kiwi_29 <kiwi_29!> has joined #yocto03:05
*** meow` <meow`!~sbourdeli@> has joined #yocto03:07
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto03:10
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has quit IRC03:14
*** kiwi_29 <kiwi_29!> has quit IRC03:16
*** kiwi_29 <kiwi_29!> has joined #yocto03:16
*** kiwi_29 <kiwi_29!> has quit IRC03:22
*** meow` <meow`!~sbourdeli@> has quit IRC03:33
*** meow` <meow`!~sbourdeli@> has joined #yocto03:39
*** kaspter <kaspter!~Instantbi@> has quit IRC03:42
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:42
*** ahadi <ahadi!~ahadi@> has quit IRC03:52
*** ahadi_ <ahadi_!> has joined #yocto03:52
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto03:52
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto03:54
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has quit IRC03:55
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto03:56
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto03:57
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has quit IRC03:59
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto03:59
*** kiwi_29 <kiwi_29!> has joined #yocto04:01
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has quit IRC04:01
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto04:01
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has quit IRC04:01
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has quit IRC04:02
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto04:02
*** meow` <meow`!~sbourdeli@> has quit IRC04:03
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has quit IRC04:04
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has joined #yocto04:05
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto04:05
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has quit IRC04:10
*** meow` <meow`!~sbourdeli@> has joined #yocto04:18
*** kiwi_29 <kiwi_29!> has quit IRC04:19
*** kiwi_29 <kiwi_29!> has joined #yocto04:19
*** kiwi_29 <kiwi_29!> has quit IRC04:27
*** Kyubi <Kyubi!~Kyubi@> has quit IRC04:28
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto04:33
*** kiwi_29 <kiwi_29!> has joined #yocto04:34
*** kiwi_29 <kiwi_29!> has quit IRC04:39
*** kiwi_29 <kiwi_29!> has joined #yocto04:50
*** kiwi_29 <kiwi_29!> has quit IRC05:05
*** kiwi_29 <kiwi_29!> has joined #yocto05:07
*** kaspter <kaspter!~Instantbi@> has quit IRC05:07
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:08
*** kiwi_29 <kiwi_29!> has quit IRC05:12
*** kiwi_29 <kiwi_29!> has joined #yocto05:16
*** stacktrust <stacktrust!sid452860@gateway/web/> has quit IRC05:21
*** stacktrust <stacktrust!sid452860@gateway/web/> has joined #yocto05:21
*** kiwi_29 <kiwi_29!> has quit IRC05:22
*** Mr_Singh_ <Mr_Singh_!~Mr_Singh@2607:fea8:bdf:dda2:4908:564f:8430:8c41> has quit IRC05:27
*** awafaa <awafaa!sid716@gateway/web/> has quit IRC05:27
*** camus <camus!~Instantbi@> has joined #yocto05:27
*** awafaa <awafaa!sid716@gateway/web/> has joined #yocto05:28
*** kaspter <kaspter!~Instantbi@> has quit IRC05:28
*** camus is now known as kaspter05:28
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC05:48
*** kiwi_29 <kiwi_29!> has joined #yocto05:52
*** camus <camus!~Instantbi@> has joined #yocto05:59
*** kaspter <kaspter!~Instantbi@> has quit IRC06:00
*** camus is now known as kaspter06:00
*** Shikadi` <Shikadi`!> has quit IRC06:06
*** jobroe <jobroe!> has joined #yocto06:07
*** Kyubi <Kyubi!~Kyubi@> has quit IRC06:08
*** jobroe <jobroe!> has quit IRC06:12
*** jobroe <jobroe!> has joined #yocto06:12
*** samvlewis6 <samvlewis6!~samvlewis@> has joined #yocto06:25
*** samvlewis <samvlewis!~samvlewis@> has quit IRC06:25
*** samvlewis6 is now known as samvlewis06:25
*** AndersD <AndersD!> has joined #yocto06:39
*** AndersD <AndersD!> has quit IRC06:40
*** AndersD <AndersD!> has joined #yocto06:42
*** AndersD_ <AndersD_!> has joined #yocto06:43
*** kaspter <kaspter!~Instantbi@> has quit IRC06:46
*** camus <camus!~Instantbi@> has joined #yocto06:46
*** AndersD <AndersD!> has quit IRC06:46
*** camus is now known as kaspter06:48
*** agust <agust!> has joined #yocto06:48
*** kiwi_29 <kiwi_29!> has quit IRC06:52
*** goliath <goliath!> has joined #yocto06:56
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:05
*** olani <olani!user@nat/axis/x-ovaiqlnrdfgrvaha> has quit IRC07:08
*** pharaon2502 <pharaon2502!> has joined #yocto07:10
*** w00die <w00die!~w00die@> has quit IRC07:22
*** w00die <w00die!~w00die@> has joined #yocto07:24
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC07:25
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:26
erboWeird. I just started to update a build from dunfell to gatesgarth, re-using the sstate-cache dir, and all files in the rootfs ends up being owned by uid 1000 instead of 0.07:27
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:5178:619c:fc92:5a85> has quit IRC07:36
*** camus <camus!~Instantbi@> has joined #yocto07:39
*** kaspter <kaspter!~Instantbi@> has quit IRC07:39
*** camus is now known as kaspter07:39
*** beneth <beneth!> has joined #yocto07:40
*** frsc <frsc!> has joined #yocto07:40
*** oberstet <oberstet!~oberstet@> has joined #yocto07:43
*** __ad is now known as ad__07:48
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has joined #yocto07:50
*** hpsy1 <hpsy1!~hpsy@> has quit IRC07:51
*** frwol <frwol!> has joined #yocto07:55
*** mckoan|away is now known as mckoan07:56
mckoangood morning07:56
erbogood morning07:58
*** fl0v0 <fl0v0!~fvo@> has joined #yocto07:59
*** Yumasi <Yumasi!> has joined #yocto08:12
*** tnovotny <tnovotny!> has joined #yocto08:13
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC08:44
*** mbulut <mbulut!> has joined #yocto08:45
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto08:45
qschulzgood morning08:45
*** manuel1985 <manuel1985!> has joined #yocto08:49
manuel1985Good Morning everyone!08:51
manuel1985Quick question: If I recall correctly, there's a bbclass which will set all package versions to the latest upstream version. It overwrites what is specified in the recipe itself. What's the name of that bbclass again? How do I utilize that?08:51
*** kiwi_29 <kiwi_29!> has joined #yocto08:53
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:54
rburtonmanuel1985: there isn't a class that does that, no08:55
rburtondevupstream can be used to building latest git for a specific recipe08:55
rburtonor if a recipe uses git already then just setting SRCREV=${AUTOREV} will grab HEAD08:55
rburton(poky-bleeding is an example of this)08:55
*** kiwi_29 <kiwi_29!> has quit IRC08:57
manuel1985Found it, thanks:
*** leon-anavi <leon-anavi!~Leon@> has quit IRC09:01
*** bps <bps!~bps@> has joined #yocto09:01
rburtondevupstream has some gotchas, doesnt work well with native yet for example09:01
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:01
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has quit IRC09:02
*** Ru3D3e <Ru3D3e!> has joined #yocto09:09
wyrehas been meta-yocto layer renamed?
wyreis meta-poky now maybe?09:12
wyreI can see the sample files in meta-poky/conf/ folder09:13
*** T_UNIX <T_UNIX!~T_UNIX@2a02:8071:b696:bd00:57dc:e194:3053:35c0> has joined #yocto09:14
wyreI'm asking this because I cannot see any reference to 'meta-poky' in the oe-setup-builddir script09:15
qschulzwyre: are you **really** building poky 1.7?09:17
wyreohh, so there is a .templateconf to fix the path ... 🤔09:17
wyreqschulz, upps, sorry09:17
qschulzwyre: if you want to document yourself, please use up-to-date documentation or documentation related to the version you'll be using09:19
*** camus <camus!~Instantbi@> has joined #yocto09:19
qschulzpoky 1.7 is atrociously old (6yo)09:19
*** kaspter <kaspter!~Instantbi@> has quit IRC09:20
*** camus is now known as kaspter09:20
rburton <-- released october 201409:20
qschulzit's closer to the first release of Yocto than today's09:20
wyreqschulz, yes, you are right, I'm sorry, I just googled about the TEMPLATECONF variable and I went to that outdated docs09:20
qschulzwyre: :)09:20
rburtongoogle is basically sabotaging our docs09:20
rburtonjust always replace the version in the URL with 'latest'09:20
qschulzndec: should we put a big red header on documentation still hosted on to say that it is outdated?09:21
wyreqschulz, so according to .templateconf script TEMPLATECONF will be meta-poky/conf if there not exist previously, right?09:21
rburtoni don't think meta-poky shipped that file09:22
*** bps <bps!~bps@> has quit IRC09:23
*** leon-anavi <leon-anavi!~Leon@> has quit IRC09:23
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:23
wyreand .templateconf is sourced in oe-setup-builddir09:23
rburtonah top level, right09:23
wyreqschulz, also I cannot find TEMPLATECONF variable in the ref-variables 😆09:24
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has quit IRC09:25
rburtonif you're making a custom distro then might be useful09:25
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has joined #yocto09:27
wyrerburton, I was actually trying to understand how `require` directive works, because according to the example config BBPATH = "${TOPDIR}" but TOPDIR is the folder where I've run bitbake ... so I don't know how is fetching with that relative path
wyreI mean, TOPDIR would be `build` because when I source oe-init-build-env `build` dir is created and is the folder where I'm running bitbake 🤔09:30
wyreso ... how can require fetch something that it's inside of ../meta/recipes-core/images/ ?09:32
qschulzrequire is given a path relative to either the current directory or the "root" directory of any layer09:33
olani[m]wyre: BBPATH is typically extended in each layers conf/layer.conf file.09:34
ndecqschulz: do you mean here for example: ?09:34
wyreqschulz, the current directory where recipe is placed?09:36
*** kpo_ <kpo_!> has quit IRC09:36
wyremy recipe is in my own layer09:36
*** hpsy <hpsy!~hpsy@> has joined #yocto09:36
*** kpo_ <kpo_!> has joined #yocto09:37
wyreI mean, is in poky/meta/recipes-core/images/09:37
wyreand my recipe has a completely different path09:37
wyreit's at the same level than poky09:38
olani[m]wyre: Each layer adds its root to BBPATH in its conf/layer.conf file.  So the BBPATH can be searched for any file you 'require'09:39
wyreolani[m], so you mean that poky/meta/ is already appended to BBPATH?09:40
qschulzwyre: require recipes-core/images/ in your recipe09:40
qschulzwyre: the poky git repo is not ONE layer, it's multiple layers09:40
qschulzpoky/meta is one for example09:40
olani[m]wyre: Check it with bitbake -e09:40
wyreqschulz, yes, I know, I was trying to understand why this works without giving a deeper path09:40
wyreolani[m], you mean `bitbake -e myrecipe` ?09:41
olani[m]wyre: yes, or just bitbake -e for the global environment09:41
*** frwol <frwol!> has quit IRC09:41
wyreolani[m], oh, I can see with `bitbake -e | grep "^BBPATH"`09:43
*** frwol <frwol!> has joined #yocto09:43
olani[m]wyre: You probably know that bitbake -e also outputs the 'history' of the variable so you can see how it was appended to by various files.09:44
*** frsc <frsc!> has quit IRC09:48
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto09:49
wyreolani[m], there are 24k lines in the bitbake -e output09:51
wyreshould I search for BBPATH pattern?09:51
olani[m]wyre: So use something like 'grep -B30 "^BBPATH"' or less and search for ^BBPATH=09:52
olani[m]I tend to output bitbake -e to a tempfile so I don't have to rerun bitbake for each search pattern change09:52
qschulzor use a pager such as `less` and look for BBPATH= and just look up in the pager09:53
wyreqschulz, yes, I've used that method 😄09:54
wyrethen ... why TEMPLATECONF is not the ref-variables list?09:55
LetoThe2ndyo dudX09:55
qschulzwyre: it seems TEMPLATECONF is an environment variable that is used by the script you source before building09:58
qschulzhence it's not really a variable that can be used in "normal" conf files?09:58
olani[m]It is mentioned in the ref manual, but not in the variable index.09:58
qschulzLetoThe2nd: o/09:58
wyreso it's an internal variable which is not intended to be set by the final user, I see09:59
qschulzwyre: no, what i meant is, it's not a variable you can set in a "Yocto" conf file, bbclass or recipe10:00
qschulz(from a very quick glance)10:00
wyreoh, I see10:00
qschulzso it IMHO does not have its place in the variable index10:00
*** Bunio_FH <Bunio_FH!> has quit IRC10:02
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:b02d:62f7:a7bb:b514> has joined #yocto10:04
*** Bunio_FH <Bunio_FH!> has joined #yocto10:08
*** creich <creich!> has quit IRC10:11
*** NiniC0c0 <NiniC0c0!> has joined #yocto10:12
*** creich <creich!> has joined #yocto10:13
*** frsc <frsc!> has joined #yocto10:13
wyreI cannot run `runqemu` because of TUN control device "runqemu - ERROR - TUN control device /dev/net/tun is unavailable; you may need to enable TUN (e.g. sudo modprobe tun)"10:14
wyrebut the module is loaded in the host system (I'm trying to run it inside the crops container)10:14
smurraywyre: you could try the slirp mode as an alternative, "runqemu slirp"10:17
smurraywyre: though that doesn't necessarily work for all usecases10:17
wyresmurray, oh, it worked, what's the difference between slirp and qemuarm?10:17
wyreapparently a few days ago it worked with qemuarm I was following the LetoThe2nd's playlist
smurraywyre: well, slirp and tap, see
smurraywyre: were you running inside crops at that time?10:19
wyresmurray, I'd say so10:19
smurraywyre: runqemu defaults to tap, which needs to be able to sudo to root10:19
wyresmurray, so I can combine qemuarm with slirp, right?10:20
smurraywyre: if you can live with the restrictions mention in that QEMU doc link I posted, big one is "the guest is not directly accessible from the host or the external network"10:21
*** kpo_ <kpo_!> has quit IRC10:25
wyresmurray, I'd say I've followed the LetoThe2nd video inside a crops container and it worked using the same command 🤔10:25
smurraywyre: I can't say, you'll have to investigate locally what would have changed10:26
*** kpo_ <kpo_!> has joined #yocto10:26
carlsb3rgis there a way of exctracting a distinct list of liceneses and/or the licenses themselves?10:32
carlsb3rgI've looked in deploy/licenses/[my-image-name]-[build-date] but that isn't a complete list...amongst other things I noticed that the linux-firmware license for my e100 network card isn't there10:36
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:f038:1ea1:3507:febb> has quit IRC10:36
carlsb3rgis it better to get them from the final image instead?10:36
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto10:43
LetoThe2ndcarlsb3rg: i'd work through and see what fits your needs.10:43
carlsb3rgok...thanks...I'll read that10:48
*** camus <camus!~Instantbi@> has joined #yocto10:48
*** kaspter <kaspter!~Instantbi@> has quit IRC10:50
*** camus is now known as kaspter10:50
*** Ru3D3e <Ru3D3e!> has quit IRC11:00
*** leon-anavi <leon-anavi!~Leon@> has quit IRC11:01
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto11:01
*** tsjsieb <tsjsieb!> has joined #yocto11:15
*** bps <bps!~bps@> has joined #yocto11:29
*** bps <bps!~bps@> has quit IRC11:36
*** bps <bps!~bps@> has joined #yocto11:37
wyrewhy if I'm building this core-image-minimal the image does not contain systemd?11:43
wyreis it not being appended?11:43
*** perplexabot <perplexabot!~perplexab@2600:8801:f100:35::b6d8> has quit IRC11:44
*** perplexabot <perplexabot!~perplexab@2600:8801:f102:1200::b10a> has joined #yocto11:47
LetoThe2ndwyre: what gives you the idea that it should be?11:48
wyreLetoThe2nd, line 12?11:49
LetoThe2ndwyre: seriously, that idea is so extremely far fetched that i cannot believe you even tried to read the line.11:49
LetoThe2ndwyre: with that, i hereby redirect you to
LetoThe2ndwyre: as well as
* LetoThe2nd is silent again then.11:51
erboHmm, at what point in rootfs creation is permissions set? Looking at e.g. <myimage>/<version>rootfs/bin/mount.util-linux in tmp/ it looks like it's owned by my user, but in the resulting wic image it's owned by root.11:55
erboAt least on dunfell, on gatesgarth the mount.util-linux is owned by the uid of my build host user and therefore it won't mount anything.11:56
wyreLetoThe2nd, according this bb.utils.contains() is checking if the variable DISTRO_FEATURES contains the values specified11:58
LetoThe2ndwyre: absolutely correct. and?11:58
wyreif DISTRO_FEATURES doesn't contain systemd is not appending it?11:59
olani[m]erbo: That is handled by pseudo, the fakeroot tool used by bitbake.  If I understand your question correctly.12:00
*** sagner <sagner!~ags@2a02:169:3df5:0:6d9:f5ff:fe22:28bf> has quit IRC12:00
LetoThe2ndwyre: *sigh* like i said, you did not read the line, you just interpreted into it what you wanted to see. have a look at the very first words in the line. does it ring a bell? if not, here it comes: it is about the space in the rootfs fs. if systemd is in the distro features, there is additional space reserved.12:01
erboolani[m]: is it done in the same way regardless if I'm building a wic image or .ext3 file?12:01
LetoThe2ndwyre: please forgive me if i put you on brain ignore now. have fun.12:02
rburtonerbo: permissions are handled before images are involved12:02
rburtonerbo: i suggest forcing a rebuild of util-linux  to see what happens (bitbake util-linux -C unpack), build a new image and see.  files owned by the build user should be causing huge warnings12:03
erborburton: should the files in tmp/work/*/util-linux have the correct permissions (owned by root) then?12:04
rburtonyou're a normal user, how would you write a file owned as root? :)12:04
rburton(this is the pseudo magic)12:04
erboright, I'm stupid :)12:04
LetoThe2ndis that even a word?12:05
erboit is now12:05
*** tgoodwin <tgoodwin!> has joined #yocto12:06
RPkanavin_home: we did see one repro failure with your world change: - looks like a sorting issue...12:14
RPkanavin_home: also, I've been thinking, it would be handy if the ptest runs on the autobuilder shows warnings upon regressions?12:17
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC12:18
*** wz <wz!> has joined #yocto12:23
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto12:23
RPpaulbarker: I've queued that revert we discussed since I'd like to build M1 and I think it should be included12:27
*** RobertBerger <RobertBerger!> has quit IRC12:27
JaMaRP: would you accept revert of as well if I send it?12:29
RPJaMa: good question, I'm frustrated there is no response too :(12:31
RPJaMa: yes, lets revert it12:32
RPJaMa: want me just to do it?12:33
JaMaplease do if you can12:33
JaMaI don't have better explanation than what I've used in the e-mail12:33
kanavin_homeRP: yeah, those sorting issues are notoriously non-reproducible ;), I haven't seen this one in any of my tests12:34
kanavin_homeRP: if you add it to the exclusion list, please also add the link to the repro-fail directory where artefacts and diff can be found12:35
kanavin_homenon-reprodible non-reproducibility :)12:35
kanavin_homeextra level of indirection, my head can barely cope12:35
erbokanavin_home: join me in the pseudostupid club :)12:36
RPkanavin_home: I'm going to hold the world list until M1 is sorted and then we can figure this out. I will keep it in -next12:37
kanavin_homeRP: as for ptest, I wanted to again try to make it a hard failure12:37
RPkanavin_home: well, if you can make it a warning, I can merge that more easily and it will stop things regressing as we watch the AB for warnings12:37
kanavin_homeRP: from what I have seen, it's just exclusing lttng-tools-ptest, and figuring out the intermittent valgrind failures12:38
RPkanavin_home: if we could at least stop anything else regressing (and spot it), that would be a big win12:38
kanavin_homeRP: sure, so warning == failures? that would be easier than warning == more failures than before.12:38
RPkanavin_home: I don't particuarly want to remove lttng from tests as a large chunk of them do pass12:38
RPkanavin_home: warning == failures no != vlagrind/lttng ?12:39
kanavin_homeRP: that would work12:39
*** RobertBerger <RobertBerger!> has joined #yocto12:39
RPkanavin_home: that would let us stop regressing I think12:39
*** hpsy <hpsy!~hpsy@> has quit IRC12:40
*** hpsy <hpsy!~hpsy@> has joined #yocto12:41
*** carlsb3rg <carlsb3rg!~chrissc@> has quit IRC12:42
*** leon-anavi <leon-anavi!~Leon@> has quit IRC13:01
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto13:01
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has quit IRC13:02
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has joined #yocto13:04
erboAh, so I've narrowed my file permission issue down to the use of --exclude-path in the wks file used for wic image creation.13:23
erboIf I don't use --exclude-path all is good, if I do use it the files will have the wrong permissions.13:23
erboI seem to recall reading something about pseudo and ignore dirs etc changing for this release, so I'm off to do some reading about that13:24
*** jobroe_ <jobroe_!> has joined #yocto13:30
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has joined #yocto13:31
*** jobroe <jobroe!> has quit IRC13:32
*** frsc <frsc!> has quit IRC13:34
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto13:36
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC13:39
*** Yumasi <Yumasi!> has quit IRC13:47
*** frsc <frsc!> has joined #yocto13:47
*** bps <bps!~bps@> has quit IRC13:48
erboAh, there's already a bug for this:
*** Yumasi <Yumasi!> has joined #yocto13:48
*** konsgnxx <konsgnxx!> has joined #yocto14:02
*** sakoman <sakoman!> has joined #yocto14:02
*** kaspter <kaspter!~Instantbi@> has quit IRC14:05
*** kaspter <kaspter!~Instantbi@> has joined #yocto14:06
*** kaspter <kaspter!~Instantbi@> has quit IRC14:10
*** bps <bps!~bps@> has joined #yocto14:12
*** bps <bps!~bps@> has quit IRC14:16
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto14:26
*** dv|2 <dv|2!~dv@> has joined #yocto14:36
dv|2how to get rid of SDK generation "locale archive not found" problem?
yannWhen we change a SRC_URI to get the same source from a difference place, this taints sigdata.  We already have source checksums and SRCREV, we could just omit the URI from the hash, right ?14:38
LetoThe2ndyann: you better add "asking for a friend" ;-)14:44
qschulzyann: I might want to manually bump the revision of a package without renaming the recipe, in which case a build wouldn't be retriggered14:44
qschulzI see very little benefit and a very implicit side effect14:45
qschulzbut I am probably missing a valid use case so please let us know14:45
yannqschulz: changing the revision would change the hash anyway, right ?14:46
RPyann: if it were me I'd probably do it with PREMIRRORS then that might keep the same hash14:47
qschulzyann: quick and dirty testing, just changing the SRC_URI will not retrigger a build14:53
yannRP: the problem is not on this side.  The vendor meta-rockchip layer changed most of its SRC_URI's because the upstream repo moved.  I'm currently battling with bitbake to remove/append the necessary stuff so I can avoid rebuilding linux-libc-headers and the whole target with it.  Afterwards will come PREMIRRORS to set the proper URL for those that did not fetch before the change.14:53
qschulzwell technically linux-libc-headers shouldn't be impacted right? I mean if it is, bad (as stated in the recipe :) )14:54
*** ericch <ericch!> has joined #yocto14:54
yannI'm pretty much baffled by this: not only does SRC_URI have an impact, but even _remove (from a .bbappend) causes funky effects:
yannqschulz: they include a linux-libc-headers_4.4-custom to provide a uapi matching the tons of stuff they backported from newer kernels (some of which, incidently, we rely on)14:56
yannI'm pretty much baffled by the "_remove of git://;branch=kernel;" you can see in the pastebin14:57
RPyann: PREMIRRORS allows you to rewrite SRC_URI without changing the hashes which is what you asked for.14:58
yannRP: I understand, but it's not what I need as a first step14:58
RPyann: Everything related to a variable is encoded into the hash, including remove values, the hash is not about the variable evaluated value but all its dependencies and makeup too14:58
*** Ru3D3e <Ru3D3e!> has joined #yocto14:59
wyreare all these variables intended to use them in recipes? 🤔14:59
*** kpo_ <kpo_!> has quit IRC15:00
qschulzwyre: no, some in conf files too15:00
RPwyre: not all, definitely not15:00
RPwyre: some are documented as they're used in the code but you'd most likely not need them15:01
kanavin_homeRP: I'll see if I can do additional targeted disabling in lttng and sort the valgrind sporadic fails first15:01
yannmeta-rockchip changed the SRC_URI, my original point is that it should not impact the siginfo as long as the SRCREV is the same, right ?  The problem is diffsigs says the sole difference is SRC_URI - my original problem was that one:
kanavin_homeRP: I don't want more of those exception lists :) would rather have a hard ptest failure15:01
wyreRP, qschulz where should I use DISTRO_ variables?15:01
*** kpo_ <kpo_!> has joined #yocto15:01
RPyann: it will impact the hash as the hash mechanism is not content aware15:01
wyrein the layer conf file?15:01
yannand from this point do_unpack is tainted, and the whole target userspace15:01
yannRP: so I can't restore the original hash without forking meta-rockchip again ?15:02
RPyann: It will impact the hash. Your only way to avoid that would either be to use PREMIRRORS as I suggested which you keep telling me you don't want to, or perhaps force the variable hash value15:03
RPor lock the hash, that would work too15:03
RPyann: you could try setting SRC_URI[vardepvalue] = "<old SRC_URI>"15:04
yannI do want to use PREMIRRORS, I'm merely insisting that as it won't change the hash I have to fix it through an additional mechanism :)15:04
qschulzwyre: in... distros as the name implies?15:04
qschulzI mean, set in distros, then you can read them from anywhere15:05
RPyann: I think I see what you mean, you want to use the old hash when the upstream has changed to a new url15:06
RPyann: in that case vardepvalue can probably force things15:06
wyreqschulz, but are distros part of a layer? are a type of layers?15:07
* RP makes no comment on whether this makes any sense. 15:07
yannseems too, it's picky on whitespace though (!)15:07
RPyann: locked sigs is your other option15:07
RPyann: you will have to get whitespace right, yes15:07
qschulzwyre: if it's not part of a layer, where would you have the distro file?15:10
*** Ru3D3eR <Ru3D3eR!~Ru3D3eR4@> has joined #yocto15:15
yannRP: a bad side effect from vardepvalue is that if they change other things (add a new patch) I'll get an inconsistent hash15:16
yannLooks like the safest way is to duplicate the old version of the recipe in our layer15:16
yannBut then, is there a good reason to satrt with, to be that picky with SRC_URI contents ?15:17
RPyann: right, you could do something like SRC_URI[vardepvalue] = "${@d.getVar("SRC_URI").replace("XXX", "YYY")}" I guess15:17
RPyann: as I tried to explain above, the algorithm is not context aware, it works for a any variable value including functions15:18
*** Ru3D3e <Ru3D3e!> has quit IRC15:18
RPI'm sure we could start adding all kinds of special logic into it but which cases matter and which cases don't?15:18
yannyeah, not an easy one15:19
*** Ru3D3e <Ru3D3e!> has joined #yocto15:20
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has quit IRC15:21
*** davidinux <davidinux!~davidinux@> has quit IRC15:21
wyreqschulz, I don't have the distro file because I've created an example layer with bitbake-layers15:21
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has joined #yocto15:22
qschulzwyre: you cna't build without a distro ;)15:22
yannI'd start with "anything with a SRCREV or a SRC_URI[*.*sum] can get excluded from SRC_URI[vardepvalue]"15:22
wyreqschulz, I'm using right now poky as distro, I think15:22
wyrebut should I add a distro to my layer? 🤔15:22
qschulzwyre: it's defined in your local.conf which distro is used15:22
wyreqschulz, yes, I know it15:23
*** Ru3D3eR <Ru3D3eR!~Ru3D3eR4@> has quit IRC15:23
wyreI'm pretty sure it's poky15:23
qschulzwyre: 1) machine conf file, 2) image recipe, 3) distro if poky is not enough/too much15:23
*** davidinux <davidinux!~davidinux@> has joined #yocto15:23
wyreqschulz, so I guess there are also some inherit/include mechanisms to manage distros, right?15:25
qschulzwyre: they are conf files15:27
*** Gundy <Gundy!5bc86cfa@> has joined #yocto15:27
wyrealso recipes? 🤔15:28
RPyann: do we really want to add an maintain such a list of "rules"?15:33
*** kaspter <kaspter!~Instantbi@2409:8a1e:911b:1000:69fd:8d1d:f742:81a6> has joined #yocto15:33
RPyann: I appreciate you have a specific problem now but the answer is no, we don't ;-)15:34
GundyHeyo, I could use some help. Bitbaking a kernel recipe using GIT as a source, its a local clone. So my SRC_URI looks like this: "git:///workspace/processor-sdk-linux;protocol=file;branch=Versions/Neptune". SRCREV is set to "${AUTOREV}" and PV_append to "+git${SRCPV}".15:34
*** jonasbits <jonasbits!~quassel@2001:2002:4e48:1aca:908e:1969:c028:2e1d> has quit IRC15:34
GundyWoops, sorry, haven't finished typing. bare with me :)15:34
qschulzwyre: no, conf files, so work the same way as .conf files15:35
qschulze.g. machines15:35
qschulzobviously, it's not identical but the require/include should work the same way15:35
*** jonasbits <jonasbits!~quassel@2001:2002:4e48:1aca:908e:1969:c028:2e1d> has joined #yocto15:36
yannRP: it would not seem that much of a stretch to "replace" every such file's URI with his hash/siginfo.   Since every remotely-fetched source is identified with a hash already, it looks like there'll be no other thing to add to that "list of rules", even ;)15:38
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto15:38
GundySo, first build of the kernel is fine. I then create a new commit and call bitbake with the recipe name again. This is where it fails to fetch. The git fetcher seems to run "git -c core.fsyncobjectfiles=0 branch --contains 16711b1ab1b669c1243c0bc04ef1cbdbb928cff0 --list Versions/Neptune" (that ID is the new commit), but that comes back with an15:39
Gundyerror, saying there is no such commit. It runs this inside of "downloads/git2/workspace.processor-sdk-linux" and indeed, that clone doesn't have that commit. Why is that?15:39
GundyOh, the version of Yocto I am using is 2.2, so quite old by now :/15:40
yannthat would be like, generating a siginfo for every SRC_URI item, and use the hash in it instead of the URI itself, when there's one (keeping those bitbake-specific URI parameters we add, obviously)15:40
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC15:40
RPyann: you're willing to write and maintain that? ;-)15:41
yannIf I had the time :)15:42
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has quit IRC15:43
yannwouldn't that make a nice SoC topic ?15:44
*** AndersD_ <AndersD_!> has quit IRC15:45
qschulzGundy: is the commit in the master branch or in a different branch?15:46
GundyThat commit is in the branch "Versions/Neptune", the one specified with "branch=" in SRC_URI. Thanks for taking a look :)15:47
qschulzGundy: any reason for using a local git repo instead of externalsrc or devtool?15:48
GundyI have run the same git command I mentioned above inside of the location specified in SRC_URI and there it happily succeeds. Just not in the download-folder that bitbake is using. There things are still looking like the previous build.15:48
Gundyqschulz: The repo location is passed with a variable. In production that one points to the main repo (using http protocol), but when developing we override that variable to point to our local clone of said repo. Maybe that's not how its supposed to be done? I haven't heard of externalsrc and have only recently watched a talk on devtool, so I can't15:52
Gundysay that I am familiar with it either.15:52
qschulzGundy: don't know :man_shrugging: you can have a look in the fetcher python code directly and start debugging from there15:53
GundyThe other reason for using a local clone of that repo is that when working remotely, we have to fetch through the VPN and that's just taking too long (as in 30 minutes).15:53
qschulzI've only ever used local git repo with the git fetcher by using a fixed SRCREV so no idea really :/15:56
*** Kyubi <Kyubi!~Kyubi@2601:640:20b:983f:1483:5361:a7da:3dd3> has joined #yocto16:06
*** Kyubi <Kyubi!~Kyubi@2601:640:20b:983f:1483:5361:a7da:3dd3> has quit IRC16:10
Gundyqschulz: Thanks though! Yep will continue peeking at git.py16:15
*** rcw <rcw!~rcwoolley@> has joined #yocto16:17
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC16:24
*** frsc <frsc!> has quit IRC16:25
*** Mr_Singh_ <Mr_Singh_!~Mr_Singh@2607:fea8:bdf:dda2:4908:564f:8430:8c41> has joined #yocto16:26
*** jobroe_ <jobroe_!> has quit IRC16:27
sgwRP: was the bitbake.conf revert responsible for the failures yesterday?16:27
RPsgw: no, separate issue16:31
RPsgw: the M1 build looks like a disaster :(16:32
* zeddii doesn't remember typing 0lll16:33
* RP doesn't understand how master is suddenly so broken16:35
*** mbulut <mbulut!> has quit IRC16:40
*** adelcast <adelcast!~adelcast@2806:108e:1a:2a74:286b:3fe0:de39:c5b1> has left #yocto16:40
*** adelcast <adelcast!~adelcast@2806:108e:1a:2a74:286b:3fe0:de39:c5b1> has joined #yocto16:42
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has joined #yocto16:45
RPsgw, kanavin_home: Its the change to DISTRO_VERSION in poky :(16:46
RP/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/aarch64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/3.2+snapshot-9826881036191be6ffba98c9bc8a86d1b852ff41/sysroots/aarch64-pokysdk-linux/usr/lib/': No such file or directory16:46
RPboth 3.2+snapshot-9826881036191be6ffba98c9bc8a86d1b852ff41/ and 3.2+snapshot-be4e442da1b22e4a0d85cc74f11fec4981207684/ exist16:46
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto16:47
sgwRP: this is one of those things that happens every 6 months and gets goofed up from time to time?16:55
RPsgw: no, we just changed the way this worked for reproducibility (oh the irony)16:55
sgwOh boy, Ok, I will not worry about swatting that further than.16:56
RPsgw: right, I'll do something about this, I think I understand some of it now16:59
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has quit IRC17:02
*** frwol <frwol!> has quit IRC17:04
*** tnovotny <tnovotny!> has quit IRC17:23
*** vineela <vineela!~vtummala@> has joined #yocto17:24
*** davidinux <davidinux!~davidinux@> has quit IRC17:26
*** tsjsieb <tsjsieb!> has quit IRC17:30
*** mckoan is now known as mckoan|away17:30
*** Shikadi` <Shikadi`!> has joined #yocto17:32
kanavin_homeRP: thanks for sorting this :)17:32
RPkanavin_home: np, its actually pretty nasty, fixes to core and to poky17:33
RPkanavin_home: I've pushed some changes so we'll try again for M1 :)17:36
*** kiwi_29 <kiwi_29!> has joined #yocto17:39
*** kiwi_29 <kiwi_29!> has quit IRC17:42
*** junland <junland!~junland@> has quit IRC17:44
*** fl0v0 <fl0v0!~fvo@> has quit IRC17:45
*** junland <junland!~junland@> has joined #yocto17:45
*** junland <junland!~junland@> has quit IRC17:46
*** junland <junland!~junland@> has joined #yocto17:47
*** davidinux <davidinux!~davidinux@> has joined #yocto17:57
v0nI don't understand wic's --ondisk option17:59
v0nwhat's the point of specifying sda or sdb17:59
JPEWv0n: It can populate the fstab with the mounts18:01
v0noh ok, so that has to be the name that the SD card slot will have on the target machine18:02
RPkanavin_home: :)18:03
*** Kyubi <Kyubi!~Kyubi@> has quit IRC18:06
*** junland <junland!~junland@> has quit IRC18:06
*** Yumasi <Yumasi!> has quit IRC18:06
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto18:07
JPEWv0n: Ya18:08
*** pharaon2502 <pharaon2502!> has quit IRC18:09
*** pharaon2502 <pharaon2502!> has joined #yocto18:14
kanavin_homeRP: nice :)18:16
*** pharaon2502 <pharaon2502!> has quit IRC18:18
*** mbulut <mbulut!> has joined #yocto18:18
*** junland <junland!~junland@> has joined #yocto18:21
*** armpit <armpit!~armpit@2601:202:4180:a5c0:44ad:b2c4:bf7f:7e99> has quit IRC18:21
*** psiva87 <psiva87!> has joined #yocto18:22
psiva87Hi everyone,18:22
*** dev1990 <dev1990!> has quit IRC18:23
*** dev1990 <dev1990!> has joined #yocto18:23
*** armpit <armpit!~armpit@2601:202:4180:a5c0:c584:dc9f:dcf0:9e06> has joined #yocto18:26
psiva87I want binary installed by cmake (yocto recipe) to be available in rootfs, does adding SYSROOT_DIRS += "${bindir}" to recipe a correct way? It works in fact..18:26
*** w00die <w00die!~w00die@> has quit IRC18:27
*** w00die <w00die!~w00die@> has joined #yocto18:29
*** NiniC0c0 <NiniC0c0!> has quit IRC18:31
*** wz <wz!> has quit IRC18:32
*** dv|2 <dv|2!~dv@> has quit IRC18:33
*** kiwi_29 <kiwi_29!> has joined #yocto18:39
*** kiwi_29 <kiwi_29!> has quit IRC18:43
*** Hadi <Hadi!a5e1d930@> has joined #yocto18:54
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:55
*** mbulut <mbulut!> has quit IRC18:57
HadiSorry for asking this question again. I need a way to download all application sources for a release load. This is to allow designer to have access to the application sources in their IDE.  I could use the src package in the deploy directory. But those packages are subset  of all source files.  I dont want to do "devtool modify". Is there any19:01
Hadioptions to download the complete source and create a DEBUGFS. Thank for any help.19:01
JPEWHadi: Yes.....19:04
JPEWApparently, that variable is not in the manual variable index :/19:06
JPEWHadi: Covered there though:
HadiThanks JPEW, I think IMAGE_GEN_DEBUGFS only unpack *-src.rpm. The src package only contain C and header file.  It doesn't contain all files from a package. Eg: The package may have  automake, m4  and other files.  I need something equivalent to "devtool modify  < all package-name >"19:14
*** beneth <beneth!> has left #yocto19:23
*** kiwi_29 <kiwi_29!> has joined #yocto19:24
JPEWHadi: Ah. No I don't think there's anything to do that19:31
*** kaspter <kaspter!~Instantbi@2409:8a1e:911b:1000:69fd:8d1d:f742:81a6> has quit IRC19:32
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:b02d:62f7:a7bb:b514> has quit IRC19:36
*** T_UNIX <T_UNIX!~T_UNIX@2a02:8071:b696:bd00:57dc:e194:3053:35c0> has quit IRC19:37
*** T_UNIX <T_UNIX!> has joined #yocto19:37
*** dreyna <dreyna!> has joined #yocto19:38
*** asteriusio <asteriusio!> has joined #yocto19:38
*** mbulut <mbulut!> has joined #yocto19:45
*** wz <wz!> has joined #yocto19:54
kiwi_29Hello..I m getting this error when building a distro . The error is inside run.do_rootfs20:00
kiwi_29Errors were encountered while processing:20:00
kiwi_29<full path>/<name of deb>.deb20:00
kiwi_29W: --force-yes is deprecated, use one of the options starting with --allow instead.20:00
kiwi_29W: No sandbox user '_apt' on the system, can not drop privileges20:00
kiwi_29E: Sub-process dpkg returned an error code (1)20:00
kiwi_29Not able to understand how to debug this as part of do_rootfs as there is no more details.. How to get more info or debug20:00
*** jobroe <jobroe!> has joined #yocto20:06
codypskiwi_29: one can edit the run.do_rootfs script and re-run it to get more output. It's also a good idea to look at the stored log files for the recipe.20:08
kiwi_29thanks codyps I looked log.do_rootfs in detail and found this20:09
kiwi_29Unpacking PACKAGENAME (0.42.1-r0) ...20:09
kiwi_29[1mdpkg:[0m error processing archive <PATHTODEB>/PACKAGENAME.deb (--unpack):20:09
kiwi_29 trying to overwrite ‘<FILESYSTEM PATH>’, which is also in package PACKAGENAME220:09
kiwi_29dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)20:09
kiwi_29which means PACKAGENAME is trying to overwrite a file already installed by PACKAGENAME220:10
*** Kyubi <Kyubi!~Kyubi@> has quit IRC20:10
kiwi_29how to I let PACKAGENAME do that... as the changes I made needs PACKAGENAME to overwrite that file20:10
*** Kyubi <Kyubi!> has joined #yocto20:12
*** Kyubi <Kyubi!> has quit IRC20:13
*** Hadi <Hadi!a5e1d930@> has quit IRC20:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto20:22
*** tgamblin <tgamblin!> has quit IRC20:23
*** tgamblin <tgamblin!> has joined #yocto20:26
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has quit IRC20:39
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC20:41
*** pharaon2502 <pharaon2502!> has joined #yocto20:49
codypskiwi_29: I don't think you can directly overwrite things via packages. Some options folks tend to use here: 1. use `ALTERNATIVES` support to have links to files/directories put into place with a priority per package. I'm pretty sure this requires that both packages that "conflict" use ALTERNATIVES. 2. Use the ROOTFS_POSTPROCESS_CMD to move the files around (ie: install both, then use20:53
codypsROOTFS_POSTPROCESS_CMD to have one overwrite the other). This seems kind of dirty, but it may be workable. 3. Avoid making a seperate package and instead use bbappends. This loses some nice isolation properties, but it is pretty straight forward. Can be a bit tricky if you'd like to avoid making the package being bbappended to into something machine/image specific.20:53
kiwi_29thanks codyps  I will try it out . I have been delaying reading update-alternatives stuff more   . Also I might try using bbappend for PACKAGENAME2 and remove the common file and then let PACKAGENAME install the file ..lets c21:01
kiwi_29does that make sense21:07
*** alessioigor <alessioigor!> has joined #yocto21:08
*** alessioigor <alessioigor!> has quit IRC21:09
*** alessioigor <alessioigor!> has joined #yocto21:09
*** wz <wz!> has quit IRC21:19
*** T_UNIX <T_UNIX!> has quit IRC21:22
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto21:31
v0nif my board is a well known commercial board but with a custom in-house designed daughter board, is it best if I define my own machine?21:33
*** pharaon2502 <pharaon2502!> has quit IRC21:49
*** kiwi_29 <kiwi_29!> has quit IRC21:53
*** kiwi_29 <kiwi_29!> has joined #yocto21:53
*** kiwi_29 <kiwi_29!> has joined #yocto21:54
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto22:00
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC22:01
*** aidanh_ is now known as aidanh22:01
*** konsgnxx <konsgnxx!> has quit IRC22:08
*** vineela <vineela!~vtummala@> has quit IRC22:15
*** mbulut <mbulut!> has quit IRC22:17
*** kiwi_29 <kiwi_29!> has quit IRC22:17
*** alessioigor <alessioigor!> has joined #yocto22:20
*** kiwi_29 <kiwi_29!> has joined #yocto22:20
*** alessioigor <alessioigor!> has quit IRC22:20
*** mbulut <mbulut!> has joined #yocto22:21
*** vineela <vineela!vtummala@nat/intel/x-uhcggmgzbcbxaxju> has joined #yocto22:21
*** tgoodwin <tgoodwin!> has quit IRC22:22
*** alessioigor <alessioigor!> has joined #yocto22:23
*** alessioigor <alessioigor!> has joined #yocto22:24
*** alessioigor <alessioigor!> has quit IRC22:26
*** amerigo <amerigo!uid331857@gateway/web/> has joined #yocto22:30
*** NiksDev <NiksDev!~NiksDev@> has quit IRC22:37
*** goliath <goliath!> has quit IRC22:48
*** psiva87 <psiva87!> has quit IRC22:52
*** extor <extor!extor@unaffiliated/extor> has quit IRC22:52
*** Ru3D3e <Ru3D3e!> has quit IRC23:02
*** vineela <vineela!vtummala@nat/intel/x-uhcggmgzbcbxaxju> has quit IRC23:08
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:11
*** vineela <vineela!~vtummala@> has joined #yocto23:30
*** falk0n <falk0n!> has quit IRC23:43
*** falk0n <falk0n!> has joined #yocto23:45
*** kiwi_29 <kiwi_29!> has left #yocto23:47
*** kiwi_29 <kiwi_29!> has joined #yocto23:47
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto23:51
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC23:52

Generated by 2.17.2 by Marius Gedminas - find it at!