Wednesday, 2020-12-16

*** mbulut <mbulut!> has quit IRC00:01
*** dakhouya <dakhouya!> has quit IRC00:12
*** kiwi_29 <kiwi_29!> has quit IRC00:16
*** leon-anavi <leon-anavi!~Leon@> has quit IRC00:39
*** kiwi_29 <kiwi_29!> has joined #yocto00:41
v0ncodyps: so essentially if I want to let my customers build their own application for the target without sharing sensitive stuffs (e.g. the daughterboard or in-house apps) I can share the distro layer to them and ask them to build for the "beaglebone(-yocto)" machine, while I would be using a custom machine on my side.01:02
*** kiwi_29 <kiwi_29!> has quit IRC01:05
*** kiwi_29 <kiwi_29!> has joined #yocto01:05
*** MatheusR <MatheusR!~matheus.r@> has joined #yocto01:45
*** vineela <vineela!~vtummala@> has quit IRC01:46
*** fury is now known as furysox01:50
*** furysox is now known as fury01:50
*** paulg <paulg!> has quit IRC01:50
*** goliath <goliath!> has quit IRC01:52
*** kiwi_29 <kiwi_29!> has quit IRC01:58
*** paulg <paulg!> has joined #yocto01:59
*** kiwi_29 <kiwi_29!> has joined #yocto02:02
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:04
*** kiwi_29 <kiwi_29!> has quit IRC02:07
*** kiwi_29 <kiwi_29!> has joined #yocto02:08
*** paulg <paulg!> has quit IRC02:11
*** MatheusR <MatheusR!~matheus.r@> has quit IRC02:11
*** kaspter <kaspter!~Instantbi@> has quit IRC02:34
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:34
zeddiiRP: somehow I ended up with a temp commit and the push bounced on non-ff, and I didn't notice.02:38
*** cbrake1 <cbrake1!cbrakematr@gateway/shell/> has quit IRC02:38
zeddiiI'll resend.02:38
*** kiwi_29 <kiwi_29!> has quit IRC02:39
*** khem <khem!khemmatrix@gateway/shell/> has quit IRC02:39
*** khem <khem!khemmatrix@gateway/shell/> has joined #yocto02:39
*** khem is now known as Guest3923902:40
*** kiwi_29 <kiwi_29!> has joined #yocto02:40
*** cbrake1 <cbrake1!cbrakematr@gateway/shell/> has joined #yocto02:42
*** kiwi_29 <kiwi_29!> has quit IRC02:44
*** kiwi_29 <kiwi_29!> has joined #yocto02:45
*** paulg <paulg!> has joined #yocto02:49
zeddiiRP: rebased and dropped my debug commit, the patch will be fine now.02:50
*** ericch <ericch!> has quit IRC03:02
*** paulg <paulg!> has quit IRC03:09
*** sakoman <sakoman!> has quit IRC03:10
*** kiwi_29 <kiwi_29!> has quit IRC03:11
*** kiwi_29 <kiwi_29!> has joined #yocto03:19
*** kiwi_29 <kiwi_29!> has quit IRC03:26
*** paulg <paulg!> has joined #yocto03:27
*** kiwi_29 <kiwi_29!> has joined #yocto03:32
*** paulg <paulg!> has quit IRC03:33
*** paulg <paulg!> has joined #yocto03:36
*** kiwi_29 <kiwi_29!> has quit IRC03:39
*** paulg <paulg!> has quit IRC03:42
*** ahadi <ahadi!> has quit IRC03:43
*** gpanders <gpanders!> has quit IRC03:43
*** gpanders <gpanders!> has joined #yocto03:44
*** ahadi <ahadi!> has joined #yocto03:45
*** paulg <paulg!> has joined #yocto03:47
*** gpanders <gpanders!> has quit IRC03:51
*** gpanders <gpanders!> has joined #yocto03:51
*** kiwi_29 <kiwi_29!> has joined #yocto04:00
*** kpo_ <kpo_!> has quit IRC04:12
*** kpo_ <kpo_!> has joined #yocto04:12
*** paulg <paulg!> has quit IRC04:12
*** kiwi_29 <kiwi_29!> has quit IRC04:33
*** kiwi_29 <kiwi_29!> has joined #yocto04:34
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:37
*** paulg <paulg!> has joined #yocto04:44
*** kiwi_29 <kiwi_29!> has quit IRC04:48
*** adelcast <adelcast!~adelcast@2806:108e:1a:9622:639:45d7:75dd:768b> has quit IRC04:52
*** jobroe <jobroe!> has joined #yocto04:52
*** kiwi_29 <kiwi_29!> has joined #yocto04:57
*** kiwi_29 <kiwi_29!> has quit IRC05:01
*** kiwi_29 <kiwi_29!> has joined #yocto05:01
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto05:05
*** kiwi_29 <kiwi_29!> has quit IRC05:08
*** ahadi <ahadi!> has quit IRC05:39
*** ahadi <ahadi!> has joined #yocto05:41
*** kiwi_29 <kiwi_29!> has joined #yocto05:50
*** Kyubi <Kyubi!~Kyubi@> has quit IRC05:51
*** kiwi_29 <kiwi_29!> has quit IRC05:52
*** kiwi_29 <kiwi_29!> has joined #yocto05:52
*** kiwi_29 <kiwi_29!> has quit IRC05:55
*** gnac <gnac!> has quit IRC05:56
*** kiwi_29 <kiwi_29!> has joined #yocto05:58
*** davidinux <davidinux!~davidinux@> has joined #yocto05:59
*** pharaon2502 <pharaon2502!> has joined #yocto06:01
*** kiwi_29 <kiwi_29!> has quit IRC06:01
*** kaspter <kaspter!~Instantbi@> has quit IRC06:02
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:03
*** alessioigor <alessioigor!> has joined #yocto06:11
*** ThomasD13 <ThomasD13!> has joined #yocto06:16
*** AndersD <AndersD!> has joined #yocto06:39
*** beneth <beneth!> has joined #yocto06:44
*** kiwi_29 <kiwi_29!> has joined #yocto07:02
*** w00die <w00die!~w00die@> has quit IRC07:06
*** kiwi_29 <kiwi_29!> has quit IRC07:07
*** paulg <paulg!> has quit IRC07:07
*** w00die <w00die!~w00die@> has joined #yocto07:08
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:09
*** paulg <paulg!> has joined #yocto07:11
*** rcoote <rcoote!> has joined #yocto07:14
*** B0ned1ger <B0ned1ger!> has joined #yocto07:25
*** minimaxwell <minimaxwell!> has quit IRC07:28
mcfriskbazel, the holy grail of reproducible builds fails to build reproducibly.. palm, face07:29
*** agust <agust!> has joined #yocto07:30
*** mckoan|away is now known as mckoan07:31
mckoangood morning07:31
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto07:32
*** frsc <frsc!> has joined #yocto07:33
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC07:34
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto07:37
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC07:41
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto07:42
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC07:43
*** B0ned1ger <B0ned1ger!> has quit IRC07:46
*** B0ned1ger <B0ned1ger!> has joined #yocto07:47
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto07:51
*** frwol <frwol!> has joined #yocto07:52
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC07:53
*** rcoote <rcoote!> has quit IRC07:54
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto07:59
*** fl0v0 <fl0v0!> has joined #yocto07:59
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC08:01
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:01
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto08:03
*** dsueiro <dsueiro!uid467101@gateway/web/> has joined #yocto08:14
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC08:15
*** zyga <zyga!> has joined #yocto08:16
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto08:16
*** tnovotny <tnovotny!> has joined #yocto08:18
dsueiroWe are having some problems with our CI system where the `do_populate_sysroot_setscene: Fetcher failure` task fails because of instability in our sstate cache mirror. Bitbake is able to recover by re-building the recipe and the whole build finishes successfully. But because of this task failure, bitbake returns non-zero making our CI not happy. Is there any specific reason to have bitbake returning non-zero in this case?08:21
*** kpo_ <kpo_!> has quit IRC08:22
*** kpo_ <kpo_!> has joined #yocto08:23
*** Klox048093186316 <Klox048093186316!> has quit IRC08:25
*** alessioigor <alessioigor!> has quit IRC08:26
*** frsc <frsc!> has quit IRC08:27
paulbarkerdsueiro: That's a known issue. I've looked a couple of times for a good fix but bitbake really assumes that the sstate mirror is reliable08:32
*** luneff <luneff!~yury@> has joined #yocto08:33
paulbarkerdsueiro: A workaround is to run `bitbake --setscene-only ${IMAGES} || true` first to fetch from the sstate cache ignoring errors08:35
paulbarkerThen `bitbake --skip-setscene ${IMAGES}` to build anything which couldn't be fetched from sstate08:35
luneffI'm compiling Yocto with DEBUG_BUILD = "1" and I got error with ltrace (error: 'data' may be used uninitialized in this function) which is probably related to compiler flags. Any workaround?08:35
luneffprobably DEBUG_BUILD = "0" in ltrace's bbappend?08:37
stefan-schmidt[mgood morning08:38
*** frsc <frsc!> has joined #yocto08:40
dsueiropaulbarker: Thanks for the tip. Is there anything that can be made to trick bitbake in this case?08:41
*** luneff <luneff!~yury@> has quit IRC08:43
paulbarkerdsueiro: Trick bitbake in what sense?08:45
*** mbulut <mbulut!> has joined #yocto08:46
*** minimaxwell <minimaxwell!> has joined #yocto08:46
*** minimaxw1ll <minimaxw1ll!> has joined #yocto08:49
*** amitk_ is now known as amitk08:50
*** minimaxw1ll <minimaxw1ll!> has left #yocto08:50
*** minimaxwell <minimaxwell!> has quit IRC08:50
*** minimaxwell <minimaxwell!> has joined #yocto08:50
*** wz <wz!> has joined #yocto08:51
dsueiropaulbarker: for a setscene task the fetcher raise the failure as a warning or info instead of an error. I didn't have time to look at the code to check if this is feasible.08:57
*** sno <sno!> has joined #yocto08:58
paulbarkerdsueiro: It's feasible as a local patch, needs some more testing & discussion to upstream that change though09:02
*** luneff <luneff!~yury@> has joined #yocto09:12
*** gpanders <gpanders!> has quit IRC09:14
luneffgot disconnected badly... DEBUG_BUILD = "0" helped :-)09:14
paulbarkerluneff: I recommend the free tier of IRCCloud to avoid that09:15
paulbarkerluneff: It's probably worth checking if the warning is a real problem, if there is a chance the variable may be used uninitialized and it's not just the compiler getting confused09:16
*** chris_ber <chris_ber!~quassel@> has joined #yocto09:16
paulbarkerIf it's a real warning fixing it in ltrace would be the way to go09:16
paulbarkerIf not, then yes changing the flags via a bbappend may work. I'm not familiar with `DEBUG_BUILD`09:16
*** frwol <frwol!> has quit IRC09:19
*** frwol <frwol!> has joined #yocto09:19
luneffthank you, paulbarker :-)09:20
chris_bergo-recipe: my recipe will not download external resource, what i am doing wrong?
paulbarkerchris_ber: DEPENDS is a list of Yocto packages which your recipe depends on09:22
chris_berpaulbarker: i tried with this line and without09:22
paulbarkerchris_ber: What error do you get without it?09:23
chris_bersee bottom09:25
chris_berERROR: Nothing PROVIDES ''09:25
paulbarkerSo without the `DEPENDS +=  ""` line in your recipe you still get that error?09:26
chris_beryes, i will check it again, give me a second09:27
*** gpanders <gpanders!> has joined #yocto09:30
chris_beri updated the code link, but basically:  "static-server.go:10:2: cannot find package "" in any of:"09:34
paulbarkerchris_ber: You'll need to look how recipes for other software written in Go handles this09:37
chris_beryeah, but i only can find hello world examples ...09:37
*** sno <sno!> has quit IRC09:39
paulbarkerchris_ber: The go world seems to be very keen on vendoring dependencies and including them in the git repository for a project09:40
paulbarkerSo there may not be many examples for what you want to do sadly. Go devs are crazy09:42
chris_berby this u mean i have to download the deps and it directly to the git-repoß09:42
chris_ber*add it directly09:42
paulbarkerThat seems to be usual for things written in Go. It's not something I use though so I'm very much looking at it as an outsider and thinking "this is crazy, just point at the upstream repository and version for each dependency"09:43
paulbarkerI'm not too familiar with if/how bitbake can handle this09:44
chris_beròk, thx for your tips. I am new to go :)09:44
paulbarkerFor Rust I know folks wrote a crate fetcher for bitbake which makes life very easy09:44
*** dreyna <dreyna!> has quit IRC09:45
paulbarkerchris_ber: For Rust you can do something like this as the crate fetcher exists:
paulbarkerA "crate" is just a Rust library09:46
paulbarkerI'd love to see something similar for Go but it's not something I use or have a deep knowledge of so I'm not able to put that together myself09:46
*** camus <camus!~Instantbi@> has joined #yocto09:59
*** goliath <goliath!> has joined #yocto10:00
*** kaspter <kaspter!~Instantbi@> has quit IRC10:00
*** camus is now known as kaspter10:00
*** TPRoberts <TPRoberts!~TPRoberts@> has joined #yocto10:06
*** dleppich <dleppich!~Thunderbi@> has quit IRC10:06
*** dleppich <dleppich!~Thunderbi@> has joined #yocto10:07
*** gpanders <gpanders!> has quit IRC10:14
*** gpanders <gpanders!> has joined #yocto10:41
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC10:42
*** moto-timo <moto-timo!> has joined #yocto10:42
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto10:42
*** amerigo <amerigo!uid331857@gateway/web/> has joined #yocto10:52
*** mbulut <mbulut!> has quit IRC10:56
*** gpanders <gpanders!> has quit IRC10:57
*** sno <sno!> has joined #yocto11:01
*** oberstet <oberstet!~oberstet@> has joined #yocto11:02
LetoThe2ndsuper weird situation. i rsynv -av'ed a relatively big build directory. now the whole process of copying seems to have finished already, but the shell is completely busy cranking away with listing all files.11:15
LetoThe2ndsolution: tmux detach, tmux attach. it was literally just the output that was swamped.11:16
*** manuel1985 <manuel1985!~manuel@> has joined #yocto11:18
*** luneff <luneff!~yury@> has quit IRC11:29
manuel1985Can I make yocto produce some overview of all the partitions there are with their offsets and sizes?11:29
manuel1985We're updating from zeus to dunfell and using mender on a Jetson TX2. When we deploy a dunfell artifact, everything seems to run fine. But I still want to check to rule out problems which are there but which we just didn't face yet.11:31
*** hpsy <hpsy!~hpsy@> has joined #yocto11:31
*** mbulut <mbulut!> has joined #yocto11:35
*** goliath <goliath!> has quit IRC11:41
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC12:05
RPkanavin_home, rburton: any idea why the patches in master-next would cause arm ptests and ltp to timeout?12:10
rburtonnot off the top of my head12:12
RPnot very helpful12:13
RPI'm going to have to bisect it aren't I? :/12:14
rburtonpresumably the ptest log is vanished12:15
RPrburton: shouldn't be12:15
rburtonwondering if it hung somewhere12:15
RPrburton: although I can't ssh into that machine :/12:17
rburtonthat's not a good start12:17
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto12:18
rburtonhm my ssh is hanging too, and i've definitely connected to that in the past12:18
RPrburton: I've paused it and run the build on the other worker12:18
RPrburton: that worker does seem to have "issues" :(12:19
rburtonI was going to try selftest on that machine today now in theory the last blocker is fixed in next12:19
RPrburton: I'm declining to comment on that ;-)12:19
*** kpo_ <kpo_!> has quit IRC12:20
RPkanavin_home: we have a definite intermittent reproducibility issue in u-boot and grub-efi btw. I merged your filter patches but I think I'll now regret it due to those :(12:21
*** kpo_ <kpo_!> has joined #yocto12:21
kanavin_homeRP: then you should add those to exception lists?12:21
kanavin_homeRP: I don't know what could cause arm64 timeouts :(12:21
rburtoni worry about the syslinux patch as that changed what builds on arm64 but it *shouldn't* have hung12:22
RPIt could be the worker has some issue...12:23
RPkanavin_home: the exception list is probably the way forward if we don't have anyone to fix them. I keep thinking I should have a look at fixing it12:24
LetoThe2ndmanuel1985: the partitions are not per se generated by yocto - if at all, then by wic.12:33
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto12:36
qschulzLetoThe2nd: don't forget about ubi too :)12:38
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC12:38
LetoThe2ndqschulz: good point.12:38
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto12:40
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC12:40
madisoxmanuel1985: The partition layout is controlled by the XML file used by the flashing tools in the L4T BSP.  If you're keeping the same version of L4T over that update, you shouldn't have any issues, but if your're going from, say R32.3.1 to R32.4.3, you may have a problem.  You can compare the layouts by  generating a tegraflash image from each version and diffing the flash.xml files.12:43
*** camus <camus!~Instantbi@> has joined #yocto12:43
*** kaspter <kaspter!~Instantbi@> has quit IRC12:44
*** camus is now known as kaspter12:44
kanavin_homeRP: also please drop opkg update as it has a ptest regression12:48
RPkanavin_home: right, its on my don't merge list12:51
RPkanavin_home: gone locally now12:52
kanavin_homeRP: I couldn't reproduce the AUH failures locally, but I re-started AUH to check once more, and it failed the same way. So I'm going to try the exact sequence that AUH is doing.12:54
RPkanavin_home: I can just about see how it could happen with the change as I mentioned last night12:54
RPkanavin_home: less sure how to fix it12:54
* LetoThe2nd feels very auhbombed!12:55
manuel1985LetoThe2nd: Got it, just sloppy wording ;)12:55
kanavin_homeRP: that is what I tried, and os-release rebuilt correctly. But maybe you could also try something locally?12:55
LetoThe2ndmanuel1985: nah, its not about the wording. just as madisox pointed out, there's often custom add-on stuff that does things like this. hence its really needed to go digging first which mechanisms are actually being used.12:56
manuel1985madisox: So you're saying everything boils down to the flash.xml in the tegraflash.{zip,tar.gz}? That's the point of truth? Got it. Unfortunately we are indeed going from L4T 32.3.1 to 32.4.3. But I'm gonna check that flash.xml now.12:57
manuel1985LetoThe2nd: So you're saying that sometimes something else is used for image creation instead wic?13:01
LetoThe2ndmanuel1985: bingo.13:03
*** TPRoberts <TPRoberts!~TPRoberts@> has quit IRC13:04
*** kiwi_29 <kiwi_29!> has joined #yocto13:04
*** kaspter <kaspter!~Instantbi@> has quit IRC13:05
*** dleppich <dleppich!~Thunderbi@> has quit IRC13:07
*** dleppich <dleppich!~Thunderbi@> has joined #yocto13:07
*** kiwi_29 <kiwi_29!> has quit IRC13:09
RPkanavin_home: reproduced. "bitbake os-release" then "vi documentation/tools/update*; git commit", then "bitbake os-release -C install"13:10
RPidea being to commit something which doesn't cause a reparse, then rebuild it13:11
*** ak77 <ak77!> has quit IRC13:12
*** ak77 <ak77!> has joined #yocto13:13
madisoxmanuel1985: Yep, the XML file determines the layout used, including for the bootloader update payloads used for the Mender updates.13:16
* manuel1985 is frolocking13:21
*** otavio <otavio!> has joined #yocto13:32
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto13:32
*** BlueBus <BlueBus!5fa87400@> has joined #yocto13:33
BlueBusHi there,13:34
manuel1985madisox: Okay, it seems we're fine. Size attributes remained unchanged throughout the file. Is the tegra flashing tool just putting every partition after the other? I noticed there is not offset attribute.13:34
BlueBusIs it possible to change the override priority of conf/local.conf? I'd like it to be the last thing applied but the values entered there get overwritten by  other layers.13:35
BlueBusThe use case is a development environment for board bring up. I want to be able to experiment in one place and split that into layers once something is working.13:37
manuel1985Also I noticed that, in contrast to the zeus-made, in the dunfell-made tegraflash.tar.gz there is no flash.xml anymore. Only the, which has the variables replaced by their actual values, though. Except for VERFILE, APPFILE and BPFDTB-FILE.13:38
manuel1985BlueBus: This is were the local.conf gets included: As far as I know, all the conf files are taken into account as described in this file, then the resulting state is taken as base for every recipe, unmodified. That is, recipes don't affect each other.13:40
paulbarkerBlueBus: It really depends what you need to override. E.g. all _append actions are applied after all += actions. All _remove actions are applied last of all13:40
*** sakoman <sakoman!> has joined #yocto13:41
manuel1985BlueBus: If you want to change the priority of the individual layers, that is, how they're stacked onto each other: yes, you can define that order somewhere.13:42
*** ssajal <ssajal!> has quit IRC13:42
BlueBusmanuel1985 Thanks, I'm only reffering on the priority for local.conf13:42
* zeddii chugs a coffee13:44
BlueBuspaulbarker: Hm... Perhaps I could make something like work in conf/local.conf.  `VARIABLE_remove=" * "    VARIABLE_append=" the only value set in local.conf which will stay"13:47
BlueBusThe " * "  is supposed to mean "remove all values regardless of what they were" :p13:47
paulbarkerBlueBus: _remove actions are applied last of all. You'd just end up with an empty variable13:47
BlueBusOh, allright :)13:48
paulbarker_forcevariable is a horrible way to hack things but often useful in debugging13:48
*** goliath <goliath!> has joined #yocto13:48
paulbarkerThough I'm not sure on the exact ordering of how that is applied13:48
paulbarkerYMMV, check the `bitbake -e` output if you try it out13:49
BlueBusOuu, _forcevariable looks promising. Will take a look, thanks paulbarker13:49
manuel1985Where is that _append _remove _whatever coming from? Is that Bitbake? Is there a comprehensive list which suffixes are there?13:53
manuel1985Was wondering about that for a long time.13:54
manuel1985Also, you seem to be able to set recipe-variables from the local.conf with PN_<packagename>_varname syntax. Did I get this right?13:54
manuel1985LetoThe2nd: Thanks14:00
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has quit IRC14:01
manuel1985In my source tree, there are two functions: do_compile_tegra186() and do_compile_tegra194(). Do I just call do_compile and BitBake selects the right one based on some variable?14:01
manuel1985I'm wondering if this is yet another BitBake variable naming feature14:02
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has joined #yocto14:02
*** frsc <frsc!> has quit IRC14:02
RPkanavin_home: I think replacing varflags = d.getVarFlags(key, internalflags = True) with varflags = d.getVarFlags(key, internalflags = True, expand=["vardepvalue"]) in get_hash in data_smart fixes i14:03
manuel1985LetoThe2nd: Mind = blown14:07
qschulzLetoThe2nd: GIVE THE SPHINX DOCS :D14:07
LetoThe2ndqschulz: meh.#14:08
LetoThe2ndqschulz: you're right, as always.14:09
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto14:09
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC14:10
*** frsc <frsc!> has joined #yocto14:12
qschulzI have to say though that the search feature is poor for now :/14:12
*** jobroe <jobroe!> has quit IRC14:14
*** ahadi <ahadi!> has quit IRC14:19
*** ahadi <ahadi!> has joined #yocto14:19
*** luneff <luneff!~yury@> has joined #yocto14:25
*** ericch <ericch!> has joined #yocto14:26
luneffis there any quick hack to make systemd-journald logs persistent in Yocto? I tried Storage=persistent in journald.conf, but there's still no logs from the previous boot...14:33
*** kaspter <kaspter!~Instantbi@2409:8a1e:9112:caf0:c5fc:a685:807f:dd36> has joined #yocto14:33
*** ssajal <ssajal!~ssajal@> has joined #yocto14:36
RPluneff: if you do figure it out it would be good to document it. I think there is meta/files/fs-perms-persistent-log.txt vs fs-perms.txt which may or may not help with systemd14:41
luneffconf/bitbake.conf:VOLATILE_LOG_DIR ?= "yes"14:46
luneff"To make the /var/log directory on the target persistent, use the VOLATILE_LOG_DIR variable by setting it to "no"."14:47
luneffalready documented, just hard to google14:47
*** ThomasD13 <ThomasD13!> has quit IRC14:48
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto14:50
manuel1985You really need to be 100% sober to understand
LetoThe2ndmanuel1985: disagreed.14:52
*** Chep <Chep!~chep@> has joined #yocto14:52
qschulzmanuel1985: always open to suggestions and patches :)14:59
*** roussinm1 <roussinm1!> has joined #yocto15:03
manuel1985I didn't mean to critize the text, it's just that the subject on hand is.. complicated.15:08
qschulzIt is but we can always improve ;)15:10
*** Chep <Chep!~chep@> has left #yocto15:11
kanavin_homeRP: right, thanks for looking into it! This does look like outside of my competence area :)15:19
RPkanavin_home: I wasn't sure which way it would lead but I think its a bitbake bug :/15:23
*** gpanders <gpanders!> has joined #yocto15:37
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:38
*** davidinux <davidinux!~davidinux@> has quit IRC15:41
*** davidinux <davidinux!~davidinux@> has joined #yocto15:41
*** gpanders <gpanders!> has quit IRC15:42
*** gpanders <gpanders!> has joined #yocto15:43
*** BlueBus <BlueBus!5fa87400@> has quit IRC15:45
*** AndersD <AndersD!> has quit IRC15:47
*** luneff <luneff!~yury@> has quit IRC15:48
*** King_InuYasha is now known as Conan_Kudo15:51
*** Conan_Kudo is now known as King_InuYasha15:51
*** mbulut <mbulut!> has quit IRC15:51
*** kpo_ <kpo_!> has quit IRC15:51
*** kpo_ <kpo_!> has joined #yocto15:53
*** gpanders <gpanders!> has quit IRC15:53
*** gpanders <gpanders!> has joined #yocto15:59
*** davidinux <davidinux!~davidinux@> has quit IRC16:01
*** armpit <armpit!~armpit@2601:202:4180:a5c0:475:ced5:fdcb:90c5> has quit IRC16:01
*** davidinux <davidinux!~davidinux@> has joined #yocto16:03
*** roussinm1 <roussinm1!> has quit IRC16:04
*** frwol <frwol!> has quit IRC16:05
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC16:06
*** otavio <otavio!> has joined #yocto16:07
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto16:07
*** hpsy <hpsy!~hpsy@> has quit IRC16:23
*** wz <wz!> has quit IRC16:26
*** Kyubi <Kyubi!> has joined #yocto16:28
*** hpsy <hpsy!~hpsy@> has joined #yocto16:32
*** gpanders <gpanders!> has quit IRC16:38
*** chris_ber <chris_ber!~quassel@> has quit IRC16:38
*** frsc <frsc!> has quit IRC16:39
*** hpsy <hpsy!~hpsy@> has quit IRC16:41
paulbarkerRP: I have what looks like a fix for the pseudo pyc file generation. It's a patch to pseudo itself to set the environment variable `PYTHONDONTWRITEBYTECODE` when executing a program under pseudo16:42
*** gpanders <gpanders!> has joined #yocto16:42
paulbarkerShould I sent the patch against pseudo? Or a patch against oe-core carrying the patch next to the recipe?16:42
RPpaulbarker: isn't that 3.8 onwards only?16:42
paulbarkerRP: It's documented for 3.5:
*** fl0v0 <fl0v0!> has quit IRC16:44
paulbarker says "New in 2.6"16:44
*** gpanders <gpanders!> has quit IRC16:44
RPpaulbarker: hmm, ok, fair enough. I could have sworn I looked and the option we needed was 3.816:45
*** gpanders <gpanders!> has joined #yocto16:45
RPpaulbarker: ok, lets add a patch to the pseudo repo and update. I can add a couple of other patches we have in OE to there too, clean things up16:46
*** B0ned1ger <B0ned1ger!> has quit IRC16:46
paulbarkerIt does the job. If I run python in do_compile and import I get a pyc file, if I do the same in do_install for a file I don't get a pyc file16:46
RPpaulbarker: makes sense, I'm just wondering how I missed that :)16:46
*** B0ned1ger <B0ned1ger!> has joined #yocto16:46
paulbarkerNo measurable difference in build time for core-image-sato16:47
RPpaulbarker: good, I thought that would be the case but good to confirm16:47
paulbarkerBuilding on my machine from scratch (just downloads populated) was 63m27s before the change and 63m45s afterwards, probably just noise and other activity16:48
paulbarkerRP: I'll send a revert for the change in oe-core which added ${COREBASE}/meta to the ignored paths and send a separate patch against pseudo with the fix16:50
RPpaulbarker: thanks.16:51
RPpaulbarker: thinking about this, shouldn't we just export PYTHONDONTWRITEBYTECODE in FAKEROOTENV in bitbake.conf?16:51
*** frsc <frsc!> has joined #yocto16:52
paulbarkerRP: I didn't know that was possible. I added a `SETENV()` call within the pseudo C code16:52
paulbarkerLet me look, that would probably be a neater solution16:53
RPpaulbarker: we export anything in that variable into the pseudo environment16:53
paulbarkerI now have a nice recipe I can use to quickly test16:53
*** Kyubi <Kyubi!> has quit IRC16:53
paulbarkerNot sure if it's suitable for meta-selftest and a test case16:53
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto16:53
RPpaulbarker: if we have one, yes, its suitable16:53
paulbarkerI'll see what I can throw together16:54
RPpaulbarker: thanks, should be a nice simple fix in the end!16:54
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto16:55
RPpaulbarker: I've just send out a patch merging a couple of other patches to the pseudo repo to clean things up16:55
RPparticularly after my comments about reducing patch count the other day :)16:55
paulbarkerRP: I'll move my test recipe to meta-selftest and work up an oeqa test case16:56
RPpaulbarker: thanks, sounds good16:56
paulbarkerHopefully a patch will appear on the list later this evening or tomorrow16:56
*** B0ned1ger <B0ned1ger!> has quit IRC16:58
*** B0ned1ger2 <B0ned1ger2!> has quit IRC16:59
RPrburton, kanavin_home: the retried builds worked so its something wrong with that worker17:00
RPhalstead is looking into it (FWIW halstead, that machine seems to have broken when running builds)17:01
*** B0ned1ger <B0ned1ger!> has joined #yocto17:01
paulbarkerLine lengths in bitbake.conf make me cry17:04
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto17:06
*** frsc <frsc!> has quit IRC17:09
*** mckoan is now known as mckoan|away17:13
kanavin_homeRP: I thought that both ltp and ptest failing is difficult to explain otherwise, unless something introduced a qemu-on-arm-host regression17:18
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has quit IRC17:22
RPkanavin_home: right, the build did complete so I presumed the worker was ok but obviously not17:23
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC17:25
*** kpo_ <kpo_!> has quit IRC17:29
*** kpo_ <kpo_!> has joined #yocto17:30
*** Ad0 <Ad0!~Ad0@> has quit IRC17:30
*** Ad0 <Ad0!~Ad0@> has joined #yocto17:35
*** kiwi_29 <kiwi_29!> has joined #yocto17:48
*** vineela <vineela!vtummala@nat/intel/x-ammgxqezybyatxdq> has joined #yocto17:55
*** kiwi_29 <kiwi_29!> has quit IRC18:02
*** RP <RP!> has quit IRC18:11
*** RP <RP!~RP@2001:8b0:aba:5f3c:96de:80ff:fe6d:2d2b> has joined #yocto18:12
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto18:30
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC18:31
*** armpit <armpit!~armpit@2601:202:4180:a5c0:340d:313d:cd08:87ee> has joined #yocto18:38
*** kaspter <kaspter!~Instantbi@2409:8a1e:9112:caf0:c5fc:a685:807f:dd36> has quit IRC18:41
*** mbulut <mbulut!> has joined #yocto18:45
*** kiwi_29 <kiwi_29!> has joined #yocto18:55
tlwoerneri seem to vaguely recall that using IMAGE_ROOTFS is frowned on outside of do_rootfs(), is that the case?19:00
*** tnovotny <tnovotny!> has quit IRC19:02
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC19:02
*** kiwi_29 <kiwi_29!> has quit IRC19:03
*** vineela <vineela!vtummala@nat/intel/x-ammgxqezybyatxdq> has quit IRC19:03
*** w00die <w00die!~w00die@> has quit IRC19:05
v0nwhat's the best place to put my custom .dts file between recipes-kernel/linux/{,${PN}/,files/}custom.dts?19:07
*** w00die <w00die!~w00die@> has joined #yocto19:07
paulbarkerv0n: Either '${PN}-${PV}', '${PN}' or 'files' directories next to your recipe will work. Which one you choose depends if you need to share the file between different recipes and/or versions19:09
*** Guest39239 is now known as khem19:11
v0npaulbarker: I want the simplest version to add my own kernel dts in my BSP layer, no version distinctions at the moment19:11
*** khem <khem!khemmatrix@gateway/shell/> has quit IRC19:11
*** khem <khem!khemmatrix@unaffiliated/khem> has joined #yocto19:11
*** khem <khem!khemmatrix@gateway/shell/> has joined #yocto19:11
khemzeddii:  if an option in defconfig is set to 'm' and then I add a .cfg where I set it to 'y' it seems that tooling is picking up the one from defconfig which seems not right to me as cfg files should override the defaults isnt it so ?19:12
zeddiinot if something else demands it be a 'm'19:13
paulbarkerv0n: All are equally valid. I'd use ${PN} though in case you add another recipe to the same directory later19:13
zeddii  MTD_UBI(=m) has made it to m19:14
khemzeddii:  there are just two providers19:14
zeddiithe fragment cannot undo that.19:14
zeddiiunless you put in the fragment, the change to mtd_ubi19:15
khemso tooling prefers modules it seems19:15
zeddiithe tooling has no preference19:15
zeddiithat's the kernel config subsystem19:15
khemif one of dependency is a module then it will pick module option19:16
khemyeah I meant kernel tooling19:16
zeddiigotcha even. yes. if a dependency is =m it chains down.19:16
zeddiiwhich is why I enhanced the audit to show it more clearly.19:16
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC19:17
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC19:17
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:d586:eeb0:289:42dd> has joined #yocto19:18
khemyes themessage is pretty neat thanks19:18
khemthere is another issue I was seeing in odroid kernel too let me reproduce that19:18
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:d586:eeb0:289:42dd> has quit IRC19:19
*** dreyna <dreyna!> has joined #yocto19:19
v0npaulbarker: ok thank you. Can I have a package agnostic recipe for any linux for does it have to be package specific like "linux-ti-staging_%.bbappend"?19:23
paulbarkerv0n: Not sure I totally understand your question, but I'll try anyway. "%" acts as a wildcard there19:24
khemwildcards should be used with care19:25
khemthey can get you in trouble down the lane19:25
khemthey bite you when you forget them19:25
paulbarkerkhem is right. Have a think about what you want to achieve, should it be specific to the full recipe name, maybe even the version as well19:26
v0npaulbarker: yes % acts as a wildcard for the version, but what if I want to use my dts for any linux (linux-ti-staging, linux-yocto, whichever kernel)19:26
paulbarkerv0n: % isn't specific to the version19:27
v0npaulbarker: I have a bbb with a custom daughter board on it. I'm writting a bsp layer defining a new machine and I want to apply my custom dts on it. My machine is currently based on "beaglebone" from meta-ti which uses linux-ti-staging.19:27
paulbarkerlinux-%.bbappend will match that but beware as khem says, using that you're effectively saying this append is compatible with any kernel recipe19:28
paulbarkerConsider that in future you may wish to support multiple MACHINEs, etc19:28
khemand also stepping on other peoples toes e.g. in a multi BSP env19:28
paulbarkerSometimes better to be specific even if that leads to a little duplication19:28
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto19:29
v0npaulbarker: can I specify my custom dts from the machine configuration or do I have to bbappend the kernel recipe?19:30
*** vineela <vineela!~vtummala@> has joined #yocto19:30
paulbarkerv0n: Either. I'd say machine config is a better option there19:32
khemzeddii: I am also seeing problem in CONFIG_LOCALVERSION setting in some cases19:33
paulbarkerv0n: We do this for the bbe. The bbe.conf file includes a kernel provider config like
paulbarkerThat config fragment sets the device trees to build19:33
paulbarkerThe BBE layer may be useful for you to review as it's essentially a modified BBB (more RAM, better wifi, etc)19:34
v0npaulbarker: thank you, let me take a look at that!19:36
RPkhem: eglibc is dead, right?19:38
khemRP: yes I attended the burial19:40
RPkhem: I thought so. I'm just being asked some questions about it. Not sure why all of a sudden19:40
khemRP:  yeah it was there in daisy timeframe19:41
khemRP: btw. you must have seen I am toggling a systemd patch based on 247 or 246 we need that patch with latest musl btw. reallocarray patch19:41
RPkhem: I keep trying the 247 patches and they don't pass testing :(19:42
RPkhem: let me add the 246 version to master-next19:42
khemand ask 247 submitter to rebase on top of master-next19:42
khemzeddii:  here is another kernel similar issue
RPkhem: perhaps I should gamble you got it right and add it directly...19:43
*** mbulut <mbulut!> has quit IRC19:44
khemRP:  the patch is already in systemd/master so its ok19:44
khemI have been building with both 246/247 here with no issues, only problem is rebasing conflicts19:45
RPkhem: is master breaks I'll be upset but its in :)19:45
RPworst case its a revert...19:45
khemok let me check19:46
khemok do_patch succeeded for systemd on master so I think we have it right :)19:49
JPEWHmm, what MACHINE should I use for an Intel Atom x5 Z8350?19:50
JPEWMore specifically, a Rock Pi X:
khemgenericx86-64.conf if you use poky19:51
JPEWkhem: Ah, simple enough. Thanks!19:53
khemthats one good thing about intel chips19:56
khembut dont open the hood :)19:56
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto20:07
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto20:14
*** kiwi_29 <kiwi_29!> has joined #yocto20:16
*** B0ned1ger <B0ned1ger!> has quit IRC20:17
*** vineela <vineela!~vtummala@> has quit IRC20:19
smurrayJPEW: the other option would be meta-intel, it might have a specific tuning for those Atoms20:20
smurrayJPEW: we were using meta-intel's intel-corei7-64 machine in AGL, but there's not a lot of demand for x86 support from members so now just qemux86-64 is used with some kernel config additions20:22
*** B0ned1ger2 <B0ned1ger2!> has quit IRC20:23
RobertBerger1@khem: What you see here could be because LINUX_VERSION_EXTENSION and CONFIG_LOCALVERSION are unequal20:39
*** vineela <vineela!vtummala@nat/intel/x-pysxdiupfszcdlfp> has joined #yocto20:41
*** adelcast <adelcast!~adelcast@2806:108e:1a:6659:f716:ab12:f11f:429a> has joined #yocto20:44
*** B0ned1ger <B0ned1ger!> has joined #yocto20:50
JPEWWell... that was easy20:55
*** B0ned1ger <B0ned1ger!> has quit IRC20:55
JPEWtlwoerner: I have the Rock Pi X booting :)20:55
*** ericch <ericch!> has quit IRC21:07
*** ericch <ericch!> has joined #yocto21:13
v0npaulbarker: since I add custom u-boot and linux files for my beaglebone based board, should I use SRC_URI_append_<board> in their {u-boot,linux}-ti-staging_%.bbappend recipes?21:20
*** mbulut <mbulut!> has joined #yocto21:25
v0nhum I'll keep them as SRC_URI_append because these recipes are supposed to be in the BSP layer so they couldn't be used without the defined layer machine(s)21:42
tlwoernerJPEW: sweet! B-)21:53
khemboth are set to same value '-odroid'21:58
JPEWtlwoerner: Mind applying that patch for the rock-pi-4 serial port to meta-rockchip (it will need backport to dunfell as well)?22:05
tlwoernerJPEW: sure22:06
tlwoernersorry, i though Bruce was going to apply it22:10
tlwoerneri'll go ahead and apply it now22:10
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has quit IRC22:12
*** kiwi_29 <kiwi_29!> has quit IRC22:22
*** kiwi_29 <kiwi_29!> has joined #yocto22:23
*** vineela <vineela!vtummala@nat/intel/x-pysxdiupfszcdlfp> has quit IRC22:37
*** vineela <vineela!vtummala@nat/intel/x-alptdxubtqnzluyq> has joined #yocto22:39
*** beneth <beneth!> has left #yocto22:40
JPEWtlwoerner: Thanks!22:41
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC22:45
*** adelcast <adelcast!~adelcast@2806:108e:1a:6659:f716:ab12:f11f:429a> has quit IRC22:48
khemzeddii: RobertBerger1 in my case kernel recipe has LINUX_VERSION_EXTENSION ?= "-odroid" but defconfig has CONFIG_LOCALVERSION="" and after do_configme I get CONFIG_LOCALVERSION="-odroid"22:50
khem which is what i expect but then the question is why this warning from kernel tooling22:50
*** B0ned1ger <B0ned1ger!> has joined #yocto22:51
*** ssajal <ssajal!~ssajal@> has quit IRC22:54
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC22:54
v0ndo I need MACHINEOVERRIDES =. "beaglebone:" ?22:55
*** B0ned1ger <B0ned1ger!> has quit IRC22:55
*** adelcast <adelcast!~adelcast@2806:108e:1a:6659:f716:ab12:f11f:429a> has joined #yocto22:56
v0nI used 'require conf/machine/beaglebone.conf' to define my machine based on bbb, but images still go in a beaglebone/ directory instead of <my machine>/22:56
*** kiwi_29 <kiwi_29!> has quit IRC23:12
*** kiwi_29 <kiwi_29!> has joined #yocto23:12
v0nmeta-ti/conf/machine/beaglebone.conf in fact has only a few lines, should I require instead of beaglebone.conf to define my own machine?23:15
khemyes you will need that MACHINEOVERRIDE to take advantage of all overrides that apply to bbb23:28
*** kiwi_29 <kiwi_29!> has quit IRC23:31
*** dev1990 <dev1990!> has quit IRC23:38
*** mbulut <mbulut!> has quit IRC23:46
v0nkhem: hum nah MACHINEOVERRIDES seems to give existing machine(s) as alias(es) for the newly defined machine so that it benefits from existing VAR_append_<machine> for example23:52
*** kiwi_29 <kiwi_29!> has joined #yocto23:53

Generated by 2.17.2 by Marius Gedminas - find it at!