**** BEGIN LOGGING AT Fri Jan 02 02:59:59 2015 Jan 02 03:49:05 anyone know why my cluster-minimal images don't include nice? Jan 02 07:59:17 Hi, anyone around? Jan 02 08:47:02 morning all Jan 02 13:36:26 good morning, happy new year Jan 02 13:37:41 lpapp: hi, happy new year to you also Jan 02 16:11:56 New to yocto after buying an embedded device. The package manager for Yocto is opkg? Did I read correctly that you can respin yocto to use rpm? Or do I have to rebuild the whole image for new packages? I'm not sure how packaging works. Jan 02 16:13:18 yocto supports rpm, opkg, and dpkg, though the last is less often used than the other two Jan 02 16:14:47 That's what I read. But I'm missing a piece of the puzzle - if I head over to my device the familiar rpm, yum, zypper, etc don't seem to be there. I'm not clear on if I need to rebuild it or use opkg to install rpm or... something? Jan 02 16:21:19 its not going to magically get every package manager installed on an existing image Jan 02 16:21:28 its a build time configuration option Jan 02 16:21:49 That's the piece I was looking for. So I need to add it to the image before loading it to the device. Thanks. Jan 02 16:22:41 its not a matter of installing the package manager Jan 02 16:22:55 its also a matter of actually producing packages for that package manager for every piece of software going into the image Jan 02 16:23:09 not just, i should say Jan 02 16:23:29 That's fine - I'm familiar with the rpm workflow and that's why I wanted to get that ... ecosystem? (or whatever you want to call it) working. Jan 02 16:24:20 poky defaults to rpm, angstrom doesn't, it depends on what yocto based distribution you're wanting to use, but any of them can be changed yourself wehn doing the build Jan 02 16:24:38 I'm working with whatever Intel gave me. :) Jan 02 16:42:36 supa_: which board are you using? Jan 02 16:43:04 Edison Jan 02 16:43:39 ah right, that would be opkg then by default Jan 02 16:44:11 no rebuilding should be necessary, it's already installed in the default image Jan 02 16:44:30 Sounds good. I'll just it out when I get back home. :) Jan 02 16:51:18 bluelightning: thanks :) Jan 02 16:51:43 what is the most common way of building from the same repository, but two different targets for two different user requirements? Jan 02 16:51:53 two recipes with an .inc or something else? Jan 02 16:53:51 bluelightning: any objection to letting RecipeTool provide the LICENSE to the core of recipetool? in the case of python, the license can be determined via setup.py, so that's better than a possible failed guess Jan 02 16:54:35 lpapp: within the same distro config, you would need to have two separate recipes yes Jan 02 16:55:13 kergoth: sorry, I don't quite get the question ... ? Jan 02 16:56:51 currently the classes for the buildsystems cant manipulate the existing lines (e.g. the LICENSE/LIC_FILES_CHKSUM), only add before/after, so it can't provide its more accurate license info. so i want it to either pass that info back, or let the classes manipulate the existing lines Jan 02 16:57:00 well, it can, but it'll be duplicated in the result Jan 02 16:57:18 mostly just a cosmetic issue in this case, two LICENSE = lines Jan 02 16:58:24 hmm, I think we really ought to allow them to modify the existing lines Jan 02 17:01:00 that does seem most flexible for the future. obviously not a huge priority Jan 02 17:08:38 well I'm happy to make that change, probably won't be until next week but it shouldn't take long Jan 02 17:09:15 np Jan 02 17:10:48 thanks Jan 02 17:10:58 * kergoth works on incorporating the dep scanning Jan 02 17:30:20 bluelightning: so I assume I just need to rename the current recipe as .inc, move the do_compile function out into a separate recipe on top of this, and another wrapper with a slightly different do_compile and that is it? Jan 02 17:30:43 lpapp: in theory yes Jan 02 17:48:15 bluelightning: I am getting this, error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory -> I tried to add both ncurses as well as ncurses native to DEPENDS without making a difference. :-( Jan 02 17:48:58 lpapp: you are getting that message when exactly? Jan 02 17:49:42 bluelightning: bitbake my-recipe Jan 02 17:49:53 more specifically - what task? Jan 02 17:50:29 bluelightning: I will need to investigate how to check that. Jan 02 17:51:01 ah, this is probably again the same issue... 32 bit tool used in the buildsystem ... Jan 02 17:51:09 and I am on 64 bit. Jan 02 17:51:53 possibly, but I'm still unclear on where exactly that message would be coming from with no context Jan 02 17:51:55 ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped Jan 02 17:52:02 I assume my ncurses is only 64 bit. Jan 02 17:52:30 bluelightning: it is coming from our build target when we try to run the 32 bit tool. Jan 02 17:52:40 so I think I need to apply what RP wrote a while ago on the mailing list. Jan 02 17:53:08 hold on a sec Jan 02 17:53:53 a moment ago you said you got that message when you ran bitbake Jan 02 17:53:54 yes, at the compile task. Jan 02 17:54:11 is this 32-bit tool prebuilt? Jan 02 17:54:16 bluelightning: yup Jan 02 17:54:17 bluelightning: http://lists.openembedded.org/pipermail/openembedded-core/2014-November/098521.html Jan 02 17:54:39 bluelightning: perhaps it is easier to convince the vendor to give us a 64 bit variant, too? Jan 02 17:55:02 that Yocto trick does not look simple to me. Jan 02 17:55:25 well, a simpler alternative would be to just install the 32-bit versions of required libraries on your host if your distro provides them Jan 02 17:55:42 Debian & Fedora and derivatives both do, FWIW Jan 02 17:55:58 "Alternatively, a more easier approach would be to build a target like Jan 02 17:55:58 buildtools-tarball with SDKMACHINE="i686" and then install that onto the Jan 02 17:55:59 system you're building on." Jan 02 17:56:29 bluelightning: cat /etc/issue Jan 02 17:56:29 Debian GNU/Linux 7 \n \l Jan 02 17:58:33 I'm trying to build core-image-sato for the edgerouter machine on a debian box. I keep getting errors in do_write_package_deb about invalid version numbers in the linux-yocto package. It seems dpkg is very particular about its version format. Is this a known issue? What's the recommended fix? Jan 02 17:59:00 lpapp: lib32ncurses5 maybe? Jan 02 17:59:05 bluelightning: dpkg --print-architecture Jan 02 17:59:05 amd64 Jan 02 17:59:07 I've tried adding --nocheck to the dpkg call within the recipe but dpkg doesn't like that since it's called with a directory. Jan 02 17:59:38 Aethenelle: which recipe is it failing at? Jan 02 18:00:14 there are several but the first (and only i remember off the top of my head) is linux-yocto Jan 02 18:01:07 Aethenelle: ok... which version of the build system are you building with? Jan 02 18:01:09 yocto/master Jan 02 18:02:07 bluelightning: error while loading shared libraries: libexpat.so.1: cannot open shared object file: No such file or directory Jan 02 18:02:15 unfortunately, I cannot see a 32 bit version of expat :( Jan 02 18:03:35 lib32ncurses5 made the trick for ncurses. Jan 02 18:06:00 lpapp: google suggests libexpat1:i386 Jan 02 18:06:14 bluelightning: I tried that already, but it did not work sadly. Jan 02 18:06:22 E: Unable to locate package libexpat1 Jan 02 18:06:49 ok, don't know then; that does resolve on my Ubuntu machine here Jan 02 18:07:04 yeah, wheezy is old. Jan 02 18:10:12 Aethenelle: ok, I've just tried it here and I can't reproduce that (although I am on Ubuntu and not Debian); can you please file a bug at http://bugzilla.yoctoproject.org ? Jan 02 18:10:26 k Jan 02 18:11:23 bluelightning: I am trying apt-get upgrade:) Jan 02 18:11:38 ... just realized it may be my config lemme double check and make sure I don't have it in ASSUME_PROVIDED Jan 02 18:12:11 Aethenelle: are you setting your own value of ASSUME_PROVIDED then? Jan 02 18:12:43 I Jan 02 18:12:55 I'm appending to it... probably more than I should... Jan 02 18:15:50 that's always risky and unsupported :) Jan 02 18:16:07 there's dpkg and apt in there... lemme try this again... fwiw, the docs for ASSUME_PROVIDED are easy to get to but don't mention the peril involved. It'd be nice if bitbake warned on ASSUME_PROVIDED for packages with patches. Jan 02 18:18:59 I'll have to get back to you... gonna take a while to finish moving this VM around then re-add pkg_deb and run the build. Jan 02 18:19:03 it's not just patches Jan 02 18:19:12 there are implicit dependnecies on particular versions of things, etc Jan 02 18:19:23 bluelightning: I wonder if I need to add anything special for i386 like that in my /etc/apt/sources.list Jan 02 18:19:24 it can work, but its always a gamble, and if it breaks, you get to keep the pieces Jan 02 18:19:35 this is all I have: cat /etc/apt/sources.list Jan 02 18:19:36 deb http://http.debian.net/debian wheezy main Jan 02 18:19:50 kergoth: Then there should be ART saying that... :P Jan 02 18:22:21 actually... now i remeber... there's a block of text in the default config that mentions its use for libsdl wrt qemu but no mention it's a BadIdea to mess with. Jan 02 18:30:59 It's extremely useful, and safe in certain cases where we know what we're dealing with and what the dependencies are, implicit and explicit, but beyond that.. I've experimented with adding tons of stuff to it before, and it can work well, but if i get a weird failure, i usually remember to go back and drop them to confirm it wasn't the cause before reporting any issues. that said, i dont use that much anymore, sstate means its mostly a one time cost (in Jan 02 18:30:59 theory) Jan 02 18:34:06 bluelightning: I will call it a day; thank you for your help today! Jan 02 18:34:19 have a nice weekend, all. Jan 02 19:08:30 also worth noting... debian testing build-essential apt-install is borked one of the included packages creates a conflict but isn't needed. I'd suggest expanding build-essential in the quickstart docs to the actual packages required for now Jan 02 19:20:34 Aethenelle: shouldn't that be solved pretty quickly in Debian? Jan 02 19:21:34 bluelightning: no idea Jan 02 19:21:44 been that way at least a week Jan 02 19:22:02 that's where I'd expect that sort of issue to be addressed, rather than us documenting around it Jan 02 19:22:05 it's possible I didn't upgrade to testing properly last time... Jan 02 19:22:21 unless there was some kind of upstream comment that it wasn't going to be fixed soon Jan 02 19:23:40 is the darwin SDK stuff officially supported? Jan 02 19:29:22 I guess I'd say it's expected to work and if it doesn't it would be a bug we'd try to fix Jan 02 19:29:52 I've not personally used it myself though Jan 02 19:33:19 bluelightning: then I'll use it when i get a chance and file bugs. I tried it first but had several issues which i don't remember. I also tried on a vm with a shared folder but that failed due to permissions and the build requiring timestamps being settable. Jan 02 20:03:40 problem i was having on debian with build essential was due to bad upgrade Jan 02 20:51:56 is there a way to unmark packages as tainted from a forced run? Jan 02 21:33:21 Aethenelle: bitbake -c clean Jan 02 21:34:27 thanks... i'm pretty sure I used that in the last week too... Jan 02 21:41:32 now i remember the problem i had on OSX, the command used for path manipulation isn't available (realpath i think) Jan 02 21:56:23 oaky. linux-yocto works fine on yocto/master under debian with the ASSUME_PROVIDED removed. Jan 03 00:15:18 bluelightning: https://gist.github.com/kergoth/6cca6caa4e9b22a21f75 - work in progress, but a functioning prototype :) Jan 03 00:31:25 kergoth: nice :) **** ENDING LOGGING AT Sat Jan 03 02:59:59 2015