**** BEGIN LOGGING AT Wed Dec 09 02:59:56 2020 Dec 09 07:27:00 Weird. 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. Dec 09 07:56:28 good morning Dec 09 07:58:30 good morning Dec 09 08:45:42 good morning Dec 09 08:51:34 Good Morning everyone! Dec 09 08:51:34 Quick 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? Dec 09 08:55:17 manuel1985: there isn't a class that does that, no Dec 09 08:55:29 devupstream can be used to building latest git for a specific recipe Dec 09 08:55:44 or if a recipe uses git already then just setting SRCREV=${AUTOREV} will grab HEAD Dec 09 08:55:53 (poky-bleeding is an example of this) Dec 09 08:57:43 Found it, thanks: https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/devupstream.bbclass Dec 09 09:01:31 devupstream has some gotchas, doesnt work well with native yet for example Dec 09 09:12:14 has been meta-yocto layer renamed? https://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#user-configuration Dec 09 09:12:52 is meta-poky now maybe? Dec 09 09:13:59 I can see the sample files in meta-poky/conf/ folder Dec 09 09:15:38 I'm asking this because I cannot see any reference to 'meta-poky' in the oe-setup-builddir script Dec 09 09:17:03 wyre: are you **really** building poky 1.7? Dec 09 09:17:04 ohh, so there is a .templateconf to fix the path ... 🤔 Dec 09 09:17:13 qschulz, upps, sorry Dec 09 09:19:09 wyre: if you want to document yourself, please use up-to-date documentation or documentation related to the version you'll be using Dec 09 09:19:50 poky 1.7 is atrociously old (6yo) Dec 09 09:20:10 https://wiki.yoctoproject.org/wiki/Releases <-- released october 2014 Dec 09 09:20:21 it's closer to the first release of Yocto than today's Dec 09 09:20:30 qschulz, yes, you are right, I'm sorry, I just googled about the TEMPLATECONF variable and I went to that outdated docs Dec 09 09:20:36 wyre: :) Dec 09 09:20:48 google is basically sabotaging our docs Dec 09 09:20:56 just always replace the version in the URL with 'latest' Dec 09 09:20:58 wyre: https://docs.yoctoproject.org/ref-manual/ref-variables.html Dec 09 09:21:48 ndec: should we put a big red header on documentation still hosted on https://www.yoctoproject.org/docs/ to say that it is outdated? Dec 09 09:21:57 qschulz, so according to .templateconf script TEMPLATECONF will be meta-poky/conf if there not exist previously, right? Dec 09 09:22:39 i don't think meta-poky shipped that file Dec 09 09:23:27 rburton, https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/.templateconf?h=dunfell Dec 09 09:23:37 and .templateconf is sourced in oe-setup-builddir Dec 09 09:23:51 ah top level, right Dec 09 09:24:07 qschulz, also I cannot find TEMPLATECONF variable in the ref-variables 😆 Dec 09 09:25:40 if you're making a custom distro then https://github.com/rossburton/customdistro might be useful Dec 09 09:27:59 rburton, I was actually trying to understand how `require` directive works, because according to the example config https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/bblayers.conf.sample?h=dunfell BBPATH = "${TOPDIR}" but TOPDIR is the folder where I've run bitbake ... so I don't know how is fetching core-image-minimal.bb with that relative path https://youtu.be/nqHylLP2NmA Dec 09 09:30:08 I 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 🤔 Dec 09 09:32:41 so ... how can require fetch something that it's inside of ../meta/recipes-core/images/ ? Dec 09 09:33:24 require is given a path relative to either the current directory or the "root" directory of any layer Dec 09 09:34:26 wyre: BBPATH is typically extended in each layers conf/layer.conf file. Dec 09 09:34:40 qschulz: do you mean here for example: https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html ? Dec 09 09:36:14 qschulz, the current directory where recipe is placed? Dec 09 09:36:35 my recipe is in my own layer Dec 09 09:37:48 I mean, core-image-minimal.bb is in poky/meta/recipes-core/images/ Dec 09 09:37:56 and my recipe has a completely different path Dec 09 09:38:05 it's at the same level than poky Dec 09 09:38:08 folder Dec 09 09:39:04 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' Dec 09 09:40:03 olani[m], so you mean that poky/meta/ is already appended to BBPATH? Dec 09 09:40:05 wyre: require recipes-core/images/core-image-minimal.bb in your recipe Dec 09 09:40:27 wyre: the poky git repo is not ONE layer, it's multiple layers Dec 09 09:40:32 poky/meta is one for example Dec 09 09:40:40 wyre: Check it with bitbake -e Dec 09 09:40:41 qschulz, yes, I know, I was trying to understand why this works without giving a deeper path Dec 09 09:41:34 olani[m], you mean `bitbake -e myrecipe` ? Dec 09 09:41:51 wyre: yes, or just bitbake -e for the global environment Dec 09 09:43:08 olani[m], oh, I can see with `bitbake -e | grep "^BBPATH"` Dec 09 09:44:23 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. Dec 09 09:51:25 olani[m], there are 24k lines in the bitbake -e output Dec 09 09:51:45 should I search for BBPATH pattern? Dec 09 09:52:21 wyre: So use something like 'grep -B30 "^BBPATH"' or less and search for ^BBPATH= Dec 09 09:52:57 I tend to output bitbake -e to a tempfile so I don't have to rerun bitbake for each search pattern change Dec 09 09:53:04 or use a pager such as `less` and look for BBPATH= and just look up in the pager Dec 09 09:54:57 qschulz, yes, I've used that method 😄 Dec 09 09:55:34 then ... why TEMPLATECONF is not the ref-variables list? Dec 09 09:55:48 yo dudX Dec 09 09:58:07 wyre: it seems TEMPLATECONF is an environment variable that is used by the script you source before building Dec 09 09:58:31 hence it's not really a variable that can be used in "normal" conf files? Dec 09 09:58:34 It is mentioned in the ref manual, but not in the variable index. Dec 09 09:58:35 hence/thus Dec 09 09:58:41 LetoThe2nd: o/ Dec 09 09:59:05 so it's an internal variable which is not intended to be set by the final user, I see Dec 09 10:00:27 wyre: no, what i meant is, it's not a variable you can set in a "Yocto" conf file, bbclass or recipe Dec 09 10:00:38 (from a very quick glance) Dec 09 10:00:50 oh, I see Dec 09 10:00:52 so it IMHO does not have its place in the variable index Dec 09 10:14:17 I 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)" Dec 09 10:14:33 but the module is loaded in the host system (I'm trying to run it inside the crops container) Dec 09 10:17:04 wyre: you could try the slirp mode as an alternative, "runqemu slirp" Dec 09 10:17:38 wyre: though that doesn't necessarily work for all usecases Dec 09 10:17:41 smurray, oh, it worked, what's the difference between slirp and qemuarm? Dec 09 10:18:50 apparently a few days ago it worked with qemuarm I was following the LetoThe2nd's playlist https://youtu.be/nqHylLP2NmA Dec 09 10:18:52 wyre: well, slirp and tap, see https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29 Dec 09 10:19:17 wyre: were you running inside crops at that time? Dec 09 10:19:42 smurray, I'd say so Dec 09 10:19:44 wyre: runqemu defaults to tap, which needs to be able to sudo to root Dec 09 10:20:48 smurray, so I can combine qemuarm with slirp, right? Dec 09 10:21:56 wyre: 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" Dec 09 10:25:45 smurray, I'd say I've followed the LetoThe2nd video inside a crops container and it worked using the same command 🤔 Dec 09 10:26:36 wyre: I can't say, you'll have to investigate locally what would have changed Dec 09 10:32:47 is there a way of exctracting a distinct list of liceneses and/or the licenses themselves? Dec 09 10:36:09 I'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 there Dec 09 10:36:34 is it better to get them from the final image instead? Dec 09 10:43:58 carlsb3rg: i'd work through https://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle and see what fits your needs. Dec 09 10:48:14 ok...thanks...I'll read that Dec 09 11:43:41 why if I'm building this core-image-minimal https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/images/core-image-minimal.bb?h=warrior the image does not contain systemd? Dec 09 11:43:56 is it not being appended? Dec 09 11:48:45 wyre: what gives you the idea that it should be? Dec 09 11:49:12 LetoThe2nd, line 12? Dec 09 11:49:45 wyre: seriously, that idea is so extremely far fetched that i cannot believe you even tried to read the line. Dec 09 11:50:42 wyre: with that, i hereby redirect you to https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-systemd-exclusively Dec 09 11:50:53 wyre: as well as https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj Dec 09 11:51:03 * LetoThe2nd is silent again then. Dec 09 11:55:39 Hmm, at what point in rootfs creation is permissions set? Looking at e.g. /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. Dec 09 11:56:40 At 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. Dec 09 11:58:10 LetoThe2nd, according this https://github.com/openembedded/bitbake/blob/master/lib/bb/utils.py#L970 bb.utils.contains() is checking if the variable DISTRO_FEATURES contains the values specified Dec 09 11:58:59 wyre: absolutely correct. and? Dec 09 11:59:25 if DISTRO_FEATURES doesn't contain systemd is not appending it? Dec 09 12:00:18 erbo: That is handled by pseudo, the fakeroot tool used by bitbake. If I understand your question correctly. Dec 09 12:01:23 wyre: *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. Dec 09 12:01:50 olani[m]: is it done in the same way regardless if I'm building a wic image or .ext3 file? Dec 09 12:02:03 wyre: please forgive me if i put you on brain ignore now. have fun. Dec 09 12:02:20 erbo: permissions are handled before images are involved Dec 09 12:03:05 erbo: 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 warnings Dec 09 12:04:26 rburton: should the files in tmp/work/*/util-linux have the correct permissions (owned by root) then? Dec 09 12:04:30 no Dec 09 12:04:41 you're a normal user, how would you write a file owned as root? :) Dec 09 12:04:50 (this is the pseudo magic) Dec 09 12:04:55 right, I'm stupid :) Dec 09 12:05:26 pseudostupid. Dec 09 12:05:30 is that even a word? Dec 09 12:05:35 it is now Dec 09 12:06:51 \m/ Dec 09 12:14:32 kanavin_home: we did see one repro failure with your world change: https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20201208-y9g00bvx/packages/diff-html/ - looks like a sorting issue... Dec 09 12:17:09 kanavin_home: also, I've been thinking, it would be handy if the ptest runs on the autobuilder shows warnings upon regressions? Dec 09 12:27:07 paulbarker: I've queued that revert we discussed since I'd like to build M1 and I think it should be included Dec 09 12:29:59 RP: would you accept revert of https://lists.openembedded.org/g/bitbake-devel/message/11835 as well if I send it? Dec 09 12:31:38 JaMa: good question, I'm frustrated there is no response too :( Dec 09 12:32:51 JaMa: yes, lets revert it Dec 09 12:33:16 JaMa: want me just to do it? Dec 09 12:33:39 please do if you can Dec 09 12:33:52 I don't have better explanation than what I've used in the e-mail Dec 09 12:34:34 RP: yeah, those sorting issues are notoriously non-reproducible ;), I haven't seen this one in any of my tests Dec 09 12:35:10 RP: if you add it to the exclusion list, please also add the link to the repro-fail directory where artefacts and diff can be found Dec 09 12:35:38 non-reprodible non-reproducibility :) Dec 09 12:35:54 extra level of indirection, my head can barely cope Dec 09 12:36:15 kanavin_home: join me in the pseudostupid club :) Dec 09 12:37:09 kanavin_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 -next Dec 09 12:37:33 RP: as for ptest, I wanted to again try to make it a hard failure Dec 09 12:37:58 kanavin_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 warnings Dec 09 12:38:05 RP: from what I have seen, it's just exclusing lttng-tools-ptest, and figuring out the intermittent valgrind failures Dec 09 12:38:30 kanavin_home: if we could at least stop anything else regressing (and spot it), that would be a big win Dec 09 12:38:49 RP: sure, so warning == failures? that would be easier than warning == more failures than before. Dec 09 12:38:56 kanavin_home: I don't particuarly want to remove lttng from tests as a large chunk of them do pass Dec 09 12:39:13 kanavin_home: warning == failures no != vlagrind/lttng ? Dec 09 12:39:27 RP: that would work Dec 09 12:39:48 kanavin_home: that would let us stop regressing I think Dec 09 13:23:13 Ah, so I've narrowed my file permission issue down to the use of --exclude-path in the wks file used for wic image creation. Dec 09 13:23:40 If I don't use --exclude-path all is good, if I do use it the files will have the wrong permissions. Dec 09 13:24:19 I seem to recall reading something about pseudo and ignore dirs etc changing for this release, so I'm off to do some reading about that Dec 09 13:48:35 Ah, there's already a bug for this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14129 Dec 09 14:37:35 how to get rid of SDK generation "locale archive not found" problem? https://pastebin.com/FdhgaJLR Dec 09 14:38:49 When 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 ? Dec 09 14:44:13 yann: you better add "asking for a friend" ;-) Dec 09 14:44:41 yann: I might want to manually bump the revision of a package without renaming the recipe, in which case a build wouldn't be retriggered Dec 09 14:45:01 I see very little benefit and a very implicit side effect Dec 09 14:45:41 but I am probably missing a valid use case so please let us know Dec 09 14:46:39 qschulz: changing the revision would change the hash anyway, right ? Dec 09 14:47:36 yann: if it were me I'd probably do it with PREMIRRORS then that might keep the same hash Dec 09 14:53:34 yann: quick and dirty testing, just changing the SRC_URI will not retrigger a build Dec 09 14:53:35 RP: 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. Dec 09 14:54:23 well technically linux-libc-headers shouldn't be impacted right? I mean if it is, bad (as stated in the recipe :) ) Dec 09 14:55:08 I'm pretty much baffled by this: not only does SRC_URI have an impact, but even _remove (from a .bbappend) causes funky effects: https://pastebin.com/Mh47ZCSc Dec 09 14:56:39 qschulz: 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) Dec 09 14:57:37 I'm pretty much baffled by the "_remove of git://github.com/JeffyCN/mirrors.git;branch=kernel;" you can see in the pastebin Dec 09 14:58:00 yann: PREMIRRORS allows you to rewrite SRC_URI without changing the hashes which is what you asked for. Dec 09 14:58:47 RP: I understand, but it's not what I need as a first step Dec 09 14:58:52 yann: 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 too Dec 09 14:59:56 are all these variables https://docs.yoctoproject.org/ref-manual/ref-variables.html intended to use them in recipes? 🤔 Dec 09 15:00:40 wyre: no, some in conf files too Dec 09 15:00:44 wyre: not all, definitely not Dec 09 15:01:04 wyre: some are documented as they're used in the code but you'd most likely not need them Dec 09 15:01:08 RP: I'll see if I can do additional targeted disabling in lttng and sort the valgrind sporadic fails first Dec 09 15:01:14 meta-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: https://pastebin.com/veYfCtNn Dec 09 15:01:23 RP: I don't want more of those exception lists :) would rather have a hard ptest failure Dec 09 15:01:42 RP, qschulz where should I use DISTRO_ variables? Dec 09 15:01:50 yann: it will impact the hash as the hash mechanism is not content aware Dec 09 15:01:57 in the layer conf file? Dec 09 15:01:59 and from this point do_unpack is tainted, and the whole target userspace Dec 09 15:02:46 RP: so I can't restore the original hash without forking meta-rockchip again ? Dec 09 15:03:15 yann: 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 value Dec 09 15:03:26 or lock the hash, that would work too Dec 09 15:04:05 yann: you could try setting SRC_URI[vardepvalue] = "" Dec 09 15:04:27 I 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 :) Dec 09 15:04:47 wyre: in... distros as the name implies? Dec 09 15:05:01 I mean, set in distros, then you can read them from anywhere Dec 09 15:06:43 yann: I think I see what you mean, you want to use the old hash when the upstream has changed to a new url Dec 09 15:06:55 right Dec 09 15:06:56 yann: in that case vardepvalue can probably force things Dec 09 15:07:12 qschulz, but are distros part of a layer? are a type of layers? Dec 09 15:07:17 * RP makes no comment on whether this makes any sense. Dec 09 15:07:18 seems too, it's picky on whitespace though (!) Dec 09 15:07:33 yann: locked sigs is your other option Dec 09 15:07:47 yann: you will have to get whitespace right, yes Dec 09 15:10:13 wyre: if it's not part of a layer, where would you have the distro file? Dec 09 15:16:14 RP: a bad side effect from vardepvalue is that if they change other things (add a new patch) I'll get an inconsistent hash Dec 09 15:16:47 Looks like the safest way is to duplicate the old version of the recipe in our layer Dec 09 15:17:21 But then, is there a good reason to satrt with, to be that picky with SRC_URI contents ? Dec 09 15:17:54 yann: right, you could do something like SRC_URI[vardepvalue] = "${@d.getVar("SRC_URI").replace("XXX", "YYY")}" I guess Dec 09 15:18:34 yann: as I tried to explain above, the algorithm is not context aware, it works for a any variable value including functions Dec 09 15:18:57 I'm sure we could start adding all kinds of special logic into it but which cases matter and which cases don't? Dec 09 15:19:30 yeah, not an easy one Dec 09 15:21:41 qschulz, I don't have the distro file because I've created an example layer with bitbake-layers Dec 09 15:22:10 wyre: you cna't build without a distro ;) Dec 09 15:22:22 I'd start with "anything with a SRCREV or a SRC_URI[*.*sum] can get excluded from SRC_URI[vardepvalue]" Dec 09 15:22:31 qschulz, I'm using right now poky as distro, I think Dec 09 15:22:48 but should I add a distro to my layer? 🤔 Dec 09 15:22:50 wyre: it's defined in your local.conf which distro is used Dec 09 15:23:01 qschulz, yes, I know it Dec 09 15:23:10 I'm pretty sure it's poky Dec 09 15:23:42 wyre: 1) machine conf file, 2) image recipe, 3) distro if poky is not enough/too much Dec 09 15:25:46 qschulz, so I guess there are also some inherit/include mechanisms to manage distros, right? Dec 09 15:27:52 wyre: they are conf files Dec 09 15:28:24 also recipes? 🤔 Dec 09 15:33:31 yann: do we really want to add an maintain such a list of "rules"? Dec 09 15:34:05 yann: I appreciate you have a specific problem now but the answer is no, we don't ;-) Dec 09 15:34:32 Heyo, 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}". Dec 09 15:34:52 Woops, sorry, haven't finished typing. bare with me :) Dec 09 15:35:02 wyre: no, conf files, so work the same way as .conf files Dec 09 15:35:07 e.g. machines Dec 09 15:35:23 obviously, it's not identical but the require/include should work the same way Dec 09 15:38:14 RP: 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 ;) Dec 09 15:39:34 So, 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 an Dec 09 15:39:35 error, 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? Dec 09 15:40:45 Oh, the version of Yocto I am using is 2.2, so quite old by now :/ Dec 09 15:40:49 that 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) Dec 09 15:41:17 yann: you're willing to write and maintain that? ;-) Dec 09 15:42:55 If I had the time :) Dec 09 15:44:13 wouldn't that make a nice SoC topic ? Dec 09 15:46:16 Gundy: is the commit in the master branch or in a different branch? Dec 09 15:47:05 That commit is in the branch "Versions/Neptune", the one specified with "branch=" in SRC_URI. Thanks for taking a look :) Dec 09 15:48:42 Gundy: any reason for using a local git repo instead of externalsrc or devtool? Dec 09 15:48:59 I 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. Dec 09 15:52:13 qschulz: 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't Dec 09 15:52:14 say that I am familiar with it either. Dec 09 15:53:37 Gundy: don't know :man_shrugging: you can have a look in the fetcher python code directly and start debugging from there Dec 09 15:53:58 The 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). Dec 09 15:56:34 I've only ever used local git repo with the git fetcher by using a fixed SRCREV so no idea really :/ Dec 09 16:15:10 qschulz: Thanks though! Yep will continue peeking at git.py Dec 09 16:15:58 0lll Dec 09 16:27:59 RP: was the bitbake.conf revert responsible for the failures yesterday? Dec 09 16:31:24 sgw: no, separate issue Dec 09 16:32:42 sgw: the M1 build looks like a disaster :( Dec 09 16:33:35 * zeddii doesn't remember typing 0lll Dec 09 16:35:12 * RP doesn't understand how master is suddenly so broken Dec 09 16:46:04 sgw, kanavin_home: Its the change to DISTRO_VERSION in poky :( Dec 09 16:46:22 /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 directory Dec 09 16:46:36 both 3.2+snapshot-9826881036191be6ffba98c9bc8a86d1b852ff41/ and 3.2+snapshot-be4e442da1b22e4a0d85cc74f11fec4981207684/ exist Dec 09 16:55:29 RP: this is one of those things that happens every 6 months and gets goofed up from time to time? Dec 09 16:55:59 sgw: no, we just changed the way this worked for reproducibility (oh the irony) Dec 09 16:56:37 Oh boy, Ok, I will not worry about swatting that further than. Dec 09 16:59:00 sgw: right, I'll do something about this, I think I understand some of it now Dec 09 17:32:51 RP: thanks for sorting this :) Dec 09 17:33:22 kanavin_home: np, its actually pretty nasty, fixes to core and to poky Dec 09 17:36:10 kanavin_home: I've pushed some changes so we'll try again for M1 :) Dec 09 17:59:18 I don't understand wic's --ondisk option Dec 09 17:59:30 what's the point of specifying sda or sdb Dec 09 18:01:53 v0n: It can populate the fstab with the mounts Dec 09 18:02:26 oh ok, so that has to be the name that the SD card slot will have on the target machine Dec 09 18:03:42 kanavin_home: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/e9b27e902792abf39ef823f3d028b39e8243c8e3 :) Dec 09 18:08:53 v0n: Ya Dec 09 18:16:12 RP: nice :) Dec 09 18:22:50 Hi everyone, Dec 09 18:26:14 I 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.. Dec 09 19:01:43 Sorry 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 any Dec 09 19:01:44 options to download the complete source and create a DEBUGFS. Thank for any help. Dec 09 19:04:18 Hadi: Yes..... Dec 09 19:06:09 Hadi: IMAGE_GEN_DEBUGFS = "1" Dec 09 19:06:25 Apparently, that variable is not in the manual variable index :/ Dec 09 19:07:00 Hadi: Covered there though: https://docs.yoctoproject.org/dev-manual/dev-manual-common-tasks.html#debugging-with-the-gnu-project-debugger-gdb-remotely Dec 09 19:14:13 Thanks 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 >" Dec 09 19:31:51 Hadi: Ah. No I don't think there's anything to do that Dec 09 20:00:25 Hello..I m getting this error when building a distro . The error is inside run.do_rootfs Dec 09 20:00:29 Errors were encountered while processing: Dec 09 20:00:29 /.deb Dec 09 20:00:29 W: --force-yes is deprecated, use one of the options starting with --allow instead. Dec 09 20:00:31 W: No sandbox user '_apt' on the system, can not drop privileges Dec 09 20:00:33 E: Sub-process dpkg returned an error code (1) Dec 09 20:00:57 Not able to understand how to debug this as part of do_rootfs as there is no more details.. How to get more info or debug Dec 09 20:08:50 kiwi_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. Dec 09 20:09:48 thanks codyps I looked log.do_rootfs in detail and found this Dec 09 20:09:50 Unpacking PACKAGENAME (0.42.1-r0) ... Dec 09 20:09:50 [1mdpkg:[0m error processing archive /PACKAGENAME.deb (--unpack): Dec 09 20:09:51 trying to overwrite ‘’, which is also in package PACKAGENAME2 Dec 09 20:09:52 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Dec 09 20:10:11 which means PACKAGENAME is trying to overwrite a file already installed by PACKAGENAME2 Dec 09 20:10:36 how to I let PACKAGENAME do that... as the changes I made needs PACKAGENAME to overwrite that file Dec 09 20:53:53 kiwi_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 use Dec 09 20:53:54 ROOTFS_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. Dec 09 21:01:58 thanks codyps I will try it out . I have been delaying reading update-alternatives stuff ..no more . Also I might try using bbappend for PACKAGENAME2 and remove the common file and then let PACKAGENAME install the file ..lets c Dec 09 21:07:58 does that make sense Dec 09 21:33:31 if 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? Dec 10 02:14:13 How to control what goes into the rpm-src package. I am using autotool. I am not sure if aututool or package.bbclass populate the $WORKDIR/package/usr/src/. Currently it only coping some *.c and header files. I want copy more files. How can I do that? Thanks **** ENDING LOGGING AT Thu Dec 10 02:59:56 2020