Friday, 2019-09-20

*** adelcast <adelcast!~adelcast@> has quit IRC00:05
*** goliath <goliath!> has quit IRC02:18
*** kaspter <kaspter!~Instantbi@> has quit IRC03:02
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC04:00
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto04:03
*** kroon <kroon!~kroon@> has joined #yocto04:21
iceawayI'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 in04:54
iceawaymy layer.conf (I have other .bbappends in the same layer that are recognized).04:54
nrossiiceaway: does the .bb have a version? does your .bbappend have a version? (aka u-boot-variscite_<version>.bb)04:58
iceawaynrossi: Nope, the .bb is just 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!> has joined #yocto05:02
kergothas 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 applied05:04
kergothi'd check each of those systematically.05:04
kergothmost 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 .bb05:05
iceawayI 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
kergothalso make sure BBMASK isn't interfering. it's highly unlikely, but possible05:07
iceawayit 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
iceawayi.e. it could be meta-bsp/foobar/u-boot-variscite.bbappend?05:09
nrossiiceaway: only if your BBFILES patterns allows it to match, e.g. with a BBFILES entries of "recipes-bsp/*/*.bb recipes-bsp/*/*.bbappend"05:09
iceawaynrossi: great :)05:10
iceawaykergoth: 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
kergothheh, np, that'd do it05:12
kergothas nrossi says, the layout is up to you, as long as BBFILES matches it, you're fine05:12
*** agust <agust!> has joined #yocto05:14
kroonkergoth, 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!> has joined #yocto05:41
nrossikroon: just looking at bitbake code itself, looks like overrides are processed before _append/etc. see here:
kroonnrossi, thanks!05:52
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto06:17
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:29
*** jmiehe <jmiehe!> has joined #yocto06:46
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:06
*** likewise <likewise!~leon@> has joined #yocto07:08
*** yacar_ <yacar_!~yacar@> has joined #yocto07:19
__angelohello ! 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 IRC07:21
*** yann <yann!> has quit IRC07:22
*** antoine74 <antoine74!> has joined #yocto07:22
*** Bunio_FH <Bunio_FH!> has quit IRC07:23
antoine74Hello, 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@> has quit IRC07:32
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC07:36
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto07:41
RPkroon: its not as simple as "before" or "after", it depends on the expression07:45
RPkroon: X_append_override is override first, X_override_append is append first. Its basically right hand side first07:45
kroonRP, hmm ok. and for X_append + X_override, it is override first ?07:48
RPkroon: no, overrides tend to win over appends in a straight head to head07:48
*** asabil <asabil!> has joined #yocto07:49
*** lfa <lfa!~lfa@> has quit IRC07:51
kroonRP, initial testing here with bitbake master would indicate that for X_append + X_override, it is override first, then append is applied..07:56
kroonRP, is there an easy explanation for when overrides would win ?07:57
kroonin the case above I mean07:57
RPkroon: I'm clearly confused and append does win07:58
*** Bunio_FH <Bunio_FH!> has joined #yocto07:58
*** lfa <lfa!~lfa@> has joined #yocto07:58
RPkroon: sorry, I'm misremembering07:59
kroonRP, ah07:59
RPkroon: the rules are clearly defined with the test cases in bitbake07:59
kroongood point07:59
*** mckoan|away is now known as mckoan08:04
qschulzkroon: 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 maintain08:14
*** prabhakarlad <prabhakarlad!c18ddb24@> has joined #yocto08:19
*** palate <palate!~palate@unaffiliated/palate> has quit IRC08:29
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:30
*** lemagoup <lemagoup!> has quit IRC08:33
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC08:34
yoctiNew news from stackoverflow: How to get OpenCV 4.1.0 on the yocto/poky warrior branch? <> || Rescue partition in Yocto image <>08:43
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:48
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC09:02
*** yann <yann!~yann@> has joined #yocto09:03
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto09:14
*** AndersD <AndersD!> has quit IRC09:32
*** quijote <quijote!~dqx@unaffiliated/dqx> has quit IRC09:38
*** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto09:40
*** kaspter <kaspter!~Instantbi@> has quit IRC09:43
*** yacar_ <yacar_!~yacar@> has quit IRC09:55
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC10:02
*** rburton <rburton!> has joined #yocto10:10
*** thomasd13 <thomasd13!> has quit IRC10:32
*** antoine74 <antoine74!> has quit IRC11:07
yoctiNew news from stackoverflow: How to reduce the Jetson Nano .sdcard flash file size? <>11:13
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC11:16
*** yacar_ <yacar_!~yacar@> has joined #yocto11:19
kayterinahow to add a line in inittab file? the sysvinit-inittab_ append is not read.11:30
kayterinaI add the line in do_install_aooend in sysvinit-inittab_2.88dsf.bbappend11:32
qschulzkayterina: 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
kayterinaI am fairly sure it is not applied.11:34
kayterinaI added /mylayer/reciped-core/sysvinit/sysvinit-inittab/sysvinit-inittab_2.88dsf.bbappend11:34
kayterinaI saw it in SO11:35
*** goliath <goliath!> has joined #yocto11:37
kayterinaqschulz: I modify the file in {D}, as I have ${D}${sysconfdir}/inittab11:37
* kayterina sent a long message: < >11:38
*** kroon <kroon!~kroon@> has quit IRC11:44
qschulzkayterina: reciped-core or recipes-core?11:44
qschulzyou have one too many subdirs11:45
qschulzthat's where it should be11:45
kayterinait is there.11:46
kayterinasorry I didn't copy-paste11:46
qschulz(the path where bitbake looks for bb or bbappend is BBFILES in conf/layer.conf of your layer)11:47
kayterinacould it be a priority issue? when is inittab created11:47
kayterinamy layer is priority 611:47
qschulzkayterina: you can check the bbappend is detected by using bitbake-layers show-appends sysvinit-inittab AFAIR11:50
kayterina@qschulz ok,I'll do that, thanks11:50
qschulzthen, 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_install11:51
qschulzthis is basically what is executed by bitbake, so you can see the order of things.11:52
rburtonif you're just providing a new file, i don't think you need to even do do_install_append11:57
qschulzrburton: kayterina is echo-ing >> to it11:57
rburtonah ok ignore me11:58
kayterinawell, I don't have a do.run_install in workdir11:58
qschulzin the workdir of the recipe?12:03
kayterinainside the  $WORKDIR/temp12:09
qschulzwhat is $WORKDIR exactly for you?12:13
kayterinait is the image dir I think? I grep'd it12:14
qschulzI meant the workdir of the recipe12:14
kayterinabitbake -e dikomoy-image-minimal |grep ^WORKDIR=12:14
qschulzAh, no :) that does not work12:14
qschulzwell.. yes it does but it's the workdir of the image recipe not the sysvinit-inittab recipe12:15
qschulzso you could technically do the same but with bitbake -e sysvinit-inittab | grep ^WORKDIR=12:15
kayterinait finds non existant directory with  sysvinit-inittab12:15
qschulzbut since you already know bitbake -e, you cand irectly look at do_install in there12:15
qschulzkayterina: 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
kayterinaI am using the same MACHINE and DISTRO, I did change some things,then rempved,then built12:18
kayterinaperhaos I'll just rm tmp and rebuild,is it correct?12:19
qschulzjust bitbake sysvinit-inittab12:21
qschulzthen after it's done, the dir mentioned in WORKDIR should be there12:21
*** cengiz_io <cengiz_io!~cengiz_io@> has left #yocto12:24
RPJPEW: I've put some fixes in -next for testing12:27
qschulzRP: 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
RPqschulz: I think there are open bugs for this filed by Tartarus12:40
RPqschulz: adding the user in both recipes is the workaround right now12:40
RPI've not had the bandwidth to figure out a better fix12:40
qschulzin our case the group then :)12:40
RPqschulz: right, same thing12:41
qschulzRP: do you have a link by any chance?12:41
yoctiBug 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
yoctiBug 13279: normal, Medium+, 2.8 M3, liezhi.yang, NEW , Make sure users/groups exist for package_write_* tasks12:42
*** likewise <likewise!~leon@> has quit IRC12:45
qschulzRP: thanks! we'll try the workaround12:49
RPJPEW: issustrates what I think is the remaining hashequiv runqueue problem12:50
TartarusOK, good, I'm not filing bugs about stuff in my sleep ;)12:53
*** jmiehe <jmiehe!> has quit IRC13:00
zeddiiRP: 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
RPzeddii: ok, cool. I was wondering how that was going13:03
zeddiiRP (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
qschulzzeddii: well, you can still add PROVIDES = "virtual/<pkg>" it won't change what exists currently AFAIK?13:06
RPzeddii: I'd have thought you could add in extra PROVIDES13:08
zeddiiI 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
zeddiibut yah. with the extra provides it should be fine13:11
* zeddii tries that.13:11
RPzeddii: virtual/X is a DEPENDS only namespace and a recipe can PROVIDE more than one thing13:13
zeddiiI realized that after typing it out :D13:13
zeddiiyou can't IMAGE_INSTALL = "virtual/kernel" :D13:14
*** comptroller <comptroller!> has quit IRC13:24
*** iceaway <iceaway!~pelle@> has quit IRC13:26
qschulzRP: 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
RPqschulz: that doesn't sound right to me13:30
*** comptroller <comptroller!> has joined #yocto13:43
JPEWRP: It runs the do_configure/do_compile etc. without running do_fetch?13:51
RPJPEW: yes :/14:01
RPJPEW: basically it setscened all the tasks for that recipe, then decided it really needed to rerun them14:02
kayterinaqschulz: is inittab provided by sysvinit-inittab for raspberry pi?14:07
kayterinain sysvinitab workdir there is the inittab with my append but it is different from the one in the image14:09
qschulzthis could help maybe?14:10
JPEWRP: Hmm.... interesting.14:10
*** lfa <lfa!~lfa@> has quit IRC14:11
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto14:26
*** adelcast <adelcast!~adelcast@> has joined #yocto14:26
RPJPEW: Its a tricky dilemma on how to handle this :/14:28
JPEWRP: 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 #yocto14:30
RPJPEW: the hash of a dependency changed to one which was no longer compatible14:30
RPJPEW: the setscene had already run, it then decided to change the hash and turn it to a normal task as there was no sstate14:31
RPJPEW: we could make it so that once setscene has run, the hashes can't change14:32
JPEWRP: Is any of the setsecene it did for adwaita-icon-theme valid?14:34
RPJPEW: it was valid, then new hashes appeared14:34
RPno longer matched14:34
*** Crofton <Crofton!> has quit IRC14:37
JPEWRP: 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
qschulzWe're trying to move to pigz for opkg packages compression but it fails if I don't have pigz in my host14:39
qschulzOPKGBUILDCMD = "opkg-build -Z pigz"14:39
rburtonqschulz: yes, that's right. that's exactly what would happen if you did that.14:40
qschulzwould it make sense to add DEPENDS = "pigz-native" to opkg-utils?14:40
rburtonsee pacakge_ipk.bbclass14:40
rburtonwhich in case, uses multithreaded xz and thus depends on xz-native14:41
RPJPEW: after the gtk rehash it prints that adwaita-icon-theme changed (multiple tasks)14:41
rburton"which in master", even14:41
RPJPEW: that meant the previous setscene was invalid and it now needed to rerun the adwaita-icon-theme tasks14:41
qschulzrburton: mmm, I'm lost now :/14:43
JPEWRP: Just to make sure I'm on the same page, what line of the log file is that?14:43
RPJPEW: 9139 is where it says its rerunning adwaita-icon-theme14:44
qschulzrburton: is there a way to add pigz-native dependency to the build?14:45
rburtonqschulz: yes, see package_ipg.bbclass which in master does exactly that for xz14:45
qschulzI need to override this class then, right?14:46
rburtonyou can replicate the logic in another class14:46
rburtoni recommend xz over pigz, better control over usage in heavy builds14:47
qschulzour concern at the moment is to make the build faster basically14:48
rburtonleft to its own devices a heavily parallel build can end up getting OOMd, xz lets you control memory usage and threading nicely14:48
rburtonwhich is why its used in oe-core master14:48
rburtonwarrior has that too14:49
rburtonso consider just upgrading :)14:49
qschulz"warrior has that too"?14:51
rburtonthe use of threaded xz14:51
qschulzbecause thud does not have it?14:51
qschulz(sorry for the dumb questions, brain is fried for this week)14:51
rburtonhm no thud has xz too, just doesn't control its memory usage14:52
rburtonOPKGBUILDCMD ??= "opkg-build -Z xz"14:52
rburtonso you can easily tweak opkg-build to do a multithreaded xz14:53
rburtonyou might want to backport then you're happy14:54
rburtonRP: oh my api-doc world thing didn't land, so i shouldn't feel bad :)14:56
RPrburton: no, not yet. Enough other moving bits14:56
rburtonwell i have a tweak to make it exclude webkitgtk to save half an hour :)14:57
RPrburton: ok, cool14:57
RPrburton: autobuilder helper change?14:57
rburtonross/gtkdoc in the repo14:57
JPEWRP: 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
RPJPEW: Its do_populate_lic that complicated things, that was still valid15:00
RP(and depends on tasks pre configure)15:00
JPEWRP: Ok, that makes sense15:01
JPEWRP: Out of curiosity, how do you know it was that task?15:02
RPJPEW: I just recognise the patterns15:03
RPJPEW: populate_lic is nearly always reused from sstate as it only depends on the sources15:04
JPEWRP: I figured :) Looking at a lot of these logs gives a good feel for what should be running15:05
*** prabhakarlad <prabhakarlad!c18ddb24@> has quit IRC15:06
*** marler899763 <marler899763!> has joined #yocto15:06
*** Crofton <Crofton!> has joined #yocto15:08
JPEWRP: 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
RPJPEW: that isn't what I think happened15:09
RPJPEW: I think all of adwaita-icon-theme came from sstate originally so the build marked many of the tasks as skipped15:10
RPwhen the hashes changed, its having trouble "unskipping" tasks which became buildable15:10
JPEWRP: OK, that makes sense15:11
RPJPEW: adwaita-icon-theme:do_patch is buildable before gtk+ populate_sysroot completes15:11
RPJPEW: 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 though15:12
*** JaMa <JaMa!> has joined #yocto15:13
* JPEW finds a whiteboard....15:16
*** lucaceresoli <lucaceresoli!> has quit IRC15:22
JPEWRP: How do you know do_patch was buildable?15:27
RPJPEW: I'm guessing a bit :/15:27
RPJPEW: I've spent a long time staring at the code15:27
RPJPEW: I can't explain it any other way15:28
JPEWRP: You have bitbake ESP15:28
RPJPEW: More like spent the day on this :(15:29
RPJPEW: I'm open to others ways to explain why it breaks15:29
RPJPEW: we could try
RPJPEW: for determinism we may want to have a report_unihash there15:31
RPJPEW: not sure what we can use as outhash as we don't have one15:32
*** asabil <asabil!> has quit IRC15:32
*** Bunio_FH <Bunio_FH!> has quit IRC15:33
*** Crofton <Crofton!> has quit IRC15:33
JPEWRP: Hmm..... perhaps worth a try, but I'm not sure it's quite the right thing.15:36
qschulzrburton: 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
JPEWRP: How reproducible is this?15:37
qschulzit'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
RPJPEW: happens on the autobuilder in 2-3 builds?15:38
qschulzor is it not ideal because it installs everything to a sysroot that we shouldn't need?15:38
RPqschulz: it might work but opkg-utils doesn't depend on it so its technically wrong15:39
RPJPEW: I don't like this but I can't see another way for things to work15:39
qschulzRP: such an idiot...15:39
qschulzRP: BTW, RDEPENDS for a native package should work in master now? because I guess that's what should be needed right>?15:40
RPqschulz: it kinds of works15:42
RPqschulz: think about how RDEPENDS works when PACKAGES=""15:42
RP(which is why its 'fun')15:42
qschulzRP: I saw that test in package_ipk.bbclass, when does this happen?15:44
qschulzin images?15:44
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:47
RPqschulz: when does what happen? Sorry but I really need to concentrate on other things :/15:47
*** yacar_ <yacar_!~yacar@> has quit IRC15:49
*** sgw <sgw!~sgw@> has quit IRC15:49
rburtonqschulz: package-ipk.bbclass shows exactly how to add dependencies for packaging15:50
qschulzRP: PACKAGES="". no worries, it's just curiosity :)15:50
RPqschulz: native.bbclass15:51
rburton if you're having trouble15:51
qschulzrburton: 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
rburtonwhat the class does is the one way15:52
marler899763do bitbake files have issues with HEREDOC in bash functions?15:52
qschulzrburton: well, PACKAGE_WRITE_DEPS in conf/local.conf is another way15:52
RPmarler899763: our parser may15:53
rburtonqschulz: fails if you need the thing to build the thing15:53
*** dreyna <dreyna!> has joined #yocto15:55
smurraymarler899763: there's a few recipes in the AGL layers that use here documents15:56
marler899763I'm guessing HEREDOC works so long as you don't use certain characters15:57
qschulzrburton: *facepalm*, that's what I get for trying to be smart on a Friday afternoon16:03
*** goliath <goliath!> has quit IRC16:06
qschulzrburton: 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
RPJPEW: step1d looks "fun" :(16:19
*** yann <yann!~yann@> has quit IRC16:20
*** litb <litb!~js@> has joined #yocto16:25
litbhello all16:25
litbI've just found out about the "Ostro" Operating system16:25
litbit's now dead. why was it abandoned?16:26
rburtonhm what one was ostro16:26
RPrburton: its bad when you can't even remember!16:27
rburtonwas that the nokia collab?16:27
zeddiirburton. its that's steaming, burning wreckage on the side of the raod.16:27
rburtonno, it wasn't16:27
litbi just read about it in
rburtonlitb: abandoned for boring business reasons16:27
litbapparently it's an operating system for embedded, based on yocto16:27
litbrburton, oh hmm16:28
RPrburton: Ostro was the YP based embedded distro one iirc?16:28
rburtonthe layers are still online16:28
litbmaybe we could use it to build our own16:28
rburton'be inspired by it', the layers are untouched16:28
zeddiiand it was a lot of reshashed and recycled failed design ideas ;)16:28
rburtoniot refkit is similar idea but a bit more recent16:28
litbcurrently we are trying to figure out how to make our firmware app boot up using systemd16:28
rburtonlitb: well, surely that's just turning on systemd: two lines in your distro conf16:29
litbwe 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
RPrburton: its one isn't it?16:29
rburtonRP: i was including setting distro features16:29
litbI'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
RPrburton: INIT_MANAGER = ?16:30
rburtonlitb: for what you want, ostro isn't relevant.  you're talking about general systemd use.16:30
litbrburton, 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
rburtonlitb: if you're using systemd then i believe you don't have a choice for splash16:31
rburtonpsplash and systemd don't get on well iirc16:31
litbcurrently i use yocto's init framework for initramfs. and systemd as /sbin/init16:32
litbfor splash i use plymouth16:32
rburtonright, solved then :)16:33
*** goliath <goliath!> has joined #yocto16:33
litbalso I'm not using grub as my boot manager, because yocto/oe doesn't provide ready to use wic scripts for grub+bios16:33
litbso i have to use syslinux currently and need to figure out the steps to install grub later16:33
rburtoneww bios :)16:34
*** marler899763 <marler899763!> has quit IRC16:34
*** mckoan is now known as mckoan|away16:36
*** sgw <sgw!sgw@nat/intel/x-ieicypkuwuiyfpej> has joined #yocto16:37
RPrburton: is a master failure - don't understand how/why :(16:38
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:08
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:11
JPEWRP: 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!> has joined #yocto17:25
marler899766ugh...ran out of disk space again17:26
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:26
marler899766You would think 500 GB would be big enough for 4 yocto builds...17:26
*** sgw <sgw!sgw@nat/intel/x-ieicypkuwuiyfpej> has quit IRC17:33
*** creich_ <creich_!~creich@2a02:8106:217:2100:d01:182b:8d17:626d> has quit IRC17:34
*** georgem <georgem!~georgem@> has quit IRC17:42
*** georgem <georgem!~georgem@> has joined #yocto17:43
*** georgem <georgem!~georgem@> has quit IRC17:44
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto17:45
*** goliath <goliath!> has quit IRC17:47
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:47
*** sgw <sgw!~sgw@> has joined #yocto17:47
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC17:57
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto17:59
khemRP: uim failure is due to parallel install race18:00
khemI have pushed a potential fix lets see if that works then we will be green on that tumbleweed box18:00
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC18:00
*** litb <litb!~js@> has quit IRC18:25
*** aehs29 <aehs29!~aehs29@> has quit IRC18:28
*** gattuso <gattuso!> has quit IRC18:28
*** elGamal <elGamal!~elg@> has quit IRC18:28
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto18:28
*** elGamal <elGamal!~elg@> has joined #yocto18:29
*** gattuso <gattuso!> has joined #yocto18:31
ecdheHow can I make yocto generate a vmlinuz file?18:47
mischiefi'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
ecdheI get a tar.gz of the filesystem and an Image file containing the kernel, but no vmlinuz.18:56
mischiefecdhe: what do you think Image is? :)18:58
mischiefecdhe: look at KERNEL_IMAGETYPE in the yocto manual.. 'make help' in the kernel tree and looking at the kernel bbclasses can also be instructive18:59
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC19:02
ecdhethanks 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 mustard19:02
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto19:04
*** tgamblin <tgamblin!~tgamblin@> has quit IRC19:11
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC19:15
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto19:16
*** Bunio_FH <Bunio_FH!> has joined #yocto19:21
*** khem <khem!~khem@unaffiliated/khem> has quit IRC19:39
*** goliath <goliath!> has joined #yocto19:40
*** comptroller <comptroller!> has quit IRC19:47
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto19:48
*** comptroller <comptroller!> has joined #yocto19:58
*** Crofton <Crofton!> has joined #yocto20:07
*** yates <yates!> has quit IRC20:07
*** yann <yann!> has joined #yocto20:08
kergothhmm,. no man pages in non-gplv3 due to man-db.. seems like mandoc will do the job, though..20:18
*** Crofton <Crofton!> has quit IRC20:19
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC20:27
*** Crofton <Crofton!> has joined #yocto20:29
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto20:33
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC20:47
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:48
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has joined #yocto20:50
*** JaMa <JaMa!> has quit IRC20:51
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:608b:335c:9d15:556a> has quit IRC20:53
*** Crofton <Crofton!> has quit IRC20:56
*** WillMiles <WillMiles!> has quit IRC21:22
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto21:34
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC21:36
*** aidanh_ is now known as aidanh21:36
RPkhem: ok, sounds like you're close to sorting it! :)21:41
RPJPEW: I'll leave that one with you then, thanks21:41
*** aehs29 <aehs29!~aehs29@> has joined #yocto22:02
*** palate <palate!~palate@unaffiliated/palate> has joined #yocto22:09
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:13
*** rburton <rburton!> has quit IRC22:17
*** georgem <georgem!~georgem@> has joined #yocto22:17
*** agust <agust!> has quit IRC22:22
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:09

Generated by 2.11.0 by Marius Gedminas - find it at!