**** BEGIN LOGGING AT Wed Oct 29 03:00:00 2014 Oct 29 07:34:39 anyone know what might be wrong if running "runqemu qemuarm" only brings me up to a point where it says "VNC sever running on 127.0.0.1:5900"? Should it not take me to a console of the emulated target? Oct 29 07:34:50 or do I need to connect to this prompt myself using some VNC viewer? Oct 29 08:01:15 morning all Oct 29 08:50:41 what is this yocto 1.7 Oct 29 08:50:47 is it safe to move to it? Oct 29 08:52:14 try it and find out Oct 29 08:52:40 I don't think it's officially been released yet Oct 29 08:52:41 I was wondering if I could get an opinion Oct 29 08:52:56 Our device uses a ARM processor from TI Oct 29 08:52:59 an old one Oct 29 08:53:09 that they made a kernel for, 2.6.37 Oct 29 08:53:16 we have been stuck on this kernel ever since Oct 29 08:53:26 w.r.t yocto 1.7 Oct 29 08:53:46 the migration guide is here, FWIW: http://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#moving-to-the-yocto-project-1.7-release Oct 29 08:54:29 I am scared that at some point the yocto will move forwardly sufficiently enough to require a systemd > 204, which is the version of systemd that we are stuck on since we are stuck on an old kernel. My question is, how stressed should I be about this? Oct 29 08:54:34 thanks Oct 29 08:54:54 which release are you on atm? Oct 29 08:55:10 I am on yocto 1.6, with a hacked in kernel and a hacked kernel.bbclass Oct 29 08:55:17 gm bluelightning Oct 29 08:55:20 hi woglinde Oct 29 08:55:26 every time I move from yocto versions I have to re-hack the kernel.bbclass Oct 29 08:56:07 other than that, we are on stock angstrom-yocto1.6 Oct 29 08:56:14 pompomJuice: you're on a release that will be supported for fixes for a little while yet, so unless you need new functionality added in 1.7 you can quite happily stick with 1.6 Oct 29 08:56:44 what is the hack you are making? Oct 29 08:57:29 surely it would be simpler if we could accommodate whatever change you need upstream... Oct 29 08:57:30 the hack harvests some files from the kernel build so that later on when building android, the android build kan build the hardware driver module for the powervr Oct 29 08:58:11 ok, why not just do that from the kernel recipe itself or a common inc file? Oct 29 08:58:17 it is not something that makes sense upstream Oct 29 08:58:31 mmm Oct 29 08:58:40 perhaps not, but there is surely a better way than hacking the class Oct 29 08:59:07 I have re hacked it twice now, I think you might be able move those hacks to the kernel recipy. Oct 29 08:59:24 but some of them are pretty in there Oct 29 08:59:41 I am not so worried about the kernel.bbclass hack Oct 29 08:59:50 I am worried about my systemd being left behind Oct 29 09:00:09 we are stuck on systemd 204 Oct 29 09:00:19 and I do not know when this is going to start causing problems Oct 29 09:00:31 ok, well that I'm not sure of, you'd need to dig into that Oct 29 09:00:46 why is systemd tightly coupled to a kernel Oct 29 09:00:49 who did that Oct 29 09:00:58 what were they thinking Oct 29 09:01:14 it causes serious potential problems Oct 29 09:04:05 unfortunately that is the way systemd operates, it takes advantage of new functionality in the kernel fairly rapidly Oct 29 09:04:45 uugh Oct 29 09:04:52 we are using 216 in the 1.7 release - for reference the systemd requirements are here: http://cgit.freedesktop.org/systemd/systemd/tree/README?id=v216 Oct 29 09:05:30 see but then I cant go to yocto 1.7 since I am stuck on an old kernel because my hardware is stuck on an old ARM chip. Oct 29 09:05:43 Does this mean that I can not move forward with yocto anymore? Oct 29 09:06:20 and when I think of it you will always have this problem Oct 29 09:06:43 you still have the option of forward-porting the older systemd recipes; or alternatively complain to the vendor about not either providing an up-to-date kernel or getting their stuff upstream Oct 29 09:07:14 I guess I could complain, but they will be like. Look that chip is 5 years old we dont give a damn Oct 29 09:08:35 and 5 years is not that old, our product took 5 years to develop and we would like it to have a life of say 15 years still. Oct 29 09:08:47 but this seems impossible with the issues that I am seeing Oct 29 09:09:19 why? Oct 29 09:09:20 I was wondering if there is some standard solution to this problem, like you said complain to the vendor Oct 29 09:09:21 well there's no particular imperative to upgrade to the latest Yocto Project release when it comes out Oct 29 09:09:29 just ackport the systemd version every time Oct 29 09:09:32 backport Oct 29 09:09:51 that is what I am currently doing... I have a "backported" systemd onto yocto 1.6 Oct 29 09:09:54 and it seems to work Oct 29 09:10:17 but I sometimes get strange behaviour and hangs on systemd " Oct 29 09:10:18 in any case presumably you have some kind of agreement with the vendor to actually supply you with processors for the lifetime of the product? shouldn't that come with some level of software (i.e. kernel) support as well? Oct 29 09:10:22 but I sometimes get strange behaviour and hangs on systemd "stop jobs" Oct 29 09:11:17 I guess so bluelightning Oct 29 09:11:56 what would be the probability that I extract whatever they did to the stock 2.6.37 kernel and move that to a 3.x kernel Oct 29 09:12:11 I am kernel noob I have no idea if something like that could work Oct 29 09:12:38 hard to say, I'm not a kernel dev either, but I'd imagine it depends on what changes they made Oct 29 09:12:52 aah ok Oct 29 09:13:47 in the mean time I am going to try to move to 1.7 and use a 204 systemd and see what happens Oct 29 09:13:57 so far this has worked. Oct 29 09:15:29 pompomJuice or hire a kernel dev Oct 29 09:15:41 por contract Oct 29 09:16:44 il have to become one Oct 29 09:16:54 I'm supposed to be the guru here, and I am lost Oct 29 09:17:11 kernel dev seems complicated full of history I don't have Oct 29 15:06:45 If I wanted a particular image target for a build, I wanted to influence the configuration of a dependency package that gets pulled into this image. Would the best approach to this be inserting something into the IMAGE_FEATURES and querying that in the package that I'm interested in adjusting (depending on the image that's being built)? Oct 29 15:08:28 e.g. I want to build image foo_image, it pulls in package a_library.bb, so does bar_image. I want the configuration of a_library to be different based on the image being built. Oct 29 17:24:36 bmouring: our system isn't designed to support that kind of setup I'm afraid Oct 29 17:24:51 images aren't meant to influence build-time configuration Oct 29 17:25:31 one workaround you can use is to have two or more differently built versions of the package you want to influence and then just select the appropriate one from the image Oct 29 17:25:44 bluelightning: thanks. Is there any reason that using some "*_FEATURES" flag and probing for that.. or that Oct 29 17:25:55 I was thinking along those lines as well Oct 29 17:26:05 but prototyping for the former Oct 29 17:26:24 setting that from the image recipe won't affect any other recipes Oct 29 17:27:33 *that == a differently-configured duplicate recipe? Oct 29 17:30:12 bmouring: I meant just setting a variable from the image recipe, that can't affect any other recipe Oct 29 17:30:35 gotcha Oct 29 20:24:49 new wind bug coming up :) Oct 29 20:28:34 http://pastebin.com/XSE71yxp Oct 29 20:41:39 Crofton|work: and what happens when you run bitbake -e gnuradio-demo-image ? Oct 29 20:43:04 parse error :) Oct 29 20:43:13 I filed a bug with that info Oct 29 20:43:34 basically, the error message should be more helpful Oct 29 20:45:40 I've added a comment and reassigned to Tom Oct 29 20:45:49 quick Oct 29 20:46:10 I also need to file a bug about labels in wks files not being applied to ext4 partitions Oct 29 20:46:33 the one I jsut filed is not super critical, just something I wanted to record **** ENDING LOGGING AT Thu Oct 30 03:00:00 2014