| *** adelcast <adelcast!~adelcast@130.164.62.197> has quit IRC | 00:05 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 02:18 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.187> has quit IRC | 03:02 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC | 04:00 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto | 04:03 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 04:21 | |
| iceaway | I'm having problems getting Yocto to use my .bbappend file. I'm trying to use a .bbappend for u-boot, and in my build u-boot is provided by a recipe called u-boot-variscite. So in my own layer I have created recipes-bsp/u-boot/u-boot-variscite.bbappend. But if I run bitbake-layers show-append | grep u-boot it does not show up. My layer is in "bitbake-layers show-layers", and *.bbappend is in the BBFILES in | 04:54 |
|---|---|---|
| iceaway | my layer.conf (I have other .bbappends in the same layer that are recognized). | 04:54 |
| nrossi | iceaway: does the .bb have a version? does your .bbappend have a version? (aka u-boot-variscite_<version>.bb) | 04:58 |
| iceaway | nrossi: Nope, the .bb is just u-boot-variscite.bb. I actually had this working and what caught me then was that I called my .bbappend u-boot-varicite_%.bbappend, and then it would list as "skipped". But then for some reason I deleted the whole .bbappend stuff and had to start over, and now it's not listed at all. | 05:02 |
| *** thomasd13 <thomasd13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 05:02 | |
| kergoth | as long as your layer is in bblayers and the bbappend is in bbfiles, and the filename exactly matches (with % wildcards) the .bb filename, it'll be applied | 05:04 |
| kergoth | i'd check each of those systematically. | 05:04 |
| kergoth | most common when i run into this it's something stupid like accidentally putting it in the root of recipes-whatever/ instead of in the recipe subdir, or the filename has a typo relative to the .bb | 05:05 |
| iceaway | I have triple-checked all those, but will check again. It is also my experience that when you eventually find the error it was some stupid typo or similar that you just were incapable of seeing. | 05:06 |
| kergoth | also make sure BBMASK isn't interfering. it's highly unlikely, but possible | 05:07 |
| iceaway | it does not really matter what the directory under recipes-bsp/<name> is called, right? Bitbake will search all dirs (if configured so in layer.conf) and match by <name>.bb/bbappend right? | 05:08 |
| iceaway | i.e. it could be meta-bsp/foobar/u-boot-variscite.bbappend? | 05:09 |
| nrossi | iceaway: only if your BBFILES patterns allows it to match, e.g. with a BBFILES entries of "recipes-bsp/*/*.bb recipes-bsp/*/*.bbappend" | 05:09 |
| iceaway | nrossi: great :) | 05:10 |
| iceaway | kergoth: Thanks for the BBMASK hint. I had forgotten that I tried to disable my u-boot.bbappend yesterday by adding a BBMASK in my local.conf for u-boot! *facepalm* | 05:10 |
| kergoth | heh, np, that'd do it | 05:12 |
| kergoth | as nrossi says, the layout is up to you, as long as BBFILES matches it, you're fine | 05:12 |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 05:14 | |
| kroon | kergoth, in bitbake, do you know if it is true in general that during variable expansion, all overrides are applied before all _append/_prepend/_remove are applied ? | 05:20 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:41 | |
| nrossi | kroon: just looking at bitbake code itself, looks like overrides are processed before _append/etc. see here: https://git.openembedded.org/bitbake/tree/lib/bb/data_smart.py#n734 | 05:49 |
| kroon | nrossi, thanks! | 05:52 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 06:17 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:29 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 06:46 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 07:06 | |
| *** likewise <likewise!~leon@83.137.143.222> has joined #yocto | 07:08 | |
| *** yacar_ <yacar_!~yacar@80.215.229.251> has joined #yocto | 07:19 | |
| __angelo | hello ! in an initramfs for arm i miss all devices, so getting spam of tty missing, is there any link in the manual to setup this ?^ | 07:19 |
| __angelo | (i only have /dev/console) | 07:20 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 07:21 | |
| *** yann <yann!~yann@lfbn-1-3378-31.w90-127.abo.wanadoo.fr> has quit IRC | 07:22 | |
| *** antoine74 <antoine74!5c9a57ab@lmontsouris-656-1-15-171.w92-154.abo.wanadoo.fr> has joined #yocto | 07:22 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 07:23 | |
| antoine74 | Hello, I have a problem loading a kernel module at boot, I would like to load i2c-dev so I added KERNEL_MODULE_AUTOLOAD += "i2c-dev" in my local.conf and nothing happens, any idea why ? (I can load the module when connected to the machine with "modprobe i2c-dev"...) | 07:25 |
| *** jofr <jofr!~jofr@193.182.166.3> has quit IRC | 07:32 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:36 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 07:41 | |
| RP | kroon: its not as simple as "before" or "after", it depends on the expression | 07:45 |
| RP | kroon: X_append_override is override first, X_override_append is append first. Its basically right hand side first | 07:45 |
| kroon | RP, hmm ok. and for X_append + X_override, it is override first ? | 07:48 |
| RP | kroon: no, overrides tend to win over appends in a straight head to head | 07:48 |
| *** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has joined #yocto | 07:49 | |
| *** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 07:51 | |
| kroon | RP, initial testing here with bitbake master would indicate that for X_append + X_override, it is override first, then append is applied.. | 07:56 |
| kroon | RP, is there an easy explanation for when overrides would win ? | 07:57 |
| kroon | in the case above I mean | 07:57 |
| RP | kroon: I'm clearly confused and append does win | 07:58 |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 07:58 | |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 07:58 | |
| RP | kroon: sorry, I'm misremembering | 07:59 |
| kroon | RP, ah | 07:59 |
| RP | kroon: the rules are clearly defined with the test cases in bitbake | 07:59 |
| kroon | good point | 07:59 |
| *** mckoan|away is now known as mckoan | 08:04 | |
| qschulz | kroon: I think you can remember it like that: X_append is a desire to append to X whatever the override is. X_override override X for override only. If _append would be prioritized over _override, it would mean that _append is a desire to append only to default conf and everyone would need to add _override to X to be sure X is appended for every cases => impossible to maintain | 08:14 |
| *** prabhakarlad <prabhakarlad!c18ddb24@193.141.219.36> has joined #yocto | 08:19 | |
| *** palate <palate!~palate@unaffiliated/palate> has quit IRC | 08:29 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:30 | |
| *** lemagoup <lemagoup!~lemagoup@softbank-robotics-gw1.ter4.eqx2.par.cust.as8218.eu> has quit IRC | 08:33 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 08:34 | |
| yocti | New news from stackoverflow: How to get OpenCV 4.1.0 on the yocto/poky warrior branch? <https://stackoverflow.com/questions/58024456/how-to-get-opencv-4-1-0-on-the-yocto-poky-warrior-branch> || Rescue partition in Yocto image <https://stackoverflow.com/questions/58024410/rescue-partition-in-yocto-image> | 08:43 |
| *** kaspter <kaspter!~Instantbi@223.104.213.203> has joined #yocto | 08:48 | |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has quit IRC | 09:02 | |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 09:03 | |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has joined #yocto | 09:14 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 09:32 | |
| *** quijote <quijote!~dqx@unaffiliated/dqx> has quit IRC | 09:38 | |
| *** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto | 09:40 | |
| *** kaspter <kaspter!~Instantbi@223.104.213.203> has quit IRC | 09:43 | |
| *** yacar_ <yacar_!~yacar@80.215.229.251> has quit IRC | 09:55 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 10:02 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 10:10 | |
| *** thomasd13 <thomasd13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 10:32 | |
| *** antoine74 <antoine74!5c9a57ab@lmontsouris-656-1-15-171.w92-154.abo.wanadoo.fr> has quit IRC | 11:07 | |
| yocti | New news from stackoverflow: How to reduce the Jetson Nano .sdcard flash file size? <https://stackoverflow.com/questions/58027226/how-to-reduce-the-jetson-nano-sdcard-flash-file-size> | 11:13 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 11:16 | |
| *** yacar_ <yacar_!~yacar@80.215.229.251> has joined #yocto | 11:19 | |
| kayterina | how to add a line in inittab file? the sysvinit-inittab_ append is not read. | 11:30 |
| kayterina | I add the line in do_install_aooend in sysvinit-inittab_2.88dsf.bbappend | 11:32 |
| qschulz | kayterina: 1. are you sure the bbappend is applied? 2. which file are you modifying? the one in your workdir/builddir/sourcedir or the one that is installed in ${D}? | 11:33 |
| kayterina | I am fairly sure it is not applied. | 11:34 |
| kayterina | I added /mylayer/reciped-core/sysvinit/sysvinit-inittab/sysvinit-inittab_2.88dsf.bbappend | 11:34 |
| kayterina | I saw it in SO | 11:35 |
| kayterina | *read | 11:35 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 11:37 | |
| kayterina | qschulz: I modify the file in {D}, as I have ${D}${sysconfdir}/inittab | 11:37 |
| * kayterina sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/wcTZZyPjsUlnljlyQtgmQEDr > | 11:38 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 11:44 | |
| qschulz | kayterina: reciped-core or recipes-core? | 11:44 |
| kayterina | recipes | 11:45 |
| qschulz | you have one too many subdirs | 11:45 |
| qschulz | recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bbappend | 11:45 |
| qschulz | that's where it should be | 11:45 |
| kayterina | it is there. | 11:46 |
| kayterina | sorry I didn't copy-paste | 11:46 |
| qschulz | (the path where bitbake looks for bb or bbappend is BBFILES in conf/layer.conf of your layer) | 11:47 |
| kayterina | could it be a priority issue? when is inittab created | 11:47 |
| kayterina | my layer is priority 6 | 11:47 |
| qschulz | kayterina: you can check the bbappend is detected by using bitbake-layers show-appends sysvinit-inittab AFAIR | 11:50 |
| kayterina | @qschulz ok,I'll do that, thanks | 11:50 |
| qschulz | then, if it's correctly parsed, you can check the actual value of do_install (in order as it will be executed) in $WORKDIR/temp/run.do_install | 11:51 |
| qschulz | this is basically what is executed by bitbake, so you can see the order of things. | 11:52 |
| rburton | if you're just providing a new file, i don't think you need to even do do_install_append | 11:57 |
| qschulz | rburton: kayterina is echo-ing >> to it | 11:57 |
| rburton | ah ok ignore me | 11:58 |
| kayterina | well, I don't have a do.run_install in workdir | 11:58 |
| qschulz | run.do_install? | 12:03 |
| qschulz | in the workdir of the recipe? | 12:03 |
| kayterina | inside the $WORKDIR/temp | 12:09 |
| qschulz | what is $WORKDIR exactly for you? | 12:13 |
| kayterina | it is the image dir I think? I grep'd it | 12:14 |
| qschulz | I meant the workdir of the recipe | 12:14 |
| kayterina | bitbake -e dikomoy-image-minimal |grep ^WORKDIR= | 12:14 |
| qschulz | Ah, no :) that does not work | 12:14 |
| qschulz | well.. yes it does but it's the workdir of the image recipe not the sysvinit-inittab recipe | 12:15 |
| qschulz | so you could technically do the same but with bitbake -e sysvinit-inittab | grep ^WORKDIR= | 12:15 |
| kayterina | it finds non existant directory with sysvinit-inittab | 12:15 |
| qschulz | but since you already know bitbake -e, you cand irectly look at do_install in there | 12:15 |
| qschulz | kayterina: have you cleaned your workdir since last build? are you using the same MACHINE and DISTRO for bitbake -e sysvinit-inittab than when you built your image? | 12:17 |
| kayterina | I am using the same MACHINE and DISTRO, I did change some things,then rempved,then built | 12:18 |
| kayterina | perhaos I'll just rm tmp and rebuild,is it correct? | 12:19 |
| qschulz | just bitbake sysvinit-inittab | 12:21 |
| kayterina | ok | 12:21 |
| qschulz | then after it's done, the dir mentioned in WORKDIR should be there | 12:21 |
| *** cengiz_io <cengiz_io!~cengiz_io@159.89.7.238> has left #yocto | 12:24 | |
| RP | JPEW: I've put some fixes in -next for testing | 12:27 |
| qschulz | RP: any idea how a usergroup from recipea can be used in useradd from recipeb? we have some occurences when this fails (we depends/rdepends in recipeb on recipea) | 12:39 |
| RP | qschulz: I think there are open bugs for this filed by Tartarus | 12:40 |
| RP | qschulz: adding the user in both recipes is the workaround right now | 12:40 |
| RP | I've not had the bandwidth to figure out a better fix | 12:40 |
| qschulz | in our case the group then :) | 12:40 |
| RP | qschulz: right, same thing | 12:41 |
| qschulz | RP: do you have a link by any chance? | 12:41 |
| RP | qschulz: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13419 | 12:42 |
| yocti | Bug 13419: normal, Medium+, 2.8 M3, richard.purdie, NEW , recipes that add users to groups cannot rely on other recipes creating those groups (when population from sstate happens) | 12:42 |
| RP | https://bugzilla.yoctoproject.org/show_bug.cgi?id=13279 | 12:42 |
| yocti | Bug 13279: normal, Medium+, 2.8 M3, liezhi.yang, NEW , Make sure users/groups exist for package_write_* tasks | 12:42 |
| *** likewise <likewise!~leon@83.137.143.222> has quit IRC | 12:45 | |
| qschulz | RP: thanks! we'll try the workaround | 12:49 |
| RP | JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/178 issustrates what I think is the remaining hashequiv runqueue problem | 12:50 |
| Tartarus | OK, good, I'm not filing bugs about stuff in my sleep ;) | 12:53 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 13:00 | |
| zeddii | RP: fyi. Still digging down in the freezer cgroups for strace fun. At least I'll be able to discuss it fully on the mailing list if I fail to fix it. | 13:02 |
| RP | zeddii: ok, cool. I was wondering how that was going | 13:03 |
| zeddii | RP (or anyone else) while the kernel builds yet again .. if I made bad design decision several years back and made variants of a recipe/package without using virtual/foo ... is there any graceful way to switch to virtual/foo now ? without breaking existing DEPENDS/RDEPENDS ? or am I stuck with a flag day kind of change ? | 13:04 |
| qschulz | zeddii: well, you can still add PROVIDES = "virtual/<pkg>" it won't change what exists currently AFAIK? | 13:06 |
| RP | zeddii: I'd have thought you could add in extra PROVIDES | 13:08 |
| zeddii | I haven't run all the tests yet, but since it wasn't virtual/foo before, won't anyone that had depends=foo, etc, break if I switch everything to virtual/foo ? maybe I just need more coffee. I want to move it to a preferred provider kind of thing, so now that I think about it, the *packages* will be the same so image_install, etc are fine, it is just depends. | 13:11 |
| zeddii | but yah. with the extra provides it should be fine | 13:11 |
| * zeddii tries that. | 13:11 | |
| RP | zeddii: virtual/X is a DEPENDS only namespace and a recipe can PROVIDE more than one thing | 13:13 |
| zeddii | yah | 13:13 |
| zeddii | I realized that after typing it out :D | 13:13 |
| zeddii | you can't IMAGE_INSTALL = "virtual/kernel" :D | 13:14 |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 13:24 | |
| *** iceaway <iceaway!~pelle@37.233.78.69> has quit IRC | 13:26 | |
| qschulz | RP: ok, quick question :) apparently the user/group dependency between two recipes bug does not happen if we have 'deltask do_package_setscene' in the recipe depending on the other recipe. Is this wrong? On which level of wrongness are we :) ? | 13:27 |
| RP | qschulz: that doesn't sound right to me | 13:30 |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 13:43 | |
| JPEW | RP: It runs the do_configure/do_compile etc. without running do_fetch? | 13:51 |
| RP | JPEW: yes :/ | 14:01 |
| RP | JPEW: basically it setscened all the tasks for that recipe, then decided it really needed to rerun them | 14:02 |
| kayterina | qschulz: is inittab provided by sysvinit-inittab for raspberry pi? | 14:07 |
| kayterina | in sysvinitab workdir there is the inittab with my append but it is different from the one in the image | 14:09 |
| qschulz | kayterina: https://wiki.yoctoproject.org/wiki/Technical_FAQ#How_do_I_find_out_which_package_contains_a_particular_file_.28or_python_module.29.3F | 14:10 |
| qschulz | this could help maybe? | 14:10 |
| JPEW | RP: Hmm.... interesting. | 14:10 |
| *** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 14:11 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 14:26 | |
| *** adelcast <adelcast!~adelcast@130.164.62.197> has joined #yocto | 14:26 | |
| RP | JPEW: Its a tricky dilemma on how to handle this :/ | 14:28 |
| JPEW | RP: Ya, I agree.... is there any indication as to why it though those needed to be rerun? | 14:28 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 14:30 | |
| RP | JPEW: the hash of a dependency changed to one which was no longer compatible | 14:30 |
| RP | JPEW: the setscene had already run, it then decided to change the hash and turn it to a normal task as there was no sstate | 14:31 |
| RP | JPEW: we could make it so that once setscene has run, the hashes can't change | 14:32 |
| JPEW | RP: Is any of the setsecene it did for adwaita-icon-theme valid? | 14:34 |
| RP | JPEW: it was valid, then new hashes appeared | 14:34 |
| RP | no longer matched | 14:34 |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 14:37 | |
| JPEW | RP: I guess I'm not quite following where that happened. gtk+ do_populate_sysroot was detected as equivalent and it's unihash was updated. This caused a cascade of setsecene tasks to be re-run, then adawait-icon-theme started rerunning. Wheres the hash that no longer matched? Is it one of the other tasks that setsecene'd after gtk+ changed? | 14:39 |
| qschulz | We're trying to move to pigz for opkg packages compression but it fails if I don't have pigz in my host | 14:39 |
| qschulz | OPKGBUILDCMD = "opkg-build -Z pigz" | 14:39 |
| rburton | qschulz: yes, that's right. that's exactly what would happen if you did that. | 14:40 |
| qschulz | would it make sense to add DEPENDS = "pigz-native" to opkg-utils? | 14:40 |
| rburton | no | 14:40 |
| qschulz | yup | 14:40 |
| rburton | see pacakge_ipk.bbclass | 14:40 |
| rburton | which in case, uses multithreaded xz and thus depends on xz-native | 14:41 |
| RP | JPEW: after the gtk rehash it prints that adwaita-icon-theme changed (multiple tasks) | 14:41 |
| rburton | "which in master", even | 14:41 |
| RP | JPEW: that meant the previous setscene was invalid and it now needed to rerun the adwaita-icon-theme tasks | 14:41 |
| qschulz | rburton: mmm, I'm lost now :/ | 14:43 |
| JPEW | RP: Just to make sure I'm on the same page, what line of the log file is that? | 14:43 |
| RP | JPEW: 9139 is where it says its rerunning adwaita-icon-theme | 14:44 |
| qschulz | rburton: is there a way to add pigz-native dependency to the build? | 14:45 |
| rburton | qschulz: yes, see package_ipg.bbclass which in master does exactly that for xz | 14:45 |
| qschulz | I need to override this class then, right? | 14:46 |
| rburton | you can replicate the logic in another class | 14:46 |
| rburton | i recommend xz over pigz, better control over usage in heavy builds | 14:47 |
| qschulz | wdym? | 14:48 |
| qschulz | our concern at the moment is to make the build faster basically | 14:48 |
| rburton | left to its own devices a heavily parallel build can end up getting OOMd, xz lets you control memory usage and threading nicely | 14:48 |
| rburton | which is why its used in oe-core master | 14:48 |
| rburton | warrior has that too | 14:49 |
| rburton | so consider just upgrading :) | 14:49 |
| qschulz | "warrior has that too"? | 14:51 |
| rburton | the use of threaded xz | 14:51 |
| qschulz | because thud does not have it? | 14:51 |
| qschulz | (sorry for the dumb questions, brain is fried for this week) | 14:51 |
| rburton | hm no thud has xz too, just doesn't control its memory usage | 14:52 |
| rburton | OPKGBUILDCMD ??= "opkg-build -Z xz" | 14:52 |
| rburton | so you can easily tweak opkg-build to do a multithreaded xz | 14:53 |
| rburton | you might want to backport https://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/commit/opkg-build?id=49d32419abec4142995f3ed6f840137c8a72f3b3 then you're happy | 14:54 |
| rburton | RP: oh my api-doc world thing didn't land, so i shouldn't feel bad :) | 14:56 |
| RP | rburton: no, not yet. Enough other moving bits | 14:56 |
| rburton | well i have a tweak to make it exclude webkitgtk to save half an hour :) | 14:57 |
| RP | rburton: ok, cool | 14:57 |
| RP | rburton: autobuilder helper change? | 14:57 |
| rburton | yes | 14:57 |
| rburton | ross/gtkdoc in the repo | 14:57 |
| JPEW | RP: Shouldn't the setsecene tasks being eligible to run have covered the other tasks (do_configure/do_compile?). The setscene tasks became valid, but didn't actually rerun? | 14:58 |
| RP | JPEW: Its do_populate_lic that complicated things, that was still valid | 15:00 |
| RP | (and depends on tasks pre configure) | 15:00 |
| JPEW | RP: Ok, that makes sense | 15:01 |
| JPEW | RP: Out of curiosity, how do you know it was that task? | 15:02 |
| RP | JPEW: I just recognise the patterns | 15:03 |
| RP | JPEW: populate_lic is nearly always reused from sstate as it only depends on the sources | 15:04 |
| JPEW | RP: I figured :) Looking at a lot of these logs gives a good feel for what should be running | 15:05 |
| *** prabhakarlad <prabhakarlad!c18ddb24@193.141.219.36> has quit IRC | 15:06 | |
| *** marler899763 <marler899763!0f41fc0d@ztxe01hpics303.austin.hp.com> has joined #yocto | 15:06 | |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 15:08 | |
| JPEW | RP: Ok, so if that is the case, why didn't do_fetch run? My guess: Already had a stamp file for do_fetch from a previous run, so it started from the first task that actually changed (do_prepare_recipe_sysroot), but the fetch wasn't actually there because... a previous setsecene task invalidated it? | 15:09 |
| RP | JPEW: that isn't what I think happened | 15:09 |
| RP | JPEW: I think all of adwaita-icon-theme came from sstate originally so the build marked many of the tasks as skipped | 15:10 |
| RP | when the hashes changed, its having trouble "unskipping" tasks which became buildable | 15:10 |
| JPEW | RP: OK, that makes sense | 15:11 |
| RP | JPEW: adwaita-icon-theme:do_patch is buildable before gtk+ populate_sysroot completes | 15:11 |
| RP | JPEW: I think the answer is going to be not to rerun sstate tasks once they've run. What that means for the sigs I don't know though | 15:12 |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 15:13 | |
| * JPEW finds a whiteboard.... | 15:16 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC | 15:22 | |
| JPEW | RP: How do you know do_patch was buildable? | 15:27 |
| RP | JPEW: I'm guessing a bit :/ | 15:27 |
| RP | JPEW: I've spent a long time staring at the code | 15:27 |
| RP | JPEW: I can't explain it any other way | 15:28 |
| JPEW | RP: You have bitbake ESP | 15:28 |
| RP | JPEW: More like spent the day on this :( | 15:29 |
| RP | JPEW: I'm open to others ways to explain why it breaks | 15:29 |
| RP | JPEW: we could try http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=c679b56e8b4895f926f6bfb73fcf08c61a78f90b | 15:31 |
| RP | JPEW: for determinism we may want to have a report_unihash there | 15:31 |
| RP | JPEW: not sure what we can use as outhash as we don't have one | 15:32 |
| *** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has quit IRC | 15:32 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 15:33 | |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 15:33 | |
| JPEW | RP: Hmm..... perhaps worth a try, but I'm not sure it's quite the right thing. | 15:36 |
| qschulz | rburton: I don't understand why DEPENDS = "pigz-native" in opkg-utils-native wouldn't work (I'm not saying it's the good way to do it, I just want to understand) | 15:36 |
| JPEW | RP: How reproducible is this? | 15:37 |
| qschulz | it's going to put pigz-native:do_populate_sysroot as a dependency of opkg-utils-native:do_configure which happens before do_package_write_ipk right? | 15:38 |
| RP | JPEW: happens on the autobuilder in 2-3 builds? | 15:38 |
| qschulz | or is it not ideal because it installs everything to a sysroot that we shouldn't need? | 15:38 |
| RP | qschulz: it might work but opkg-utils doesn't depend on it so its technically wrong | 15:39 |
| RP | JPEW: I don't like this but I can't see another way for things to work | 15:39 |
| qschulz | RP: such an idiot... | 15:39 |
| qschulz | RP: BTW, RDEPENDS for a native package should work in master now? because I guess that's what should be needed right>? | 15:40 |
| RP | qschulz: it kinds of works | 15:42 |
| RP | qschulz: think about how RDEPENDS works when PACKAGES="" | 15:42 |
| RP | (which is why its 'fun') | 15:42 |
| qschulz | RP: I saw that test in package_ipk.bbclass, when does this happen? | 15:44 |
| qschulz | in images? | 15:44 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 15:47 | |
| RP | qschulz: when does what happen? Sorry but I really need to concentrate on other things :/ | 15:47 |
| *** yacar_ <yacar_!~yacar@80.215.229.251> has quit IRC | 15:49 | |
| *** sgw <sgw!~sgw@192.55.55.43> has quit IRC | 15:49 | |
| rburton | qschulz: package-ipk.bbclass shows exactly how to add dependencies for packaging | 15:50 |
| qschulz | RP: PACKAGES="". no worries, it's just curiosity :) | 15:50 |
| RP | qschulz: native.bbclass | 15:51 |
| rburton | https://github.com/openembedded/openembedded-core/blob/master/meta/classes/package_ipk.bbclass#L261 if you're having trouble | 15:51 |
| qschulz | rburton: there are many ways to do different things. I saw how it's done in package_ipk.bbclass, I wanted to know if other ways I thought of could work as well and if and why it shouldn't be used. | 15:52 |
| rburton | what the class does is the one way | 15:52 |
| marler899763 | do bitbake files have issues with HEREDOC in bash functions? | 15:52 |
| qschulz | rburton: well, PACKAGE_WRITE_DEPS in conf/local.conf is another way | 15:52 |
| RP | marler899763: our parser may | 15:53 |
| rburton | qschulz: fails if you need the thing to build the thing | 15:53 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 15:55 | |
| smurray | marler899763: there's a few recipes in the AGL layers that use here documents | 15:56 |
| marler899763 | I'm guessing HEREDOC works so long as you don't use certain characters | 15:57 |
| qschulz | rburton: *facepalm*, that's what I get for trying to be smart on a Friday afternoon | 16:03 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 16:06 | |
| qschulz | rburton: I'm very curious now why it didn't fail when we compiled with PACKAGE_WRITE_DEPS = "pigz-native". What's in package_ipk.bbclass in the very same line you sent is doing the same as if PACKAGE_WRITE_DEPS was "xz-native". Or am I being an idiot again abd it's really time to go home? | 16:09 |
| RP | JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/389 step1d looks "fun" :( | 16:19 |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 16:20 | |
| *** litb <litb!~js@217.7.252.169> has joined #yocto | 16:25 | |
| litb | hello all | 16:25 |
| litb | I've just found out about the "Ostro" Operating system | 16:25 |
| litb | it's now dead. why was it abandoned? | 16:26 |
| rburton | hm what one was ostro | 16:26 |
| RP | rburton: its bad when you can't even remember! | 16:27 |
| rburton | was that the nokia collab? | 16:27 |
| zeddii | rburton. its that's steaming, burning wreckage on the side of the raod. | 16:27 |
| rburton | no, it wasn't | 16:27 |
| litb | i just read about it in https://elinux.org/images/6/69/Demystifying_Systemd.pdf | 16:27 |
| rburton | litb: abandoned for boring business reasons | 16:27 |
| litb | apparently it's an operating system for embedded, based on yocto | 16:27 |
| litb | rburton, oh hmm | 16:28 |
| RP | rburton: Ostro was the YP based embedded distro one iirc? | 16:28 |
| rburton | the layers are still online | 16:28 |
| rburton | yeah | 16:28 |
| litb | maybe we could use it to build our own | 16:28 |
| rburton | 'be inspired by it', the layers are untouched | 16:28 |
| zeddii | and it was a lot of reshashed and recycled failed design ideas ;) | 16:28 |
| rburton | iot refkit is similar idea but a bit more recent | 16:28 |
| litb | currently we are trying to figure out how to make our firmware app boot up using systemd | 16:28 |
| rburton | litb: well, surely that's just turning on systemd: two lines in your distro conf | 16:29 |
| litb | we want to support multiple app-instances of our firmware on a single device, and want to be able to tell systemd "boot our firmware that's below /firmware1" and "boot our firmware that's below /firmware2" | 16:29 |
| RP | rburton: its one isn't it? | 16:29 |
| rburton | RP: i was including setting distro features | 16:29 |
| litb | I'm currently figuring out how to do that. i.e how to put systemd unit files somewhere else than /etc and make systemd use it. | 16:29 |
| RP | rburton: INIT_MANAGER = ? | 16:30 |
| rburton | litb: for what you want, ostro isn't relevant. you're talking about general systemd use. | 16:30 |
| litb | rburton, but because we need to still figure out what initrd system to use, what splash screen to use etc.. maybe we could use an existing yocto-based OS that has all of it "solved" | 16:31 |
| rburton | litb: if you're using systemd then i believe you don't have a choice for splash | 16:31 |
| rburton | psplash and systemd don't get on well iirc | 16:31 |
| litb | currently i use yocto's init framework for initramfs. and systemd as /sbin/init | 16:32 |
| litb | for splash i use plymouth | 16:32 |
| rburton | right, solved then :) | 16:33 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 16:33 | |
| litb | also I'm not using grub as my boot manager, because yocto/oe doesn't provide ready to use wic scripts for grub+bios | 16:33 |
| litb | so i have to use syslinux currently and need to figure out the steps to install grub later | 16:33 |
| rburton | eww bios :) | 16:34 |
| *** marler899763 <marler899763!0f41fc0d@ztxe01hpics303.austin.hp.com> has quit IRC | 16:34 | |
| *** mckoan is now known as mckoan|away | 16:36 | |
| *** sgw <sgw!sgw@nat/intel/x-ieicypkuwuiyfpej> has joined #yocto | 16:37 | |
| RP | rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/388 is a master failure - don't understand how/why :( | 16:38 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 17:08 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 17:11 | |
| JPEW | RP: Got it. Will raise a bug. Fortunately, it looks like I can reproduce that one locally if I run the test enough times. | 17:18 |
| *** marler899766 <marler899766!0f41fc0d@ztxe01hpics303.austin.hp.com> has joined #yocto | 17:25 | |
| marler899766 | ugh...ran out of disk space again | 17:26 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:26 | |
| marler899766 | You would think 500 GB would be big enough for 4 yocto builds... | 17:26 |
| *** sgw <sgw!sgw@nat/intel/x-ieicypkuwuiyfpej> has quit IRC | 17:33 | |
| *** creich_ <creich_!~creich@2a02:8106:217:2100:d01:182b:8d17:626d> has quit IRC | 17:34 | |
| *** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 17:42 | |
| *** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 17:43 | |
| *** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 17:44 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto | 17:45 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 17:47 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 17:47 | |
| *** sgw <sgw!~sgw@134.134.139.77> has joined #yocto | 17:47 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC | 17:57 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto | 17:59 | |
| khem | RP: uim failure is due to parallel install race | 18:00 |
| khem | I have pushed a potential fix lets see if that works then we will be green on that tumbleweed box | 18:00 |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC | 18:00 | |
| *** litb <litb!~js@217.7.252.169> has quit IRC | 18:25 | |
| *** aehs29 <aehs29!~aehs29@149.199.62.131> has quit IRC | 18:28 | |
| *** gattuso <gattuso!~gattuso@pompel.me> has quit IRC | 18:28 | |
| *** elGamal <elGamal!~elg@5.253.206.78> has quit IRC | 18:28 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto | 18:28 | |
| *** elGamal <elGamal!~elg@5.253.206.78> has joined #yocto | 18:29 | |
| *** gattuso <gattuso!~gattuso@pompel.me> has joined #yocto | 18:31 | |
| ecdhe | How can I make yocto generate a vmlinuz file? | 18:47 |
| mischief | i'm confused about kernel module recipe/package naming.. i have a recipe that makes a kernel module foo.ko, but adding kernel-module-foo to MACHINE_ESSENTIAL_EXTRA_RDEPENDS causes bitbake to say it can't find the package. what's the deal? | 18:56 |
| ecdhe | I get a tar.gz of the filesystem and an Image file containing the kernel, but no vmlinuz. | 18:56 |
| mischief | ecdhe: what do you think Image is? :) | 18:58 |
| mischief | ecdhe: look at KERNEL_IMAGETYPE in the yocto manual.. 'make help' in the kernel tree and looking at the kernel bbclasses can also be instructive | 18:59 |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC | 19:02 | |
| ecdhe | thanks mischief. `file Image' didn't give me any useful information for converting Image -> vmlinuz. I did try gzipping it but it didn't pass the mustard | 19:02 |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto | 19:04 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 19:11 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC | 19:15 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto | 19:16 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 19:21 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 19:39 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 19:40 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 19:47 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 19:48 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 19:58 | |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 20:07 | |
| *** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has quit IRC | 20:07 | |
| *** yann <yann!~yann@lfbn-1-3378-31.w90-127.abo.wanadoo.fr> has joined #yocto | 20:08 | |
| kergoth | hmm,. no man pages in non-gplv3 due to man-db.. seems like mandoc will do the job, though.. | 20:18 |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 20:19 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC | 20:27 | |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 20:29 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto | 20:33 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC | 20:47 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 20:48 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto | 20:50 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 20:51 | |
| *** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC | 20:53 | |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 20:56 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21:22 | |
| *** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto | 21:34 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 21:36 | |
| *** aidanh_ is now known as aidanh | 21:36 | |
| RP | khem: ok, sounds like you're close to sorting it! :) | 21:41 |
| RP | JPEW: I'll leave that one with you then, thanks | 21:41 |
| *** aehs29 <aehs29!~aehs29@149.199.62.129> has joined #yocto | 22:02 | |
| *** palate <palate!~palate@unaffiliated/palate> has joined #yocto | 22:09 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 22:13 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 22:17 | |
| *** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 22:17 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 22:22 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 23:09 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!