**** BEGIN LOGGING AT Thu Aug 15 03:00:00 2013 Aug 15 04:02:35 okay, i'm getting a double path in SDK_FLAGS and XDG_DATA_DIRS trying to build this libtool-cross recipe... Aug 15 04:02:44 * nerdboy goes to look for old bugs Aug 15 04:15:02 heh, lpapp's error looks just like mine Aug 15 04:22:04 * nerdboy thinks maybe installing emul-linux-x86-compat might help Aug 15 04:24:08 kergoth: got an actual variable name for "prefix target" ? Aug 15 04:25:51 nm, not your comment... Aug 15 07:07:11 Good morning! Aug 15 07:09:28 Is there a way for me to have my-app_1.0.0.bb and my-app_2.0.0.bb and be able to build and _keep_ both in tmp/deploy/ipk so I can sync them to my repo? Aug 15 07:09:32 I need this because we have dependencies on both versions Aug 15 07:12:25 Anyone seen Eric Benard lately? Aug 15 07:43:49 noc chance for me? do I need to make a new package for one of the versions? Aug 15 07:44:25 *no Aug 15 07:45:35 what about my-app2_2.0.0.bb ? Aug 15 08:10:21 c00kiemon5ter: I am hungry now Aug 15 08:11:58 zecke eat something Aug 15 08:12:05 woglinde: cookies! Aug 15 08:12:38 woglinde: C is for Cookies... good enough for me. Aug 15 08:16:11 Are cookies still allowed? Aug 15 08:16:50 Drinking bottomless mug of coffee here. Aug 15 08:17:28 yummy, cookies Aug 15 08:46:09 * c00kiemon5ter steals a cookie from zecke >:3 Aug 15 08:46:14 morning all o/ Aug 15 08:58:48 morning all Aug 15 08:59:44 I added DISTRO_FEATURES_append = " systemd" and VIRTUAL-RUNTIME_init_manager = "systemd" an DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" and I still get rcX.d content. Is that expected or am I still getting some sysvinit stuff in? Aug 15 09:02:42 exosyst: some recipes don't yet provide a systemd unit, instead they rely on systemd's sysvinit compatibility when systemd is being used Aug 15 09:03:15 work is ongoing to clean that up, but services will still start up as expected Aug 15 09:04:44 bluelightning, OK cool stuff, so I am taking the right steps to disable it? Aug 15 09:05:30 exosyst: yes Aug 15 09:32:01 I'm having some issues using a devshell Aug 15 09:32:16 I'm trying to look at ${FILESPATH} Aug 15 09:32:29 but it looks as though it's empty Aug 15 09:32:41 should this variable be set in the devshell, if it is set in the recipe? Aug 15 09:33:24 jackmitchell: no Aug 15 09:33:56 bluelightning: how would I go about exploring variables like these, with a bitbake -e and grep? Aug 15 09:34:44 jackmitchell: you'll only get these kind of things by running the ../temp/run.do_xyz script from within the devshell, assuming it's a shell task that is (and that will actually run the task) Aug 15 09:35:22 hmmm, that just crashed my shell Aug 15 09:36:11 ah wait, I think I was misuing it Aug 15 09:36:42 yes, don't source it :) Aug 15 09:36:55 and my python was set to py3 Aug 15 09:55:47 morning all Aug 15 09:56:18 hi pb Aug 15 09:56:33 hi woglinde Aug 15 09:56:55 morning pb_, woglinde Aug 15 10:08:49 Hi, since some people joined since I asked, I hope you don't mind me repeating my question as I can't find an answer searching google: Aug 15 10:08:51 Is there a way for me to have my-app_1.0.0.bb and my-app_2.0.0.bb and be able to build and _keep_ both in tmp/deploy/ipk so I can sync them to my repo? Aug 15 10:18:15 ? Aug 15 10:19:10 hsychla: if you use the feed scripts in meta-angstrom/contrib you can maintain a feed without it being a direct rsync of deploy/ipk Aug 15 10:19:32 hsychla: but you will need to fixup those scripts a bit as they bitrotted slightly Aug 15 10:20:48 XorA: I have no problems syncing, my problem is that when I build my-app_1.0.0, it deletes my-app_2.0.0.ipk from tmp/deploy/ipk and vice versa Aug 15 10:20:49 right, it's never really been the intent that tmp/deploy/ipk be usable directly as a feed. Aug 15 10:21:49 I'm not entirely sure what entity is responsible for removing the old bits from there nowadays. Originally, opkg-make-index would just move them to the morgue and you could fish them back out from there, but for a while now they seem to be getting deleted altogether. I'm not sure if opkg-make-index has been patched to do that instead or if something else is removing them. Aug 15 10:23:08 pb_: its the set scene stuff isnt it? Aug 15 10:23:57 oh, yeah, I guess it probably is. Aug 15 10:25:15 I don't know either but it can't be make-index because that is not called if I do a normal "bitbake my-app", id it? Aug 15 11:09:06 no, it isn't. I'm pretty sure XorA is right and it's the sstate unstaging that deletes the old bits. Aug 15 11:09:31 I had forgotten that DEPLOY_DIR_IPK is under sstate control, but of course it has to be for rootfs construction to work. Aug 15 11:24:54 can you elaborate a little on that? what would I need to change, if i wanted to keep the other version? Aug 15 11:29:39 I don't think there is any feasible way to keep both in tmp/deploy/ipk. You'll have to build one, evacuate it to some safe location, then build the other. Aug 15 11:30:08 You could arrange for that to happen automatically after do_package_write_ipk, of course, it doesn't have to be a manual step. Aug 15 11:30:48 (Bitbake won't allow you to build two versions of the same thing in a single build run anyway, so this probably isn't going to be a big extra hassle.) Aug 15 11:58:34 pb_: ok, thanks. Aug 15 12:26:48 gm Aug 15 12:32:35 morning Crofton|work Aug 15 12:40:22 jo crofton Aug 15 13:01:32 I'm assuming new bsps should not use soc-family? Aug 15 13:10:24 has anyone experiences issues with pulseaudio 4.0? On imx6 I get "Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed" in pulsecore/mutex-posix.c when playing e.g. an mp3 using qtmultimedia on pulsesink. gst-launch works ok though. Downgrading to 3.0 solves the issue Aug 15 13:19:46 hmm, the board taunts me. it only worked once using 3.0 and now I get the same issue as with 4.0 :/ Aug 15 13:43:15 hi. is there any reason why there are symlinks such as log.do_compile that points to the 'last' log, and not the same symlink for run.do_compile? i find it always painful to open the 'righ' run script. Aug 15 13:43:41 ndec: I've always wondered that myself Aug 15 13:43:47 hehe Aug 15 13:43:54 it's been like that for a very long time Aug 15 13:44:03 do you at least know where the symlink for log.xxx are done? Aug 15 13:46:34 ndec: looks like bitbake/lib/bb/build.py, search for "courtesy link" Aug 15 13:46:43 ndec: I think the runfile generation is also in that file Aug 15 13:46:51 * ndec opens that file Aug 15 14:07:13 ndec: I think it's that way because, in theory, run.do_compile is a non-user-serviceable part. But I agree that it would be better if it did make a symlink for run.* as well. Aug 15 14:08:06 hi, I am trying to understand what exactly this line in base.bbclass is achieving, and how: do_unpack[cleandirs] = "${S}/patches". I assume something will delete that directory before unpack of the archive? Aug 15 14:10:40 OK, I found it in bitbake's build.py - my initial git grep didn't descend into that... Aug 15 14:39:41 should IMAGE_INSTALL += "openssh-sftp-server" be all that's needed for an sftp server to be installed into my core-image-minimal? Aug 15 14:40:08 exosyst exactly Aug 15 14:42:21 woglinde, How can I test this? Im using eclipse and it says sftp-server may not be installed, does sftp no longer allow root:(none) as user:pass? Aug 15 14:42:43 hm? Aug 15 14:42:59 login into the board and opkg list | grep sftp Aug 15 14:43:06 to see if it got installed Aug 15 14:43:13 than check if it is activated Aug 15 14:43:15 with ps Aug 15 14:43:18 ps Aug 15 14:43:21 ok Aug 15 14:43:59 woglinde, no results :-/ Aug 15 14:46:26 I also set ssh-server-openssh in IMAGE_FEATURES too so I'm really at a loss why it failed Aug 15 14:50:59 woglinde, I even tried IMAGE_INSTALL_append = "openssh-sftp-server" and still no joy. A bitbake -k core-image-minimal say all tasks have completed, none needed to rerun Aug 15 14:51:29 try bitbake -c cleansstate core-image-minimal Aug 15 14:51:39 and than bitbake core-image-minimal Aug 15 14:53:11 woglinde, I do have systemd configured rather than sysvinit but that shouldn't cause any issues? Aug 15 14:54:03 woglinde, Task do_cleanstate does not exist for target core-image-minimal - joyous :( Aug 15 14:55:11 woglinde: cleansstate not cleanstate ;) Aug 15 14:55:26 cleansstate Aug 15 14:55:33 I wrote Aug 15 14:55:55 Yeah, I goofed it Aug 15 14:55:56 exosyst maybee you need openssh-server too Aug 15 14:56:03 becaus sftp is normaly driven bei sshd Aug 15 14:56:11 it does work independently Aug 15 14:56:16 last I checked Aug 15 14:56:17 okay Aug 15 14:56:30 wonder how to configure it Aug 15 14:56:49 I've got IMAGE_FEATURES += "package-management ssh-server-openssh" and IMAGE_INSTALL_append += "openssh-sftp-server" Aug 15 14:57:07 IMAGE_INSTALL_append += is not good Aug 15 14:57:12 woglinde, Oh? Aug 15 14:57:17 either append or += Aug 15 15:00:13 hmm - it's performing a core-image-minimal do_rootfs, that's normally a later task once everything has already compiled. I wonder if that means it didn't make a differnece? Aug 15 15:00:37 nope - didn't work either Aug 15 15:00:45 that was with the IMAGE_INSTALL_append Aug 15 15:01:04 that was with the IMAGE_INSTALL_append = "openssh-sftp-server" Aug 15 15:04:17 exosyst: is there a leading space in that value? Aug 15 15:04:53 with _append you'll need it Aug 15 15:06:06 bluelightning, yes there is, sorry. Mistyped it out to IRC as on different machine for build Aug 15 15:06:17 ah ok Aug 15 15:06:35 would have failed with an error anyway if it hadn't been there I suspect Aug 15 15:08:47 I just removed it to test and it didn't error... odd. I wonder if something is wrong with what I've done in my local.conf? Aug 15 15:08:54 exosyst: does your core-image-minimal recipe have the line at the end that deletes the packaging database? Aug 15 15:11:36 bluelightning, Not that I can see, openembedded-core/meta/recipes-core/core-image-minimal.bb just inherits core-image and sets the IMAGE_ROOTFS_SIZE Aug 15 15:12:31 OK, I redeployed after the cleansstate and it looks like I have openssh-sftp-server - 6.2p2-r0 Aug 15 15:12:47 Shouldn't it have started automatically on boot? Aug 15 15:13:09 I would have thought so yes Aug 15 15:13:47 exosyst: is there a file in /etc/init.d/S*/ that looks like it should be starting it? Aug 15 15:13:53 ... ah but I'm using systemd, if it's working right - it would've bound to the socket and only done it on demand... Aug 15 15:20:31 got it - yup, systemd starts it on demand and it was missing from my original image. Thanks guys, working remote it's just nice to bounce around the thought process Aug 15 15:20:50 Cardboard engineering (or "rubber ducking" in the US) FTW Aug 15 15:27:37 np :) Aug 15 16:46:03 bluelightning1: pb_: i have been trying to play with the run.xxx symlink. i am touching some bits which i am very unfamiliar with... what do you think of http://pastebin.com/3eDtnugY? it's on dylan/1.18 branch. it seems to be doing what i needed.. Aug 15 16:47:26 i am not sure about the 'task' vs 'func', though.there can be corner cases. Aug 15 16:53:09 and this might even be better: http://pastebin.com/GCkPu8K1. only make the symlink for 'tasks', not 'functions' as it doesn't really make sense. Aug 15 16:58:04 and one drawback of that, is that the symlink is created only if the 'task' completes. if it fails during the shell or python, we will get exception, and this code is not being executed. we can either create the link before, but then at that time the actual run.xxx.pid is not created yet, or we can move the symlink creation inside exec_shell and exec_python (hence duplicate). Aug 15 16:58:25 it's likely that we want to open the symlink when the task failed in fact. Aug 15 20:34:57 khem: it would appear the anstrom-devel list stopped working in July Aug 15 21:44:11 erbo: ping Aug 15 21:46:22 awesome, oe-classic hardfloat seems to be working... Aug 15 21:47:08 swapping out csl-foo for an angstrom toolchain seems to be the ticket Aug 15 22:34:05 couple more gets patches later and it's still going... Aug 16 02:34:27 anybody seen this? http://tinyurl.com/OS4CS-reactions **** ENDING LOGGING AT Fri Aug 16 02:59:58 2013