**** BEGIN LOGGING AT Mon Feb 12 03:00:01 2018 Feb 12 07:01:22 join Feb 12 07:09:17 I am getting error while trying to install dev-0.4.0 using command $python setup.py install. error:https://pastebin.com/raw/yGt4inm7 Feb 12 09:19:08 i am on a rocko based yocto setup (GCC7) with an i.mx6 based device. there are some indications that GCC for ARM gained at some point (4.9ish) ASAN support Feb 12 09:19:19 i fail to make it work with my yocto generated toolchain Feb 12 09:19:33 i always end up with linker errors Feb 12 09:20:06 the ASAN website @google itself indicates that Linux/ARM is not a supported target Feb 12 09:20:18 should this work or not? Feb 12 09:24:43 freanux: I am using a YP generated 2.4-cortexa9hf toolchain for iMX6, building perfectly a Linux imx6qdlsabresd 4.9.67 Feb 12 09:24:59 ops Feb 12 09:25:19 fmeerkoetter: msg above was for you ^ Feb 12 09:26:25 mckoan: i don't think the toolchain was in question, but explicitly having ASAN enabled. Feb 12 09:26:48 mckoan: so you have a toolchain where you can run something like "arm-something-gcc -fsanitize=address -lasan main.c Feb 12 09:27:33 i also don't want to build a kernel Feb 12 09:27:50 only interested in application software running in userspace Feb 12 09:28:09 * mckoan yawns Feb 12 09:28:38 well, even that doesn't seem to work :-P Feb 12 09:43:13 Ciao Feb 12 09:47:56 Hello Feb 12 09:48:03 Toc toc Feb 12 09:48:43 Bear_: don't ask to ask, just ask :) Feb 12 09:50:00 Ops.. Hello only for courtesy. How I can add truetype font to proyect ? Feb 12 09:52:02 Bear_: in terms of what? probably something like http://layers.openembedded.org/layerindex/recipe/988 Feb 12 09:54:20 Ops.. Page not found Feb 12 09:55:01 strange. Feb 12 09:55:33 i guess it needs the trailing slash http://layers.openembedded.org/layerindex/recipe/988/ Feb 12 09:57:33 Yes is correct, analyze thank Feb 12 10:24:42 how to add pythondev in yoto image for i.mx6ul evk with core-image-base Feb 12 11:01:25 Hi. I have a Yocto build with a linux layer of the module vendor (Variscite). I now require changes in both the Kernel Device tree and some Linux sourcefiles. Is it best to fork the Linux fork of the module vendor or should I create a BBappend file with my custom device tree and required patches? Feb 12 11:04:00 seppe: depends a bit on how you want to maintain the kernel, if you want to stick with the vendor provided stuff Feb 12 11:04:29 seppe: our approach here is that we have local repos including our patches and modifications. Feb 12 11:04:54 and how big are modifications :) Feb 12 11:05:16 yeah. it depends(TM) Feb 12 11:15:37 Hi all. I have a quick question about documentation (I guess). Feb 12 11:16:18 I currently have a distro built from yocto and poky based on krogoth. I'd like to move forward to rocko. Is there any documentation as to what has changed or how best to go about that? Feb 12 11:16:54 The modifications are fairly minimal, hence my hesitance to fork the kernel. Feb 12 11:17:01 When I went from Dizzy to Fido years ago it was a long and painful process, I was kinda hoping hopping forwards is easier nowadays? Feb 12 11:17:34 Though I pretty much have a completly seperate Device tree by now Feb 12 11:18:44 So I was thinking to just add my own layer with my own device tree + some small paches, but I'm not sure if this is going to be easy to maintain if the vendor makes changes to the kernel. Feb 12 11:20:15 joe_r: all releases have change notes, those can be reviewed. Feb 12 11:20:23 joe_r: you need to look at the documentation before asking. whay you look for is right there in reference manual. Feb 12 11:20:45 joe_r: generally, to pyro/rocko will punish dirty recipes ;-) Feb 12 11:21:01 That's not quite what I meant. There's a LOT of documentation. So I was wondering if there was a subset that was a porting guide from one stable release to another. Feb 12 11:21:33 joe_r: section 6, is called "migrating to a newer yocto project release" Feb 12 11:21:48 kanavin: veni, vidi, vici :-P Feb 12 11:21:54 with subsections dedicated to specific releases Feb 12 11:21:58 in short, RTFM Feb 12 11:22:30 Excellent. Thank you. Feb 12 11:23:37 Section 24 in the mega-manual? Or are we talking a different manual? Feb 12 11:24:06 joe_r: reference manual, which is available separately, or as a part of the mega-manual Feb 12 11:24:20 OK, thanks. Much appreciated. Feb 12 11:26:46 kanavin: https://www.xkcd.com/293/ Feb 12 11:31:33 LetoThe2nd: I just sneaked an xkcd reference into a commit message http://lists.openembedded.org/pipermail/openembedded-core/2018-February/147388.html Feb 12 11:32:06 kanavin: hehe. a true classic. Feb 12 11:32:23 LetoThe2nd: I enjoy commits that remove code the most Feb 12 11:32:35 the more code I manage to remove from oe-core, the happier I am Feb 12 11:32:38 same here. Feb 12 11:32:51 well not exactly oe-core in my case, but i know what you mean Feb 12 11:40:10 I'm having quite a lot of issues with oe-core. Is there an alternative that's more "pick what you need" iof "include anything but the kitchensink" aproach? Feb 12 11:40:54 seppe: huh? Feb 12 11:41:17 seppe: ah wait, weren't you the guy with that awful vendor distro config? Feb 12 11:41:25 LetoThe2nd: Yup Feb 12 11:41:31 seppe: also known as variscite layer pulls in everything? Feb 12 11:41:36 Still haven't bugged them about that XD Feb 12 11:42:10 seppe: well then go bitching at variscite, because oe-core actually is starting minimal. if you don't believe it, give the quick start a try and see for yourself :) Feb 12 11:46:03 LetoThe2nd: Anyhow, oe-care has recipes for pretty much everything (except the kicthen sink ^^). Parsing these recipes on a workstation with slow storage takes a while. Feb 12 11:46:33 seppe: thats why it caches as much as possible. on my run of the mill box takes roughly 5secondes. Feb 12 11:46:55 also, some of the Python recipes seem to be missing dependencies when usin rocko Feb 12 11:47:49 LetoThe2nd: How is the recipe cache retained? Does it live as long as the server? Feb 12 11:48:04 there has been a lot of churn in python, yes. Feb 12 11:48:38 what server? i mean, there is a cache directory in the build directory. thats it. if the layers havent changed, it is just reuse.d Feb 12 11:48:59 LetoThe2nd: The bitbake server Feb 12 11:49:22 unless there has been a major modification that i'm not aware of, it should be persistent. Feb 12 11:49:35 LetoThe2nd: I change my layers all the time, since I'm developing... Feb 12 11:49:36 (it is for me, yet i have not tested that on newer things than morty) **** BEGIN LOGGING AT Mon Feb 12 12:28:34 2018 Feb 12 12:29:49 how to enforce a parsing operation in .bb file before some other parsing operation in .conf file ? Feb 12 12:34:07 i might be mistaken, but shouldn't .conf files always be evaluated before .bbs? Feb 12 12:37:33 LetoThe2nd: so if we want to a global change (.conf) after a layer operation (.bb) ? Feb 12 12:38:42 I mean .conf configuration is applicable on build, while the recipe configuration apply on that layer environment Feb 12 12:38:48 xtron: like i said, i might be mistaken - but my impression is that you want to reconsider your model. Feb 12 12:39:00 LetoThe2nd: hmm Feb 12 13:04:32 I'm still going back and forward between overwriting my SoM vendor's DTSI completely, patching it or forking the entire Linux repo. Feb 12 13:06:00 I feel like overwriting it completly is the simples option when making changes, but I loose the historic information and make it impossible to get updates. Feb 12 13:06:27 or at least make it harder to get upstream changes fot the device tree Feb 12 13:11:19 in fact, it will be like this: you pick one way now, and in a couple of weeks/months you will always find out that another one might be better for your specific situation. **** BEGIN LOGGING AT Mon Feb 12 14:06:10 2018 Feb 12 14:18:06 Is anyone here familiar with recent status of EGL + Weston on Texas Instrument platforms (AM57xx)? Feb 12 14:18:14 kergoth: thanks Feb 12 14:18:33 On their Rocko branch (on meta-ti / meta-arago), I can't seem to use Weston at all.. Feb 12 14:23:55 New news from stackoverflow: Pyusb: No Backend available (linux machine) Feb 12 15:07:51 After my recent dealings with waf.bbclass and waf-samba.bbclass, I'm thinking about making a oe.utils.get_parallel_make(d) that pulls the integer argument from "-j" out of PARALLEL_MAKE, since that code is now replicated at least 4 places by my count. Any thoughts? Feb 12 15:08:35 (go.bbclass, waf.bbclass, boost.inc, and waf-samba.bbclass for reference) Feb 12 15:13:13 JPEWhacker: sounds good to me! Feb 12 15:43:11 hi all. I would like to automatize my yocto builds. I was looking at Jenkins but maybe there's others software more appropriated ? Feb 12 15:44:01 binarym: depends(TM) - you can also beat the autobuilder into shape for your use case, or utilize toaster in some form. Feb 12 15:45:19 since i have a blank page in front of me, the only limit is my imagination Feb 12 15:45:20 but Feb 12 15:45:32 i'll probably have to build several images for several machine Feb 12 15:45:40 so something that would be quite easy to extend Feb 12 15:46:10 the most essential point is that the setup of your layer abd build configuration happens automatically. then the rest is just a task runner in the end. Feb 12 15:46:30 i think the BMW guys use something called "kis" for that Feb 12 15:47:18 no idea what tricks the autobuilder uses Feb 12 15:47:56 ok, thanks LetoThe2nd , i'll read a bit of doc about toaster and autobuilder :) Feb 12 15:51:36 binarym: FWIW, we use Jenkins.... but keep the config as simple as possible. Ours works..... sometimes. I think it would be much better if it wasn't a huge mess with layer upon layer of configuration tools that no one really understands. Feb 12 15:52:19 RP: reading the conversation just above, should we eventually mold the autobuilder tooling into the Official Yocto Configuration Management thing? Feb 12 15:52:27 people are asking about it all the time... Feb 12 15:54:13 New news from stackoverflow: How can I generate a Parsing Error in BitBake on intent? Feb 12 15:56:49 JPEWhacker: ok, thx for the feedback :) Feb 12 15:57:43 kanavin: "mold" and "autobuilder" in one sentence :) Feb 12 15:58:20 kanavin: actually i feel that the real pain point is the build/layer setup. if that is sorted out, anything else is just task runners on dope. Feb 12 15:59:39 LetoThe2nd: I believe the autobuilder has tooling for precisely that, but it's not my specialty, so I don't know how far it is from becoming Official Feb 12 16:00:15 If I needed to apply a patch to my local copy of "linux-yocto/4.1.43+gitAUTOINC+4e12cb8f8e_b5db159a9c-r0.2/kernel-meta" to add the overlayfs feature, how would I go about it? Feb 12 16:01:04 LetoThe2nd: haha mold vs. mould :) Feb 12 16:01:18 I'm not a native speaker :) Feb 12 16:01:38 kanavin: neither am i :) Feb 12 16:01:53 kanavin: ah interesting, then its time for me to look at it again. Feb 12 16:01:54 Adam___: I'm on morty, but I'm pretty sure I have weston working on TI hardware (we run our own compositor, but I occasionally use weston for testing). Feb 12 16:02:15 spierepf: you'd apply the patch just as with any other recipe, if you do need patching, if you only need to add some CONFIG to the kernel configuration you should add a kernel config fragment on your SRC_URI Feb 12 16:02:58 JPEWhacker: Right, Morty is perfectly running fine as well. However, I really need to run newer version of Qt (5.9) as well as Wayland IVI shell which seem to be available on Rocko. Feb 12 16:03:18 JPEWhacker: Btw, how was the experience of writing your own compositor? Feb 12 16:03:19 Adam___: Ah sorry. Can't help you there. Feb 12 16:03:28 JPEWhacker: np thanks for input Feb 12 16:06:07 Adam___: Not too bad. Wayland is a pretty simple protocol. Our implementation which does all the core wayland protocol + wl_shell + xdg_shell + text_input was only ~10,000 lines. Feb 12 16:06:51 aehs29: which recipe controls kernel-meta? Feb 12 16:08:30 JPEWhacker: Great to hear that. Have you evaluated IVI shell? I am considering writing my own compositor vs running IVI. Feb 12 16:08:36 Adam___: Although, our coding style is pretty vertically verbose, so I usually divide it in about half for accurate comparison. If you used something like the Kernel coding style, I suspect you would clock in around ~6000 lines. Feb 12 16:08:58 Adam___: No we don't use IVI shell Feb 12 16:09:04 JPEWhacker: that is pretty compact Feb 12 16:09:10 JPEWhacker: May I ask why? Feb 12 16:09:24 aehs: the overlayfs feature appears in 4.10 kernel-meta, but not in 4.1 kernel-meta. But when I copied the features/overlayfs from 4.10 to 4.1 it appears to build fine. Feb 12 16:10:03 exit Feb 12 16:10:13 sorry Feb 12 16:12:35 Adam___: Why what? Feb 12 16:14:36 JPEWhacker: Why not use available compositors such as IVI Feb 12 16:17:22 Adam___: Oh, we swicthed to Linux from another RTOS, and already had a huge amout of code that did graphics bits with "special" behaviors. It was eaiser to implement a Wayland compositor in our existing codebase and integrate that behavior into what we already had than convert our existing code to work as a Wayland client. Feb 12 16:17:48 JPEWhacker: Makes perfect sense. Thanks! Feb 12 16:17:49 Adam___: Really, it is a good testament to the design of Wayland, IMHO. Feb 12 16:18:23 JPEWhacker: Ya I have known how simple / straight forward Wayland is for a while. Perhaps I should just jump in and get it done Feb 12 16:45:07 https://www.bleepingcomputer.com/news/linux/its-2018-and-you-can-still-p0wn-your-linux-box-by-plugging-in-a-usb-stick/ Feb 12 18:03:00 zeddii: Could we simply remove the drivers/ directory from kernel-devsrc ? Feb 12 18:03:23 zeddii: We need to try and free some space in our big images to get the new kernel in Feb 12 19:34:45 <|Sno|> moto-timo: I commit what I have updated into rehsack/meta-cpan Feb 12 19:34:58 <|Sno|> I move it after I'm done for first round Feb 12 19:35:22 <|Sno|> then I fork, do your wishlist and 2nd load pushed Feb 12 19:36:24 |Sno|: genial Feb 12 19:39:01 |Sno Feb 12 19:39:10 |Sno|: das is ausgezeichnet Feb 12 19:39:15 ist Feb 12 19:39:59 <|Sno|> soweit klappt meine Autovervollständigung ;) Feb 12 20:01:26 \o/ Feb 12 20:09:40 <|Sno|> moto-timo: btw - I thought a bit over the allarch issue of some people wrt. meta-cpan Feb 12 20:10:23 <|Sno|> On the one hand, I don't want remove the "inherit allarch" since it removes an important marker Feb 12 20:10:44 <|Sno|> On the other hand I don't want exclude anyone from using meta-cpan Feb 12 20:13:12 <|Sno|> Is there a way like inherit "${@["allarch", ""][(bb...)]}" ? Feb 12 20:14:11 |Sno|: let me think about that, as anything without XS would be "noarch" in Fedora and other distros Feb 12 20:14:34 only the compiled native code stuff should be arch specific Feb 12 20:14:39 <|Sno|> In such a case, we could add a "pureperl" class, which cares for allarch depending on a tunable and provides extra settings for Toolchain Consensus 2013 (PUREPERL_ONLY=1 for EU::MM ...) Feb 12 20:15:47 <|Sno|> moto-timo: it seems there is an issue in oe which causes people trouble who share one BSPDIR for a family of product (e.g. at Wind-River) Feb 12 20:16:53 <|Sno|> rpurdie opened a Bugzilla Task for it Feb 12 20:18:16 <|Sno|> moto-timo: I forwarded you the ticket mail Feb 12 20:19:03 <|Sno|> let me summarizy - I intend to introduce a pureperl.bbclass which inherits from allarch unless user turns that off by a global setting in local.conf or so Feb 12 20:20:42 ok Feb 12 20:21:33 * moto-timo wonders if we can have QA check for XS and ERROR if it finds it. Feb 12 20:21:49 but that is a different story Feb 12 20:22:41 it wouldn't be part of the pureperl.bbclass, but rather in the qa check tasks Feb 12 20:24:47 <|Sno|> IIRC it fails to bake a recipe when it has allarch and XS Feb 12 20:53:18 I must be missing what the concern about allarch was then. I will get clarity from others. Feb 12 20:53:44 JaMA had a comment on a recent patch submission I did, so I'll look back at that. Feb 12 20:54:01 It is possible "allarch" is actually broken somehow Feb 12 22:16:40 <|Sno|> moto-timo: yeah, please get some information - but I think when noone knows the root cause, adding an indirection and a knob is a good user-support for the meantime Feb 12 22:17:05 <|Sno|> moto-timo: first charge pushed, around 6x more yet uncommitted on my harddisk :( Feb 12 22:30:14 how do I add xt_addrtype as a module to my kernel? I've added the CONFIG_...=m to create the module, but the module isn't being added to my image. Feb 12 23:20:35 |Sno|, moto-timo: From what I remember you can inherit allarch but actually using it can be made conditional later Feb 12 23:21:05 Look at the class and note if d.getVar("PACKAGE_ARCH") == "all": Feb 13 01:29:16 Can anyone help me add a kernel module to my image? Feb 13 02:15:10 How do I add a standard kernel module like xt_addrtype to my yocto image? **** ENDING LOGGING AT Tue Feb 13 03:00:02 2018