Tuesday, 2019-01-08

*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-091-089-212-176.hsi2.kabel-badenwuerttemberg.de> has quit IRC00:25
*** tgraydon <tgraydon!textual@nat/intel/x-grohxqxxpmwycdnn> has quit IRC00:25
*** tgraydon <tgraydon!~textual@> has joined #yocto00:29
*** tgraydon <tgraydon!~textual@> has quit IRC00:37
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-091-089-212-176.hsi2.kabel-badenwuerttemberg.de> has joined #yocto00:38
*** gtristan <gtristan!~tristanva@> has joined #yocto00:56
*** Willy-- <Willy--!~william@> has joined #yocto01:01
*** mihais <mihais!~mihaiserb@> has quit IRC01:02
*** tgraydon <tgraydon!~textual@> has joined #yocto01:02
*** sgw <sgw!sgw@nat/intel/x-lrevushrjynkskfs> has quit IRC01:05
*** sgw <sgw!~sgw@> has joined #yocto01:07
*** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has quit IRC01:09
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC01:16
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC01:54
robbawebbaderRichard: is that related to the GO_LINKSHARED variable that I included in my recipe?01:54
*** yann <yann!~yann@lfbn-1-515-227.w86-245.abo.wanadoo.fr> has quit IRC01:59
*** yann <yann!~yann@lfbn-1-515-227.w86-245.abo.wanadoo.fr> has joined #yocto02:12
*** tgraydon <tgraydon!~textual@> has quit IRC02:17
*** gtristan <gtristan!~tristanva@> has quit IRC02:17
*** gtristan <gtristan!~tristanva@> has joined #yocto02:24
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC03:09
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto03:11
yoctiNew news from stackoverflow: Adding iptables to yocto causes image do_rootfs to fail due to wrong kernel version [closed] <https://stackoverflow.com/questions/54009728/adding-iptables-to-yocto-causes-image-do-rootfs-to-fail-due-to-wrong-kernel-vers>03:33
*** gtristan <gtristan!~tristanva@> has quit IRC03:41
*** gtristan <gtristan!~tristanva@> has joined #yocto03:48
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto04:17
*** sgw <sgw!~sgw@> has quit IRC04:42
*** sgw <sgw!~sgw@> has joined #yocto04:49
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC04:51
*** lazyape <lazyape!~lazyape@athedsl-212890.home.otenet.gr> has joined #yocto04:59
*** thaytan <thaytan!~thaytan@121-200-23-18.cust.aussiebb.net> has quit IRC05:00
*** thaytan <thaytan!~thaytan@121-200-23-18.cust.aussiebb.net> has joined #yocto05:00
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC05:05
*** dv_ <dv_!~dv@> has quit IRC05:23
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-wbortzkahipkhacr> has quit IRC05:30
*** Willy-- <Willy--!~william@> has quit IRC05:34
*** dv_ <dv_!~dv@> has joined #yocto05:37
*** hamis <hamis!~irfan@> has joined #yocto05:55
*** AndersD <AndersD!~AndersD@> has joined #yocto06:09
*** AndersD <AndersD!~AndersD@> has quit IRC06:11
*** AndersD <AndersD!~AndersD@> has joined #yocto06:11
*** AndersD <AndersD!~AndersD@> has quit IRC06:12
*** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto06:13
*** kaspter <kaspter!~Instantbi@> has quit IRC06:22
*** jobroe <jobroe!~manjaro-u@> has joined #yocto06:31
*** jobroe <jobroe!~manjaro-u@> has quit IRC06:36
*** jobroe <jobroe!~manjaro-u@> has joined #yocto06:38
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:c576:ca50:a970:f742> has joined #yocto06:38
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:07
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:12
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto07:12
*** tprrt <tprrt!~tprrt@> has joined #yocto07:13
*** cvasilak <cvasilak!~cvasilak@ppp-94-66-233-157.home.otenet.gr> has joined #yocto07:18
*** gtristan <gtristan!~tristanva@> has quit IRC07:27
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto07:33
*** yann <yann!~yann@lfbn-1-515-227.w86-245.abo.wanadoo.fr> has quit IRC08:02
*** kaspter <kaspter!~Instantbi@> has quit IRC08:02
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:04
*** fl0v0 <fl0v0!~fvo@mue-88-130-104-097.dsl.tropolys.de> has joined #yocto08:10
*** egavin <egavin!~egavin@24.red-217-126-80.staticip.rima-tde.net> has joined #yocto08:17
*** kaspter <kaspter!~Instantbi@> has quit IRC08:20
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:21
*** kaspter <kaspter!~Instantbi@> has quit IRC08:45
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:45
*** falkb <falkb!91fdde45@gateway/web/freenode/ip.> has joined #yocto08:56
*** lumpi_ <lumpi_!91fdde45@gateway/web/freenode/ip.> has joined #yocto08:58
*** lumpi_ is now known as Guest1410108:59
*** mihais <mihais!~mihaiserb@> has joined #yocto09:02
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto09:05
derRichardrobbawebba: could be09:06
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC09:12
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:21
*** norman <norman!~norman@> has joined #yocto09:21
*** norman <norman!~norman@> has quit IRC09:24
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:24
*** florian_kc is now known as florian09:25
*** normguf <normguf!~norman@> has joined #yocto09:25
*** JaMa <JaMa!~martin@> has joined #yocto09:25
*** normguf <normguf!~norman@> has quit IRC09:27
*** normguf <normguf!~norman@> has joined #yocto09:28
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC09:30
normgufhey there. quick question on recipes: I have a recipe that links a wrapper into /usr/bin/cmd, and another recipe, which I want to overwrite this link. Is there a possibility to enforce a overwrite? For now I can't build my image, because of a conflicts error. Or is the only solution to append to the recipe which creates the link in the first place?09:30
*** ant_work <ant_work!~ant__@host184-22-dynamic.15-87-r.retail.telecomitalia.it> has joined #yocto09:34
*** yann <yann!~yann@lfbn-idf1-1-33-83.w82-124.abo.wanadoo.fr> has joined #yocto09:37
*** rburton <rburton!~rburton@> has joined #yocto10:04
*** alinucs <alinucs!~abo@static-176-158-51-218.ftth.abo.bbox.fr> has joined #yocto10:05
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto10:08
*** otavio_ <otavio_!~otavio@static.> has quit IRC10:09
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:31
*** berton <berton!~berton@> has joined #yocto10:41
RPrburton: -next was a green build, ok to merge?10:56
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto10:57
*** falk0n <falk0n!~falk0n@a109-49-153-10.cpe.netcabo.pt> has quit IRC11:00
*** falk0n <falk0n!~falk0n@a109-49-153-10.cpe.netcabo.pt> has joined #yocto11:01
rburtonRP: so the toolchain change shows that icecc in multilib sdks is broken.  it was broken before (would only work for the primary tune) but now its more broken.11:02
rburtonRP: not sure if we just note and file a bug (for JPEW?), or want to wait until that is handled11:03
rburtonapart from that yes11:03
RPrburton: hmm. I'm tempted just to proceed. Is it obviously broken?11:03
*** ieio <ieio!975b220a@gateway/web/freenode/ip.> has joined #yocto11:04
rburtoncurrently icecc's nativesdk setup just uses the default tune, and the setup script is ran once with that tune.11:04
rburtonnow, it will run for every tune and i'm not sure what happens: worst case it sets up for a multiarch tune but writes to a file with the name of the base tune?11:05
rburtonnot looked at icecc much11:05
rburtonwill file a bug anyway11:05
RPrburton: the case where there is one tune should work as before?11:05
rburtonyeah, for one tune my change is a no-op11:05
RPrburton: so we just make the broken case more broken? :)11:05
* RP can live with that11:07
*** LowLander <LowLander!~erwin@ip51ce2bef.speed.planet.nl> has quit IRC11:16
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:21
*** LowLander <LowLander!~erwin@ip51ce2bef.speed.planet.nl> has joined #yocto11:22
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC11:28
rburtonRP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13128 fwiw11:32
yoctiBug 13128: normal, Undecided, ---, JPEWhacker, NEW , nativesdk-icecc doesn't work for multilib SDKs11:32
RPrburton: thanks11:33
derRichardwho maintains the go.bbclass file?11:33
derRichardus this person here on irc?11:33
*** otavio_ <otavio_!~otavio@static.> has joined #yocto11:34
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto11:40
kanavinRP: thanks, there was just one issue (with perl-ptest package being erroneously pulled in). This is now fixed, so we can do maybe another spin? http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/perl-sanity11:43
RPkanavin: fired11:48
RPderRichard: khem and maybe otavio11:48
derRichardkhem: otavio: i'm facing go runtime errors on x86_64, they happen because go.bbclass uses a shared go runtime library. so far i'm not sure whether this is an go upstream issue or a yocto problem11:50
derRicharddid you see something like that in the past?11:50
derRichardthe errors are always:11:53
derRichardruntime: unknown pc in defer 0x564f3b23ea5011:53
derRichardfatal error: unknown pc11:53
*** falk0n <falk0n!~falk0n@a109-49-153-10.cpe.netcabo.pt> has quit IRC11:58
*** falk0n <falk0n!~falk0n@a109-49-153-10.cpe.netcabo.pt> has joined #yocto11:58
*** Guest14101 <Guest14101!91fdde45@gateway/web/freenode/ip.> has quit IRC12:05
rburtonRP: rootfs.py, line 744 _file_equal12:06
rburtonRP: why is opkg rootfs doing prelink things when none of the others do?12:07
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto12:13
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto12:13
*** LowLander <LowLander!~erwin@ip51ce2bef.speed.planet.nl> has quit IRC12:18
*** aratiu <aratiu!~adi@> has quit IRC12:22
*** aratiu <aratiu!~adi@> has joined #yocto12:27
*** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has quit IRC12:33
ant_workrburton, I have googled right now for a similar issue  [YOCTO #1894]12:35
ant_workabout issues with multilib vs. python 2.712:36
ant_work do_rootfs: Multilib check error: duplicate files12:37
ant_workwell, it seems the example in Yocto docs do not cope with stubborn recipes12:38
RPrburton: I don't know, that is very very strange12:39
rburtonRP: hopefully fray has some history?12:39
RPrburton: looks like incremental image issues with prelinked filed12:41
*** Guest87s <Guest87s!5f764301@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto12:42
RPrburton: I suspect incremental rpm doesn't need this12:42
ant_workseem sprelink was added to tweak _multilib_sanity_test12:42
rburton1) that should be checking if prelink is enabled12:42
rburton2) does anyone actually use incremental generation?12:42
RPI am tempted to drop the incremental generation everywhere12:43
RPand yes, 1) is a bug12:43
rburtonant_work: patches welcome?12:44
rburton(to add a prelink enabled check wrapping the prelink calls)12:45
*** mihais <mihais!~mihaiserb@> has quit IRC12:46
ant_workheh, ok, I was unsure it is a bug or an 'impossible' implementation12:47
ant_workbecause if you read last (2016) comments I found about this, Khem suggests it's just a bad idea12:47
ant_workthis happened after the prelink patch for incremental builds12:48
ant_worknow I have been pointed at python 2.7 failing beautifully :)12:48
RPant_work: the arm header situation was improved since then iirc12:48
ant_workhere is python12:50
RPant_work, rburton: the right fix above was likely to run prelink later12:50
ant_workthe developer sent me thi syesterdeay, current master12:50
*** sagivd <sagivd!51da2c11@gateway/web/freenode/ip.> has joined #yocto12:54
Piratyanyone else having trouble with 4.19.x and grub 0.97 ?13:00
sagivdHi, i hope im in the correct channel.. im having trouble changing the permission bits of various application on my OE-based platform. specifically - i try to change the application permissions for busybox and shadow applications. i tried to use do_install_append and ROOTFS_POSTPROCESS_COMMAND with no success (i.e. i see the changes in the tmp/recipe/version/image/ directory, but the final rootfs does not change). any idea what i am miss13:03
rburtonsagivd: what permissions?13:03
sagivdregular unix permissions (chmod 770 etc.) and suid bits13:04
rburtoncare to pastebin the change?13:04
sagivdoption 1: https://pastebin.com/43CNB12m13:07
sagivdoption 2: https://pastebin.com/JAsDDgPY13:07
*** Guest87s <Guest87s!5f764301@gateway/web/cgi-irc/kiwiirc.com/ip.> has left #yocto13:08
sagivdso in option 2, the files under /etc/ are changed as expected13:08
sagivdbut the /bin/login.shadow remains without suid bit13:08
sagivdin option 2 - i see the change in tmp../shadow/version/image, but it doesnt reach the machine-image rootfs13:09
sagivdplease ignore the _RW append, it was just a typo (and unrelated)13:11
rburton(2) is definitely the better fix13:11
rburtoni wonder if the alternatives code is breaking the bits accidentally, try touching other files that are not being fiddled by alternatives to test13:12
sagivdok ill check13:13
rburtonRP: can you drop the pulse patch from next, i've got a better one coming13:15
sagivdits compiling13:19
sagivdif the alternatives is the issue, since im using only a single source per app - can i just remove them from the alternative list?13:19
rburtonbetter to fix alternatives13:20
sagivdit looks like its something else13:22
sagivdi added "chmod 4777 ${D}${sysconfdir}/login.defs" to do_install_append() of shadow, got permission bits -rwxr-xr-x for login.defs13:23
sagivdin the rootfs image13:23
sagivdand -rwsr-xr-x in the shadow recipe13:23
RPrburton: dropped13:27
ak77why does runqemu has hardcodded mac address... can I override it somehow?13:28
*** jobroe_ <jobroe_!~manjaro-u@> has joined #yocto13:30
*** jobroe <jobroe!~manjaro-u@> has quit IRC13:31
*** skynet <skynet!91fdde45@gateway/web/freenode/ip.> has joined #yocto13:32
ak77huh, yes I can, only whole netdev qemu arg13:33
*** xtron <xtron!~mentor@> has quit IRC13:33
*** skynet <skynet!91fdde45@gateway/web/freenode/ip.> has quit IRC13:33
*** jobroe <jobroe!~manjaro-u@> has joined #yocto13:35
*** skynet <skynet!91fdde45@gateway/web/freenode/ip.> has joined #yocto13:35
*** jobroe_ <jobroe_!~manjaro-u@> has quit IRC13:36
*** mihais <mihais!~mihaiserb@> has joined #yocto13:43
ant_workrburton, so it's another reason at the end...13:45
*** maudat <maudat!~moda@> has joined #yocto13:46
*** mckoan|away is now known as mckoan13:47
*** zeddii <zeddii!~bruce@> has joined #yocto13:50
*** AndersD <AndersD!~AndersD@> has joined #yocto13:53
*** AndersD_ <AndersD_!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto13:55
*** AndersD <AndersD!~AndersD@> has quit IRC13:57
ak77to answer to myself: no, it's not possible to influence qemu mac address when using runqemu14:00
derRichardak77: like with all wrappers around qemu, there is always a config option you want to set but is hardcoded in the wrapper :-)14:01
ak77:S :)14:01
ak77there is QB_NETWORK_DEVICE in qemuboot though14:01
ak77it a bbclass, I could affect that14:02
ak77or, if I could find out where the qemuboot.conf file is, i could sed @MAC@ mymac it14:05
JPEWrburton: I didn't think the AB did anything with icecc, how did you discover it was broken?14:06
*** marka <marka!~masselst@> has joined #yocto14:07
rburtonJPEW: eyeballs14:08
rburtonJPEW: changed how the post-relocate hook behaved, so looked to see what else was using it14:08
JPEWrburton: Ah, that makes sense14:08
rburtonif i'm actually wrong feel free to tell me so, but from what i understand its broken in multilib :)14:08
*** sagivd <sagivd!51da2c11@gateway/web/freenode/ip.> has quit IRC14:09
JPEWYa, I'm not sure. I will take a look. multlib is another one of those things I'm not very familar with14:09
rburtonthe TARGET_PREFIX variable set by the environment script seems to be a reasonable unique id, different for each multilib tune at least14:10
*** JaMa <JaMa!~martin@> has quit IRC14:17
normgufhey there. quick question on recipes: I have a recipe that links a wrapper into /usr/bin/cmd, and another recipe, which I want to overwrite this link. Is there a possibility to enforce a overwrite? For now I can't build my image, because of a conflicts error. Or is the only solution to append to the recipe which creates the link in the first place?14:28
rburtonyou can't have two packages that provide the same file installed at once14:29
rburtonif you want to be able to switch between those, then use update-alternatives14:29
rburtonthat will give you a cmd symlink that points to whatever one is selected with priorities etc14:29
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto14:33
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC14:35
kanavinRP: so how could upstream version checks be parallelized? I am not sure actually.14:38
rburtonRP: what i posted on the list for pulse has a bad commit message, ross/mut has the latest patches14:40
normguf@rburton: thanks for clarification14:41
RPkanavin: wrap the call site in a multiprocessing or threading block14:42
* RP tends to trust multiprocessing more14:42
kanavinRP: multiprocessing is not going to work (because it needs to serialize the recipe data, and it includes non-serializable lock objects).14:44
kanavinRP: so I tried with multithreading, and it resulted in bizarre data corruption errors14:45
RPkanavin: can't you obtain the data you need in the process and just hand a result back?14:45
kanavinRP: can you explain please?14:47
RPkanavin: I guess the piece I'm forgetting here is tinfoil14:49
RPthe datastore connection over tinfoil is serialised14:50
RPto avoid that you'd need multiple build directories each with a tinfoil server14:51
RPwe do have code for that with oe-selftest parallelisation but the problem isn't as easily solved as I was thinking14:52
RPkanavin: creating tinfoil API to do it is tempting14:52
rburtonanyone know what yocto release corresponds to wind river 8?14:52
RPrburton: fray should14:53
kanavinRP: for example, I wanted to create a plugin to 'bitbake-layers' that would give an overview of recipes update status, but then realized no one would want to wait 12 minutes for it14:53
kanavinwith parallelization it used to be 90 seconds or so14:53
RPkanavin: We should talk with Paul but I think we need some kind of parallel execution tinfoil API14:55
*** hamis <hamis!~irfan@> has quit IRC14:58
kanavinRP: yep14:59
yoctiNew news from stackoverflow: Cross compilling .deb package for yocto image?i.e remot3.it [closed] <https://stackoverflow.com/questions/54021031/cross-compilling-deb-package-for-yocto-imagei-e-remot3-it>15:05
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC15:06
*** jobroe <jobroe!~manjaro-u@> has quit IRC15:07
*** skynet <skynet!91fdde45@gateway/web/freenode/ip.> has quit IRC15:21
*** mihais <mihais!~mihaiserb@> has quit IRC15:22
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto15:28
paulbarkerHas anyone else ran into "File name too long" errors when building on master? Looks like bitbake is trying to create an sstate file with a 257 character name15:29
paulbarkerI assume this is related to the recent switch from md5 to sha256 pushing the file name lengths up15:29
paulbarkerI do have a relatively long package name (containerd-opencontainers), long target triplet (cortexa7t2hf-neon-vfpv4-poky-linux-musleabi) and long version number (v1.0.2+gitcfd04396dc68220d1cecbe686a6cc3aa5ce3667c), but I'm sure I'm not the only one who will run into such a combination15:32
kergoththat does sound like a bug15:34
frayI didn't realize there was a character limit on a filename, overall path length definitely15:35
*** mihais <mihais!~mihaiserb@> has joined #yocto15:35
RPpaulbarker: which filesystem is that?15:35
yoctiNew news from stackoverflow: Which module to install to fix "module QtQuick.Controls.Styles is not installed" error for Yocto? <https://stackoverflow.com/questions/50184485/which-module-to-install-to-fix-module-qtquick-controls-styles-is-not-installed>15:35
JPEWIs it possible to run a python function (not task) under pseudo? (e.g. fakeroot python foobar(arg1, arg2, d)))15:35
frayfakeroot python task() {15:36
frayI swear that works15:36
fraysince it's used in package generation15:36
frayyou can't do it in a -function-, only a recipe task15:36
paulbarkerRP: It's xfs, but https://serverfault.com/a/9548 suggests that the 255 char limit applies more widely as well15:37
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC15:39
paulbarkerIt doesn't help that the containerd recipe uses the full ${SRCREV} in PV instead of just ${SRCPV}, fixing that should get me below 255 chars here. But definitely an issue that's likely to re-occur15:39
frayin the past when we've hit some issues like that, we've put in a max charater count and just truncated.. it's not the greated solution, but it worked in those cases..15:40
fraywith a checksum in place -- I'm not sure we can do it that way..15:40
RPpaulbarker: hmm. We can easily fix this since the only bit of the filename that is important is the hash15:40
fraymay have to truncate on the name/version not the whole filename15:40
RPpaulbarker: the other bit is for user use for debugging so we can truncate it15:40
paulbarkerIt's the file name length limit not the path length limit that's being hit so an alternative would be to add another level of hierarchy on something like the package name and/or target triplet15:41
*** AndersD_ <AndersD_!~AndersD@194-237-220-218.customer.telia.com> has quit IRC15:42
paulbarkerI do see both the target triplet (cortexa7t2hf-neon-vfpv4-poky-linux-musleabi) and the tune (cortexa7t2hf-neon-vfpv4) in the file name so that's some repetition that could be dropped15:42
RPpaulbarker: split level makes little sense given this data is just for human readability use15:44
RPreducing duplicate info would be good15:44
paulbarkerOk, for reference the full problem name is 'sstate:containerd-opencontainers:cortexa7t2hf-neon-vfpv4-poky-linux-musleabi:v1.0.2+gitcfd04396dc68220d1cecbe686a6cc3aa5ce3667c:r0:cortexa7t2hf-neon-vfpv4:3:8cf9e07e17de9682ef6e3eb78ac3eca8f942c2a833c4a7f5096cda401c1711e1_prepare_recipe_sysroot.tgz.siginfo'15:45
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC15:46
JPEWfray: Thats annoying :)15:46
*** ant_work <ant_work!~ant__@host184-22-dynamic.15-87-r.retail.telecomitalia.it> has quit IRC15:47
*** sjolley1 <sjolley1!86868b4b@gateway/web/freenode/ip.> has joined #yocto15:50
paulbarkerThe exact failure point is the os.rename call in SignatureGeneratorBasic.dump_sigtask, bitbake/lib/bb/siggen.py15:50
sjolley1YPTM: https://zoom.us/j/99089271215:55
sjolley1YPTM: sjolley joined15:55
*** normguf <normguf!~norman@> has quit IRC15:56
armpitYPTM: armin is one15:56
RParmpit: dual personalities under control today? :)15:57
*** JPEW_ <JPEW_!cc4da371@gateway/web/freenode/ip.> has joined #yocto15:57
* RP is also one15:58
RP(and on)15:58
JPEW_YPTM: Joshua Watt here15:59
vmesonYPTM: Randy MacLeod joined.15:59
rburtonYPTM: ross is two16:00
CroftonRP, we took away his beer16:01
tlwoernerYPTM: is on the call16:01
*** rcw <rcw!~rcw@> has joined #yocto16:02
* armpit breaking up is easy to do16:03
sjolley1YPTM Minutes : https://docs.google.com/document/d/1Y5IIuE-z0Ykdl-DwuzUJh52flOZuhN_TSAfw2tdU9pg/edit?ts=5c06b22d16:03
tlwoernerarmpit: lol16:03
*** richardg <richardg!~richard@> has joined #yocto16:03
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC16:05
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:c576:ca50:a970:f742> has quit IRC16:05
*** jcureton <jcureton!cc4da374@gateway/web/freenode/ip.> has joined #yocto16:06
*** mwhoosier <mwhoosier!cc4da368@gateway/web/freenode/ip.> has joined #yocto16:07
mwhoosierYPTM: Matt Hoosier (Garmin) here16:08
*** richardg <richardg!~richard@> has quit IRC16:12
*** egavin <egavin!~egavin@24.red-217-126-80.staticip.rima-tde.net> has quit IRC16:12
*** ragriffi <ragriffi!c0373626@gateway/web/freenode/ip.> has joined #yocto16:12
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto16:13
*** martinkelly <martinkelly!~martin@hq.xevo.com> has joined #yocto16:13
*** gtristan <gtristan!~tristanva@> has joined #yocto16:14
*** mwhoosier <mwhoosier!cc4da368@gateway/web/freenode/ip.> has quit IRC16:25
*** ragriffi <ragriffi!c0373626@gateway/web/freenode/ip.> has quit IRC16:25
*** richardg <richardg!~richard@> has joined #yocto16:26
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC16:26
*** richardg <richardg!~richard@> has left #yocto16:26
*** jcureton <jcureton!cc4da374@gateway/web/freenode/ip.> has quit IRC16:29
sjolley1YPTM is over16:29
*** sjolley1 <sjolley1!86868b4b@gateway/web/freenode/ip.> has quit IRC16:29
*** JPEW_ <JPEW_!cc4da371@gateway/web/freenode/ip.> has quit IRC16:30
paulbarkerRP: I'm hacking on a patch to shorten the sstate file names without dropping all the useful info, will send as an RFC once it looks ok to me16:31
RPpaulbarker: sounds good thanks16:31
*** StefanS__ <StefanS__!c1f0f176@gateway/web/freenode/ip.> has joined #yocto16:33
*** bentech <bentech!~bentech@unaffiliated/bentech> has joined #yocto16:33
paulbarkerSomething like "${PF}:${SSTATE_PKGARCH}:${SSTATE_VERSION}:" should give enough human readable info, I'll also see if I can limit the length of some of those automatically16:35
StefanS__Hello. Has anything changed between sumo and thud related to package-index? In sumo, it was enough to bitbake <image> and the index (Packages files) were automatically created in tmp/deploy/ipk, but in thud these are missing. Only if I call bitbake package-index I get them back. I'd like to know what changed, and how can I get the old behaviour back16:35
kanavinStefanS__: I think you always (officially) had to issue package-index separately, if you got index files from just making an image, that was undocumented behaviour.16:37
StefanS__I thought I had to run that only when building a new recipe/package and needed the index to be updated. It's weird since code lib/oe/rootfs seems to indicate that the index is ran all the time at rootfs time16:38
*** Alder <Alder!91fdde45@gateway/web/freenode/ip.> has joined #yocto16:41
*** ieio <ieio!975b220a@gateway/web/freenode/ip.> has quit IRC16:43
*** denix <denix!~denix@pool-100-15-91-218.washdc.fios.verizon.net> has left #yocto16:45
*** denix <denix!~denix@pool-100-15-91-218.washdc.fios.verizon.net> has joined #yocto16:45
AlderAnyone here who managed a customized i.MX8 yocto linux? I have i.MX_Yocto_Project_User's_Guide_Linux.pdf and were able to build the Linux yocto image which the vendor provides, but now I want to start to customize that for my own image.16:46
*** cvasilak <cvasilak!~cvasilak@ppp-94-66-233-157.home.otenet.gr> has quit IRC16:46
AlderI think I need a better description how to do that. That PDF description is not quite good.16:47
AlderAny other tutorial available for i.MX8?16:48
*** maudat <maudat!~moda@> has quit IRC16:54
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC16:55
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto17:01
Alderhmm urgs...17:05
*** Alder <Alder!91fdde45@gateway/web/freenode/ip.> has quit IRC17:05
*** bentech_ <bentech_!~bentech@unaffiliated/bentech> has joined #yocto17:06
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto17:06
*** bentech <bentech!~bentech@unaffiliated/bentech> has quit IRC17:07
*** bentech_ is now known as bentech17:07
*** mckoan is now known as mckoan|away17:11
*** LowLander <LowLander!~erwin@ip51ce2bef.speed.planet.nl> has joined #yocto17:19
tgoodwinmissed a window on that click... lol17:23
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:24
*** fl0v0 <fl0v0!~fvo@mue-88-130-104-097.dsl.tropolys.de> has quit IRC17:29
StefanS__ah found it17:29
StefanS__26a786f86989ce47eac4eecec3b0798730194b05 I think this one changed the behaivour17:30
StefanS__kanavin: ^17:30
*** yann <yann!~yann@lfbn-idf1-1-33-83.w82-124.abo.wanadoo.fr> has quit IRC17:39
RPStefanS__: the indexes were moved to the image workdir since multple images in parallel had interesting race issues17:39
RPStefanS__: you need to use package-index to say *when* you want the indexes created as any other way is ambiguous17:40
StefanS__yup, got it17:43
StefanS__I was just confused because in sumo the indexes were in DEPLOY_IPK_DIR and now were missing, and wanted to get the same behaviour17:44
StefanS__I'll just run package-index at the end17:44
*** StefanS__ <StefanS__!c1f0f176@gateway/web/freenode/ip.> has quit IRC17:46
*** armpit <armpit!~armpit@2601:202:4180:c33:7513:b68a:6d2a:56d9> has quit IRC17:59
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto18:00
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto18:06
*** gtristan <gtristan!~tristanva@> has quit IRC18:18
*** gtristan <gtristan!~tristanva@> has joined #yocto18:21
*** gtristan <gtristan!~tristanva@> has quit IRC18:27
*** gtristan <gtristan!~tristanva@> has joined #yocto18:27
*** ravi__ <ravi__!~ravi@2a02:908:698:68a0:909:6ba9:a0f6:6612> has joined #yocto18:29
*** yann <yann!~yann@lfbn-1-515-227.w86-245.abo.wanadoo.fr> has joined #yocto18:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:47
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-kdjknkenmlsrrkgf> has quit IRC18:47
*** nate02 <nate02!~nate02@mail.validmanufacturing.com> has joined #yocto19:08
khemRP: http://lists.openembedded.org/pipermail/openembedded-core/2019-January/277509.html do you see any issues ?19:11
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC19:15
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto19:17
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto19:17
RPkhem: I don't really like enabling things we don't use but its probably reasonable19:22
*** nate02 <nate02!~nate02@mail.validmanufacturing.com> has quit IRC19:26
*** nate02 <nate02!~nate02@mail.validmanufacturing.com> has joined #yocto19:27
RPkanavin: for the perl changes how does ptest look before/after?19:27
*** mwhoosier <mwhoosier!cc4da337@gateway/web/freenode/ip.> has joined #yocto19:28
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC19:32
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto19:32
*** dev1990 <dev1990!~dev@dynamic-78-8-116-81.ssp.dialog.net.pl> has joined #yocto19:35
*** niro22 <niro22!~niro@> has joined #yocto19:50
*** armpit <armpit!~armpit@> has joined #yocto20:03
*** ravi__ <ravi__!~ravi@2a02:908:698:68a0:909:6ba9:a0f6:6612> has quit IRC20:04
*** Circuitsoft <Circuitsoft!4925ef68@gateway/web/freenode/ip.> has joined #yocto20:08
*** berton <berton!~berton@> has quit IRC20:18
RParmpit: could you rebase thud-next? I think I've missed some patches but its not easy for me to tell which ones20:19
RP(I have to figure out which ones to apply to bitbake, meta-yocto and so on)20:19
*** mihais <mihais!~mihaiserb@> has quit IRC20:20
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC20:21
*** marka <marka!~masselst@> has quit IRC20:21
* armpit rebase ... again... 20:22
*** gtristan <gtristan!~tristanva@> has quit IRC20:22
khemRP: I am trying to remove dependency on non busybox apps for runit to work20:23
khemzeddii: yt ?20:24
*** gtristan <gtristan!~tristanva@> has joined #yocto20:24
khemzeddii: 4.19 kernel headers have one regression20:24
RPkhem: I understand20:24
khemzeddii: we need to backport this patch https://github.com/torvalds/linux/commit/e2c4cf7f98a519eb4d95532bfa06bcaf3562fed5 to 4.1920:24
RParmpit: hopefully really simple as I think there are about three patches missing from upstream20:24
kroonhuh. why would using rm_work pull in perl-native..20:25
khemzeddii: the sample error is here http://errors.yoctoproject.org/Errors/Details/215558/20:26
armpitRP, rebase done and pushed. what is not in next yet are the bitbake-diffsig20:29
*** niro22 <niro22!~niro@> has quit IRC20:41
*** mihais <mihais!~mihaiserb@> has joined #yocto20:42
*** tprrt <tprrt!~tprrt@> has quit IRC20:42
*** zino_ <zino_!~zino@2001:b07:2e6:ccce:8174:f8a4:6f6b:389b> has joined #yocto20:44
*** mihais <mihais!~mihaiserb@> has quit IRC20:51
*** mihais <mihais!~mihaiserb@> has joined #yocto20:53
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC20:53
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto20:53
khemRP: started couple of builds here with latest master-next20:59
khemlets see how perl pans out this time20:59
*** zino__ <zino__!~zino@2-230-204-206.ip203.fastwebnet.it> has joined #yocto21:03
*** zino_ <zino_!~zino@2001:b07:2e6:ccce:8174:f8a4:6f6b:389b> has quit IRC21:03
zino__hi all, I'm moving my first steps with yocto, trying to write a recipe. I managed to package a kernel module (I see the ko file inside the rpm package) but when I bitbake core-image-minimal i get https://pastebin.com/VZs9TBSG21:08
robbawebbazino__: could you please post a snippet of your recipe?21:09
zino__robbawebba: https://pastebin.com/Bka56bD7 if that's not the relevant part I can post everything21:12
kroonJPEW, ping21:13
robbawebbazino__: Are you familiar with the module bbclass for help with the packaging and installation?21:15
zino__robbawebba: not yet: any pointer for studying the necessary documentation would be welcome. The entire documentation is huge:)21:16
* zeddii_home sees khem’s message here, after he read the email :D21:17
zino__robbawebba: I'm quite familiar with buildroot but I still feel a bit lost21:17
kroonJPEW, just mentioning it before I forget; I see random changes of data order in the depsig.do_package, for recipe initramfs-boot, file "pkgdata/runtime/initramfs-boot", the line starting with FILES_INFO. Looks like it is set by meta/classes/package.bbclass: d.setVar('FILES_INFO', json.dumps(files))21:18
zino__robbawebba: I did "inherit module" if that's what you're referring to though21:19
kroonJPEW, i mean, the digest is changing in the depsig.do_package, due to pkgdata/runtime/initramfs-boot changing randomly21:20
*** gtristan <gtristan!~tristanva@> has quit IRC21:22
JPEWkroon: Hmm, OK21:23
kroonso what im trying to say is that json.dumps() might not be deterministic21:23
JPEWkroon: Ya, I would believe that21:24
JPEWkroon: Perhaps python has something to help with that....21:24
JPEWkroon: json.dumps(..., sort_keys=True)21:25
kroonJPEW, i can try that and try to reproduce21:25
JPEWkroon: OK. I've been working on re-writing the signature generation to be more useful for you; I'll post a patch when it is done21:26
*** marka <marka!~masselst@> has joined #yocto21:27
kroonJPEW, cool. I hope it makes sense and is not too costly, I mean buildhistory could also do some post-processing on the raw data21:28
JPEWkroon: I think it won't be to bad. The hardest part is actually to get the listing to happen under fakeroot (pseudo) so it can see all the "correct" uid/gid's21:29
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC21:30
kroonJPEW, yeah sort_keys=True does the trick21:39
kroonJPEW, want me to send patch to ml ?21:40
JPEWkroon: Yes21:40
RParmpit: thanks, sorted I think21:41
RPJPEW: btw, your last patch to the list didn't quite apply against master. I just took the bit that did21:42
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC21:45
JPEWRP: Sorry, I really need to drop the "rehash running tasks" from my local sandbox21:45
RPJPEW: I know the problem, I have a ton of this kind of thing :/21:47
*** rburton <rburton!~rburton@> has quit IRC21:49
*** dl9pf2 <dl9pf2!~dl9pf2@> has joined #yocto21:51
JPEWRP: Anyway we could add a AB build that uses icecream :D.... The trick I think is that it wouldn't share sstate with any other build :(21:51
RPJPEW: we could, I'm just not sure it that many users or how much we'd have to test to make it worthwhile21:53
JPEWRP: Fair enough. FWIW, it can be inherited but disabled (ICECC_DISABLED="1") which has the advantage that you can share sstate without having to use it (And would have caught all the recent bugs).21:56
* armpit thinks he found another mutliconfig bug21:57
armpitRP, cool.. thanks21:57
*** rcw <rcw!~rcw@> has quit IRC21:58
*** dl9pf2 <dl9pf2!~dl9pf2@> has quit IRC21:58
RPJPEW: I guess I'd be ok with a parsing test for it, its things like the SDK with it enabled which I'm a bit more wary of for test matrix explosion21:59
*** dl9pf2 <dl9pf2!~dl9pf2@> has joined #yocto22:03
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC22:06
khemJPEW: is there a good how-to on using icecc22:07
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC22:08
JPEWkhem: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-icecc is pretty close. I think it could use a little more work22:09
khemJPEW: since you are fresh with icecc can you see the gaps and fill them may be22:10
JPEWkhem: Ya22:10
*** marka <marka!~masselst@> has quit IRC22:13
khemI want to do an experiment with this so what are limitationss that I should be aware of22:14
JPEWkhem: You'll want to crank up ICECC_PARALLEL_MAKE.... I use ICECC_PARALLEL_MAKE="-j 24" (for reference, PARALLEL_MAKE is "-j 8").22:15
JPEWkhem: You also may need to fiddle with ICECC_USER_PACKAGE_BL if there are recipes that don't build.22:18
JPEWkhem: Having a 15 node cluster of your co-worker's PCs helps a lot also :)22:19
* RP wonders if any openxt people are around22:22
*** bentech <bentech!~bentech@unaffiliated/bentech> has quit IRC22:24
*** dl9pf2 <dl9pf2!~dl9pf2@> has quit IRC22:25
khemJPEW: ok, I have ubuntu 14.04 and ubuntu 18.04 hosts, I hope thats not an issue22:25
*** xperia64 <xperia64!~pi@pool-71-179-254-134.bltmmd.fios.verizon.net> has quit IRC22:26
JPEWShouldn't be. We have an electic mix22:26
JPEW14.04, 18.04, Arch, Fedora22:26
khemJPEW: can you share your setup in confs ?22:27
*** dl9pf2 <dl9pf2!~dl9pf2@> has joined #yocto22:27
kheme.g. host pre-requisites etc. that are needed on build machines22:28
JPEWkhem: There isn't much configuration required on the compile nodes. Essentially it is install icecc and make sure the firewall doesn't block it.22:31
khemJPEW: ok, and its the host version whatever that distro supports ?22:32
JPEWkhem: Yes. Icecream is pretty good about being backward compatible with itself (e.g. the protocol hasn't changed much). Most of the complicated logic is on the source (client) side compiler shims, so having newer ones of them is nice, but not mandatory22:33
derRichardis distcc/icecream still a thing?22:34
JPEWderRichard: Yes22:34
khemJPEW: ok do  I need icecc-monitor as well ?22:34
JPEWIt is helpful. Or you can install https://github.com/JPEWdev/icecream-sundae (shameless plug)22:35
derRichardJPEW: i thought these days sending souces/objects via network is much slower than the actual compile job (if you have fast cpus)22:35
JPEWderRichard: I think that is true if you can't jack up the parallelism22:37
khemwell n/w has become fast too22:37
khemthink of 10G interconnects in data-centers22:37
yoctiNew news from stackoverflow: Why can't I copy files into the rootFS from a Yocto recipe <https://stackoverflow.com/questions/54100547/why-cant-i-copy-files-into-the-rootfs-from-a-yocto-recipe>22:37
khemthey will be fastr than some of SSDs22:37
khemJPEW: how is your minitor better ?22:37
*** bradleyb is now known as radsquirrel22:38
derRichardkhem: this is not the distcc use case. 10 years ago it was very useful. just connect all compuers in your office to have a decent build cluster22:38
JPEWkhem: Its command line only22:38
derRichardnow we have single nodes with many cpus but still not 10g network22:38
derRichardanyway, getting too much ot :)22:38
derRichardJPEW: icecream-sundae look nice :-)22:39
khemderRichard: you still have same usecase in build clusters in data centers22:41
khemJPEW: I see22:41
khemJPEW: so say I have two machines with icecc now if I run icecc enabled build on both of them what happens :)22:41
khemdo they attach each other with bits22:41
JPEWYes, make sure you start the scheduler daemon on at least one of them (or all of them)22:42
JPEWIt's been a while since I did that, so I don't remember exactly22:42
derRichardkhem: not sure. even in datacenters you have nodes with many local cpus. say 16 to 32. so icecc/distcc won't give you a huge speedup since make -j HUGE (like 512) does not scale22:43
khembuying large instances is expensive where as smaller instances are cheaper22:43
khempool always wins in scale22:44
khemwhen you have many devs22:44
khemJPEW: ah scheduler daemon ok22:44
derRichardit is news to me that recent datacenters use local nodes with that few cpus. even my laptop has many cores22:44
khemJPEW: so any machine that want to issue the jobs has to be running scheduler for sure22:45
JPEWNo, not necessarily. The daemon (iceccd) is separate from the scheduler (icecc-scheduler)22:45
khemso iceccd would take care of sending jobs to scheduler ?22:46
JPEWThey all have to run the daemon. One (or more, they'll do election) has to run the scheduler. For example, here we have a dedicated scheduler because it can be a little resource intensive to have running a developer PC22:46
JPEWThe scheduler just manages and assigns jobs to the daemons. They talk directly to each other once the scheduler decides who is doing what (e.g. not all data flows through the scheduler)22:47
khemyeah ok22:48
khemgot iceccd up on both22:49
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-rwpinemzjvipihbf> has joined #yocto22:49
JPEWCool. It it all works right icecream-sundae or icemon should show both nodes attached22:49
khemJPEW: OK, now starting/enabling icecc-scheduler.service on both too22:50
khemdoes it help to have multiple schedulers22:51
khemI guess yes22:51
khemyou need to publish .debs and rpms for icecream-sundae22:51
khemor maybe appimage22:51
khemsnap or flatpak22:52
JPEWI've been looking at creating a snap (never done it before, so it's a nice challenge)22:52
khemdo it once for all https://appimage.org22:52
*** xperia64 <xperia64!~pi@pool-71-179-254-134.bltmmd.fios.verizon.net> has joined #yocto22:53
JPEWI'll look at that22:53
JPEWAnyway, I have to go, so if you have more questions they will have to wait until tomorrow.22:54
khemok thx ttyl22:55
*** dl9pf2 <dl9pf2!~dl9pf2@> has quit IRC22:59
RParmpit: fired 2.6.123:04
*** dl9pf2 <dl9pf2!~dl9pf2@> has joined #yocto23:04
armpita-full ?23:09
*** xperia64 <xperia64!~pi@pool-71-179-254-134.bltmmd.fios.verizon.net> has quit IRC23:12
*** dl9pf2 <dl9pf2!~dl9pf2@> has quit IRC23:12
*** dl9pf2 <dl9pf2!~dl9pf2@> has joined #yocto23:15
derRichardhm, i get "QA Issue: Architecture did not match (x86-64, expected x86)" for my kernel build. this is expected. userspace is 32bit, but kernel 64bit. but i wonder why i get this error, my bb file already contains:23:17
derRichardINSANE_SKIP_${PN} += "arch"23:17
robbawebbazino__: yes! inherit module is exactly what I've been referring to23:19
*** martinkelly <martinkelly!~martin@hq.xevo.com> has quit IRC23:19
robbawebbazino__: check out the documentation here: https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules23:21
robbawebbaand here's an example recipe: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb23:22
*** khem <khem!~khem@unaffiliated/khem> has quit IRC23:22
robbawebbazino__: pay special attention to to the extra RPROVIDES_${PN} that declares this recipe also provides kernel-module-*23:23
derRichardhmm, ok. INSANE_SKIP = "arch" did the trick23:24
derRichardmaybe because the kernel recipe does deep black magic ;)23:24
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto23:27
*** dl9pf2 <dl9pf2!~dl9pf2@> has quit IRC23:39
*** xperia64 <xperia64!~pi@pool-71-179-254-134.bltmmd.fios.verizon.net> has joined #yocto23:39
*** dl9pf2 <dl9pf2!~dl9pf2@> has joined #yocto23:40
RParmpit: yes, a-full23:44
armpitfor the Candian's its Full- eh23:45
*** xperia64 <xperia64!~pi@pool-71-179-254-134.bltmmd.fios.verizon.net> has quit IRC23:48
*** dl9pf2 <dl9pf2!~dl9pf2@> has quit IRC23:52
*** dl9pf2 <dl9pf2!~dl9pf2@> has joined #yocto23:53

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!