Monday, 2019-09-23

*** learningc <learningc!~learningc@> has joined #yocto00:45
*** learningc <learningc!~learningc@> has quit IRC01:07
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto01:20
*** learningc <learningc!> has joined #yocto01:21
*** learningc <learningc!> has quit IRC01:27
*** learningc <learningc!> has joined #yocto01:28
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC01:34
*** sgw1 <sgw1!~sgw@> has quit IRC01:35
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:40
*** yizhao <yizhao!~zhaoyi@> has quit IRC01:44
*** kaspter <kaspter!~Instantbi@> has quit IRC01:57
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:05
*** dv_ <dv_!~dv@> has quit IRC02:26
*** dv_ <dv_!~dv@> has joined #yocto02:39
yoctiNew news from stackoverflow: How do you build individual app inside Yocto Project Image? <>02:52
*** dreyna <dreyna!> has joined #yocto03:08
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto03:12
*** dreyna <dreyna!> has quit IRC03:12
*** bjobjo <bjobjo!~bjobjo@2a01:79d:3e81:5208::9e6> has quit IRC04:03
*** wooosaiiii <wooosaiiii!> has quit IRC04:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC04:18
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto04:18
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC04:19
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto04:20
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto04:21
*** Crofton <Crofton!~Crofton@> has quit IRC04:35
*** iceaway <iceaway!~pelle@> has joined #yocto04:40
*** iceaway_ <iceaway_!~pelle@> has joined #yocto04:44
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto04:48
*** agust <agust!~agust@> has joined #yocto05:26
*** kroon <kroon!~kroon@> has joined #yocto05:29
*** marka <marka!~marka@> has quit IRC05:32
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto05:34
*** AndersD <AndersD!> has joined #yocto05:38
*** marka <marka!~marka@> has joined #yocto05:51
*** saraf <saraf!~a_saraf@> has joined #yocto06:04
*** alessioigor <alessioigor!~alessioig@> has quit IRC06:10
*** marka <marka!~marka@> has quit IRC06:12
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:14
*** wooosaiiii <wooosaiiii!> has joined #yocto06:18
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto06:27
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:32
*** saraf <saraf!~a_saraf@> has quit IRC06:35
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC06:36
*** bjobjo <bjobjo!~bjobjo@2a01:79d:3e81:5208::9e6> has joined #yocto07:07
*** lfa <lfa!~lfa@> has joined #yocto07:11
*** tprrt <tprrt!~tprrt@> has joined #yocto07:12
*** mckoan|away is now known as mckoan07:16
mckoangood morning07:16
alessioigormckoan: Good morning to you07:18
*** yacar_ <yacar_!~yacar@> has joined #yocto07:21
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:27
iceawaygood morning07:27
*** jofr <jofr!~jofr@> has joined #yocto07:32
*** Bunio_FH <Bunio_FH!> has joined #yocto07:50
*** yacar_ <yacar_!~yacar@> has quit IRC07:52
*** yacar_ <yacar_!~yacar@> has joined #yocto07:58
*** TobSnyder <TobSnyder!> has joined #yocto08:18
*** lucaceresoli <lucaceresoli!> has joined #yocto08:32
*** Bunio_FH1 <Bunio_FH1!> has joined #yocto08:37
*** Bunio_FH <Bunio_FH!> has quit IRC08:39
*** yizhao <yizhao!~zhaoyi@> has joined #yocto08:45
*** jofr <jofr!~jofr@> has quit IRC09:04
*** jofr <jofr!~jofr@> has joined #yocto09:04
*** jofr <jofr!~jofr@> has quit IRC09:06
*** jofr <jofr!~jofr@> has joined #yocto09:06
*** jofr <jofr!~jofr@> has quit IRC09:08
*** jofr <jofr!~jofr@> has joined #yocto09:08
*** jofr <jofr!~jofr@> has joined #yocto09:09
*** yacar_ <yacar_!~yacar@> has quit IRC09:24
*** rburton <rburton!> has joined #yocto09:32
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:39
*** yann <yann!> has quit IRC09:41
*** JaMa <JaMa!> has joined #yocto09:44
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:51
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:55
*** goliath <goliath!> has joined #yocto10:03
*** litb <litb!> has joined #yocto10:06
litbhello all10:06
litbwhy when I say "bitbake -c <task>" does it build all task that depend on it? rather than only building the task itself and only building the others when needed?10:07
litbi.e when saying "bitbake gdb -C unpack" it also appears to compile it10:07
kroonlitb, sure your not confusing -c with -C here ?10:09
litbkroon, I thought -C just means "ignore the cache and force execution"10:09
kroon+ "run the default task for the target"10:10
litbkroon, ahh I looked it up again and see now that -C does something different indeed!10:10
litbthanks. I'm such a lazy dude not to look it up before asking. shame on me10:10
litbI think "-c <task> -f" is what I had in mind10:11
kroonwell, i think dependant tasks are also run10:13
kroongotta fetch sources before one can unpack them10:15
litbkroon, sure. Fair enough.10:23
yoctiNew news from stackoverflow: How to install Yocto on Beaglebone blackĀ“s Emmc using U-Boot <>10:23
*** learningc <learningc!> has quit IRC10:42
*** nayfe <nayfe!uid259604@gateway/web/> has joined #yocto10:51
*** yacar_ <yacar_!~yacar@> has joined #yocto11:05
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto11:05
*** learningc <learningc!~learningc@> has joined #yocto11:25
*** kroon <kroon!~kroon@> has quit IRC11:32
*** Bunio_FH1 <Bunio_FH1!> has quit IRC11:38
*** Bunio_FH <Bunio_FH!> has joined #yocto11:39
*** berton <berton!~berton@> has joined #yocto11:46
*** berton <berton!~berton@> has quit IRC11:51
*** berton <berton!~berton@> has joined #yocto11:52
*** yacar_ <yacar_!~yacar@> has quit IRC11:59
*** Klox <Klox!> has joined #yocto12:07
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto12:14
*** yacar_ <yacar_!~yacar@> has joined #yocto12:15
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:22
litbwhat's the recommended way to provide a config file for a specific package? I wanna provide a config file for systemd-networkd. should I make a completely separate package that consists only of this config file?12:24
litbor should I use a .bbappend on the systemd recipe and add the config file there? Maybe on the systemd-conf recipe?12:24
rburtoneither works12:26
rburtonsystemd-conf seems appropriate12:26
litbcurrently in my OS/dist-layer I have a "recipes-core/conffiles/*.bb" folder for various config files. i.e. a "". and now a "" for networkd12:26
rburtonthat ensures it gets pulled in12:26
litbmaybe calling it to keep the pattern12:27
litbrburton, hm, I see. i thought that maybe I would mess with yocto internals this way. i mean, nothing guarantees that systemd-conf stays. so if yocto decided to remove this package or rename it, I would be screwed12:27
rburtonit would only disappear on an upgrade to oe-core, and its trivial enough to solve12:29
rburtonyou'll get a build error with a dangling bbappend so you'll know12:29
litbah, i see12:30
*** berton <berton!~berton@> has quit IRC12:35
*** Crofton <Crofton!~Crofton@> has joined #yocto12:40
*** marka <marka!> has joined #yocto12:41
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto12:46
litbrburton, perhaps automatically populating the value of "SRC_URI" with all files in  files/   would be a compact solution and deserve a class of its own. each file name has the format "folder1-folder2-...-filename" and will be installed to  "${D}/folder1/folder2/.../filename". a dash can be escaped by double-dashing13:06
*** AndersD <AndersD!> has quit IRC13:09
rburtonlitb: you can use limited globs in SRC_URI, see matchbox-desktop for an example13:10
rburtonor a directory name, see xserver-nodm-common13:10
qschulzrburton: from my understanding file://dir/* is exactly the same as file://. isn't it?
qschulzanything with * in the path will be replaced by .13:15
*** TobSnyder <TobSnyder!> has quit IRC13:18
rburtonthat search logic is suboptimal to say the least13:20
rburtonbut its unpack that does the copy13:21
rburton        # Localpath can't deal with 'dir/*' entries, so it converts them to '.',13:21
rburton        # but it must be corrected back for local files copying13:21
*** kroon <kroon!> has joined #yocto13:22
rburtonNOTE: Unpacking /home/ross/Yocto/poky/meta/recipes-sato/matchbox-desktop/files/vfolders/* to /data/poky-tmp/master/work/corei7-64-poky-linux/matchbox-desktop/2.2-r0/13:22
*** Crofton <Crofton!~Crofton@> has quit IRC13:22
*** ECDHE_RSA_AES256 is now known as ecdhe13:22
JPEWdl9pf: BB_HASHSERVE = "host:port"13:34
JPEWdl9pf: The server listens on port 8686 unless you tell it otherwise, so "host:8686"13:34
RPJPEW: good news is we're down to two failures with master-next. I have a fix for the selftest one, the esdk one is eluding me, can't even reproduce :(13:36
JPEWRP: Is that with the "only run setscene once" patch?13:39
RPJPEW: yes13:41
qschulzrburton: I see... I've to check this out in more depth. By any chance, do you know/understand the difference between -H and -P in cp? Because it looks to me they are contradictory and they're used together in
rburtonerm no13:42
Piratyadelcast: ^ may be interesting13:43
RPqschulz: looks like a bug :(13:45
*** yacar_ <yacar_!~yacar@> has quit IRC13:47
JPEWRP: I'd love to talk over that solution. Not that it's necessarily wrong, I just want to understand why that solution is correct. Maybe in the engineering call tomorrow?13:50
*** Crofton <Crofton!~Crofton@> has joined #yocto13:52
litbrburton, thanks!13:54
*** yacar_ <yacar_!~yacar@> has joined #yocto13:56
*** Crofton <Crofton!~Crofton@> has quit IRC14:00
*** AndersD <AndersD!> has joined #yocto14:01
*** AndersD_ <AndersD_!> has joined #yocto14:02
*** AndersD <AndersD!> has quit IRC14:06
*** yacar_ <yacar_!~yacar@> has quit IRC14:08
RPJPEW: I'm not 100% convinced its right14:15
RPJPEW: it is however fairly unavoidable :(14:16
qschulzRP: yup, they should have removed the P in the commit, it works because it's parsed from left to right and then H overrides P14:17
qschulzRP: well at least from, which I guess is the "correct" one?14:18
RPqschulz: I think so14:18
*** yacar_ <yacar_!~yacar@> has joined #yocto14:19
*** tgamblin <tgamblin!~tgamblin@> has quit IRC14:21
*** fray <fray!> has joined #yocto14:23
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto14:27
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:35
*** berton <berton!~berton@> has joined #yocto14:42
*** berton <berton!~berton@> has quit IRC14:44
*** berton <berton!~berton@> has joined #yocto14:45
*** PinkSnake <PinkSnake!51ff1123@> has joined #yocto14:49
PinkSnakeHello Guys, someone here could give a feedback about application management inside Yocto ? We have several project with different applications, I made a partition to split OS/app binary and update designated application with opkg. And as always I'm looking for the better way to do that :)14:53
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC14:55
alessioigorPinkSnake: We generate with Yocto an immutable OS (so no rpm, dpkg or opkg) and we use a directory (optionally mounted on NFS) to provides binaries handled with specific application.15:05
*** yacar_ <yacar_!~yacar@> has quit IRC15:07
PinkSnakealessioigor Thx for replying! Seems also a good solution :)15:07
alessioigorPinkSnake: I hope so :)15:07
*** yacar_ <yacar_!~yacar@> has joined #yocto15:11
*** kroon <kroon!> has quit IRC15:20
qschulzI want to debug a BAD_RECOMMENDATIONS which isn't taken into account, do you have any tips?15:21
rburtonqschulz: easiest way is to go onto the target and remove the package15:22
rburtonthe package manager will tell you what is causing it to be installed15:22
rburtonif it removes, then your image explicitly pulls it in15:23
*** yacar_ <yacar_!~yacar@> has quit IRC15:25
qschulzit's eudev-hwdb, there is only one package RRECOMMENDS-ing it, usbutils. In our image recipe we have BAD_RECOMMENDATIONS += " eudev-hwdb ".15:26
*** tprrt <tprrt!~tprrt@> has quit IRC15:27
qschulz(and BAD_RECOMMENDATIONS has it in bitbake -e)15:27
fraybad recommendation simply is a hint, there is a way to avoid it ever being installed.. and if it's a hard dep, it'll error15:27
qschulzI know, there is no rdepends anywhere in our layers nor in poky AFAICT, so it shouldn't behave like this.15:28
qschulzor... it gets pulled by the auto-rdepends mechanism15:28
frayiuf your image can't be generated it'll error..15:28
qschulzAHAH. I forgot about that one. Let's see :D15:28
frayBAD_RECOMMENDATION is only a hint, it says don't install it if recommended.. but if something else says it NEEDS it, then it'll go in15:29
frayexclude won't even allow that15:29
*** kroon <kroon!> has joined #yocto15:30
qschulzfray: yup, I know. let's see what it says with PACKAGE_EXCLUDE, thanks for the hint15:33
rburtonforgot about package_exclude15:34
frayI know it was added precisely to deal with the case where packages came in and just wouldn't stay out15:35
*** Bunio_FH <Bunio_FH!> has quit IRC15:38
zeddiiRP: I've got a bunch of -stable 5.2 bumps that I've done locally here while working through strace. I didn't see a M3 announcement, so I'm not sure if it is still being built .. but I was wondering if you'd rather I sit on those patches until M3 is out, or should I just fire them out anyway ?15:42
* zeddii hates getting patches when other things are blowing up .. hence why I ask.15:43
adelcast^Piraty, thanks, seems like libcurl has had this for a while, but its not being used by opkg.....this actually should be easy to implement15:44
RPzeddii: M3 is built and in QA15:55
zeddiiok. so I'll send them out, and go back to printk'ing the kernel after that.16:01
frayall can be debugged w/ printk.. ;)16:02
*** learningc <learningc!~learningc@> has quit IRC16:04
*** learningc <learningc!~learningc@> has joined #yocto16:05
*** Bunio_FH <Bunio_FH!> has joined #yocto16:13
rburtonkergoth: rewrote the bulk of bb-whatdepends with three lines of tinfoil. for recipe in tinfoil.all_recipes(): if args.recipe in recipe.depends: print(recipe)16:14
kergothha, nice16:14
kergothdoes that cover runtime or just build time?16:14
rburtonjust build time16:15
rburton(which is all i wanted)16:15
rburtonrdepends should be done via pkgdata16:15
*** mckoan is now known as mckoan|away16:24
kergothdebatable. there's value in being able to operate based on the defined metadata vs the actual results including shlibs after a build, especially if you're investigating why something is being *built*, which was the main purpose of the script16:29
kergothboth have a certain a mount of value, i think16:30
rburtonkergoth: hm, i guess something being built would mean chasing the actual depends tree,  not the DEPENDS variable16:31
rburtonyeah fair enough16:31
kergoththere's also the question of whether task depends are included. my ideal was to track down why something was sucked in and ideally why. *this* flag on *that* task is why this is being built. but never quite got there, there are a lot of forms of dependency :)16:32
*** kroon <kroon!> has quit IRC16:32
kergoth-g sucks when recrdeptask is involved, for example16:32
kergoth"oh good, *everything* depends on this, that helps.."16:33
rburtoni'll keep bb-depends around for the common case16:34
rburtonbut will try rewrite whatdepends to follow the actual task depends at some point16:34
kergothyeah, makes sense, i'm sure it'll be of use16:34
rburtonoften stare at -g output wondering why something like attr is depending on py3-native for example16:34
kergothi most often have the gumption to make such a script work again when i'm in the midst of such a diagnosis, but then i'm usually under time pressure and just want to move on, so it never gets done16:35
RPkergoth: the main problem is there is no record in the system of where a dependency came from16:48
RPAn option to filter the logging by a specific dependency name may be interesting16:49
RPThe standard logging does normally tell you but its near impossible to read. With filtering...16:49
*** cdgarren <cdgarren!cf431e3c@> has joined #yocto16:53
cdgarrenIs it possible to modify the SRC_URI variable in a task before do_fetch? When I print d.getVar("SRC_URI") at the end of my new task, it has the files I expect, but then the fetcher debug output doesn't indicate it's looking for all the files.17:00
*** tprrt <tprrt!> has joined #yocto17:04
*** velo <velo!> has joined #yocto17:11
veloHello. Would this be the right place to ask for advice on yocto cross-compilation?17:13
kergothcdgarren: tasks get isolated copies of the metadata. tasks can't modify the data of other tasks or it'd make the build non-deterministic due to task ordering.17:16
kergothcdgarren: use anonymous python to do something at parse time if needed, or use a prefunc17:17
cdgarrenAh, got it. Thanks17:17
kergothi.e. do_foo[prefuncs] += "my_other_function"17:17
kergothor use _prepend/_append, depending on your requirements17:17
cdgarrenSo I could append to SRC_URI in a prefunc, and the fetcher would get those files?17:18
kergothyes. it'd be better to do it at parse time, though, then bitbake -e would show the changes17:21
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC17:21
cdgarrenkergoth: Got it. That works perfectly, thanks17:25
*** berton <berton!~berton@> has quit IRC17:28
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:29
*** berton <berton!~berton@> has joined #yocto17:30
*** khem <khem!~khem@unaffiliated/khem> has quit IRC17:33
*** comptroller <comptroller!> has quit IRC17:34
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto17:38
qschulzfray: turns out PACKAGE_EXCLUDE didn't make yocto complain17:43
fraymaybe there is a bug in the BAD_RECOMMENDATIONS then..17:43
qschulzWe removed libsolv from PACKAGECONFIG for the target opkg in thud17:44
mischiefare there builtin wrappers i can call in a recipe for unpacking a tarball, or should i just invoke tar directly?17:44
qschulzso I put it back17:44
frayI'd suggest explaining what you did and how to reproduce it to the oe-core mailing list..17:44
qschulzand then I remembered I asked for backporting a few patches from opkg 4.0 to 3.6 because it fixed an issue for me with BAD_RECOMMENDATIONS17:44
tgamblinRP: accidentally changed a couple of bug milestones in Bugzilla. I've reverted the changes but you may see some notification emails17:44
qschulzbut apparently, (WHICH IS VERY OBVIOUS FROM THE COMMIT LOG GMRBNLRBGLKRBGJBRG), someone needs libsolv > 7.2 to make use of it17:45
qschulzso I don't know what the fuck I did to make it work nicely back when I asked to backport the patches for opkg but it definitely isn't enough now (works fine with libsolv in PACKAGECONFIG and backported libsolv_7.3)17:45
qschulzthe question is if it's supposed to work without libsolv support17:46
qschulz(BAD_RECOMMENDATIONS I mean)17:46
*** learningc <learningc!~learningc@> has quit IRC17:49
*** comptroller <comptroller!> has joined #yocto17:50
*** cdgarren <cdgarren!cf431e3c@> has quit IRC17:54
yoctiNew news from stackoverflow: Toolchain build using yocto <>17:54
*** WillMiles <WillMiles!> has joined #yocto18:02
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto18:14
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:21
*** WillMiles <WillMiles!> has quit IRC18:27
*** WillMiles <WillMiles!> has joined #yocto18:28
*** tprrt <tprrt!> has quit IRC18:32
*** yann <yann!> has joined #yocto18:44
*** velo <velo!> has quit IRC18:46
RPtgamblin: np, thanks for the headsup18:52
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC19:00
*** litb <litb!> has quit IRC19:03
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC19:07
*** tprrt <tprrt!> has joined #yocto19:11
*** lfa_ <lfa_!> has joined #yocto19:19
*** lfa <lfa!~lfa@> has quit IRC19:22
*** lfa <lfa!~lfa@> has joined #yocto19:22
*** lfa_ <lfa_!> has quit IRC19:23
*** vlo86 <vlo86!> has joined #yocto19:41
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC19:43
vlo86I'm building a custom library (own recipe) on top of poky thud for Raspberry Pi Zero. I'm getting a QA error for my library stating "Architecture did not match (x86-64, expected ARM)". I checked the produced .so file, and it's x86 instead of ARM. The library is using make, and I noticed that if I change the lib install location from /usr/lib to19:46
vlo86e.g. /usr/local/lib then the QA error disappears. My question is still, that why is the library built for x86 instead of ARM?19:46
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:46
LetoThe2ndvlo86: chances are that the Makefile just doesn't properly handle the passed CC, CFLAGS, arch and all that19:49
LetoThe2ndvlo86: pretty much one of the poster examples why hand-written Makefiles are a massive PITA when it comes to cross compiling.19:50
*** kroon <kroon!> has joined #yocto19:54
rburtonvlo86: what LetoThe2nd said.  that qa warning is explicitly to catch build systems that hardcode 'gcc' and don't use the cross compiler.19:55
vlo86Thanks for the pointer. I will check this lead. This is a third party library and I'm just trying to include it into my image =)19:55
rburtonfile a bug with the library at least, if its bare makefiles you can normally override the right variables19:55
rburtonis it open source?19:55
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?19:56
LetoThe2ndrburton: "if the Makefile is at least halfways properly written"19:56
vlo86rburton: yeah, it's open source:
rburtonCC           = $(CROSS_PREFIX)gcc19:57
rburtonif it used ?=...19:58
LetoThe2ndrburton: thats what i meant19:58
LetoThe2ndLetoThe2nd vs. Makefiles: 1:019:58
rburtonwhen you call make, also add CC="${CC}" AR="${AR}" etc etc19:58
rburtoni also noice no way to override LDFLAGS19:59
LetoThe2ndfork it and port to cmake, meson, autotools, $WHATEVER_SANE :P19:59
rburtonthat's definitely the better option :)19:59
vlo86So what you're saying is I should patch CROSS_PREFIX definition?19:59
rburton <-- hey use that instead19:59
vlo86Heh, I was already considering that for a moment. But good to know now that this Makefile is in fact the problem.19:59
rburtonLIBRARY DESTINATION ${DESTDIR}/usr/local/lib   <-- argh that hardcodes locations though19:59
LetoThe2ndLetoThe2nd vs. people who write handwritten Makefiles: 2:020:00
LetoThe2ndi take this as an omen i should call it a day.20:01
vlo86Heh. Thanks a lot for your help!20:02
rburton is a bug about getting cross support actually working,20:06
rburtonnote how its not closed20:06
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:07
vlo86Well would you look at that =)20:10
vlo86That was a mere statement of no surprise, not a real question :D20:10
*** PinkSnake <PinkSnake!51ff1123@> has quit IRC20:13
*** rburton <rburton!> has quit IRC20:19
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto20:22
mischiefis there a way to see the working directory during recipe task execution?20:24
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC20:27
RPmischief: bitbake X -e | grep WORKDIR= ?20:43
*** diamondman <diamondman!sid306859@gateway/web/> has joined #yocto20:46
*** tprrt <tprrt!> has quit IRC20:49
*** tprrt <tprrt!> has joined #yocto20:50
*** kroon <kroon!> has quit IRC20:53
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto20:54
*** vlo86 <vlo86!> has quit IRC21:00
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto21:08
*** berton <berton!~berton@> has quit IRC21:15
*** WillMiles <WillMiles!> has quit IRC21:25
*** JaMa <JaMa!> has quit IRC21:28
RPJPEW: Still can't reproduce the esdk failure :(21:33
*** grumble <grumble!~grumble@freenode/staff/grumble> has quit IRC21:48
*** grumble <grumble!~grumble@freenode/staff/grumble> has joined #yocto21:50
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC21:55
*** goliath <goliath!> has quit IRC22:06
*** rburton <rburton!> has joined #yocto22:06
*** rburton <rburton!> has quit IRC22:15
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC22:23
*** agust <agust!~agust@> has quit IRC22:32
mischiefRP: thanks. any clue about the kernel module question?22:53
*** Crofton <Crofton!~Crofton@2601:5c0:c100:b84:3d3f:64d6:2ba1:780b> has joined #yocto23:01
*** anujm <anujm!anujm@nat/intel/x-ohxuqwacpsmvqvsg> has joined #yocto23:03
khemmischief: can you paste your kernel module recipe ?23:07
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:07
khemare you inheriting module ?23:07
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC23:22
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto23:53

Generated by 2.11.0 by Marius Gedminas - find it at!