**** BEGIN LOGGING AT Mon May 02 02:59:58 2016 May 02 08:13:38 good morning May 02 09:38:05 Wouldn't PNBLACKLIST_remove = "pidgin" when added in bbappend remove recipe from the blacklist? May 02 10:23:39 Hi May 02 10:26:43 Small question guys. I have EGLFS working on the RaspberryPi but I can't find how to target my PiTFT and not the HDMI screen. May 02 10:27:02 When I run ts_calibrate, it properly appears on the PiTFT. May 02 10:27:30 All the QPA variables, FRAMEBUFFER,... points to /dev/fb1. May 02 10:28:21 Which is supposed to be the good one. (cat /dev/random > /dev/fb1 gives my PiTFT turning grey.) May 02 10:28:37 Does someone have any idea? May 02 10:31:10 I have a Qt application appearing one the wrong screen though. May 02 10:31:35 I need to find how to disable HDMI? Or beeing able to switch? May 02 10:31:45 Thanks for any clue! :) May 02 10:56:31 And also I got a message telling I shoudl set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT. May 02 11:07:19 present: Did you set QT_QPA_EGLFS_FB to /dev/fb1 ? May 02 11:09:35 frsc: yes May 02 11:10:03 I just set the QT_QPA_EGLFS_PHYSICAL_* also and switched on the debug. May 02 11:12:32 root@LightPixels:~# env | grep QPA May 02 11:12:33 QT_QPA_EGLFS_PHYSICAL_HEIGHT=50 May 02 11:12:33 QT_QPA_EGLFS_HEIGHT=240 May 02 11:12:33 QT_QPA_EGLFS_HIDECURSOR=1 May 02 11:12:33 QT_QPA_EGLFS_FB=/dev/fb1 May 02 11:12:33 QT_QPA_EGLFS_DISABLE_INPUT=1 May 02 11:12:33 QT_QPA_EGLFS_DEPTH=16 May 02 11:12:34 QT_QPA_EGLFS_PHYSICAL_WIDTH=69 May 02 11:12:34 QT_QPA_EGLFS_TSLIB=1 May 02 11:12:35 QT_QPA_PLATFORM=eglfs May 02 11:12:35 QT_QPA_EGLFS_WIDTH=320 May 02 11:12:36 root@LightPixels:~# env | grep TSLIB May 02 11:12:36 TSLIB_TSDEVICE=/dev/input/touchscreen0 May 02 11:12:37 TSLIB_FBDEVICE=/dev/fb1 May 02 11:16:45 I just tried out this syntax: QT_QPA_PLATFORM="eglfs:fb=/dev/fb1" May 02 11:21:05 There is a tty on this screen first. May be there is some interaction. May 02 14:34:23 Hi, is there any preferred way to add mount point to the build? May 02 14:34:23 Until know i used a ROOTFS_POSTPROCESS_COMMAND which appends the line to /etc/fstab. But that doesn't really feel nice. May 02 14:40:45 fl0v01: not that I know of unfortunately... I had various ways of doing this depending on my needs May 02 14:41:25 for instance I had a recipe that only had a postinstall on target that would run fdisk+mkfs+patch /etc/fstab (so It could fill-up the whole disk) May 02 14:41:44 I had stuff patching the usb liveboot so that the install grub target would do the same as above May 02 14:41:57 and I had what you mentionned above May 02 14:42:04 hm okay May 02 14:42:18 I never looked into wic yet, but I assume it would be a cleaner way to do it... I just hadn't had the chance yet May 02 14:43:27 ok ill look into it. Thank you! May 02 14:43:47 yeah, having a /data writeable partition with a read-only / is something my customers ask quite often and is not easy to do... I wonder if using some sort of overlayfs would be easier May 02 14:58:38 hi May 02 14:59:37 for some reason, a kernel fragment does not override an unset option. Is there a way to see the overrides' application? May 02 15:00:21 also: is there a way to "undef" a feature that was chosen by a defconfig using a kernel config fragment in a .bbappend? May 02 15:09:03 How would bitbake notice that the code of a python function that's called from a task changes? May 02 15:09:31 I'd expect a mechanism similar to vardeps, but how do I check that the dependencies are correctly detected automatically? May 02 15:50:59 neverpanic: i don't think there's a good mechanism to dump the detected deps short of adding debug messages to build_dependencies() in bitbake, there was a recent question on the list about that. but any call to getVar/contains/etc will be picked up as a variable dependency, unless it's dynamic, i.e. the argument with the name is a variable or constructed dynamically, in that case that's where you need vardeps, to list those explicitly May 02 15:51:25 neverpanic: if you run bitbake with debug messages enabled, you can see messages whenever it encounters such dynamic cases, but there are so many of them it's hard to do much with that info at this time May 02 15:52:24 Yeah, I've seen Ulfalizer's code on the list, and I've used that... it just doesn't list task and function dependencies because he calls it with empty sets as input May 02 15:53:11 Just to confirm, if I change the code of a python function, that should make the next run ignore the sstate cache for a task that calls this function, right? May 02 15:54:54 neverpanic: bb.data.generate_dependencies(data) will run build_dependencies against all existing tasks and their dependencies, including exported vars May 02 15:55:29 neverpanic: it's not that the cache is ignore, it's that the task checksum changes due to one of its deps changing. if you already had results for that checksum in the cache, it would use them May 02 15:55:33 s/ignore/ignored/ May 02 15:55:45 but effectively yes May 02 15:57:24 yes, I know that modification changes the task hash, I'm just wondering if any modification, even if it doesn't add/remove/change a vardep, causes a change in the task hash May 02 15:57:34 But I guess I could just try that easy enough locally. May 02 15:57:44 it hashes the contents of the task and the contents of all the deps of the task May 02 15:57:48 so by definition yes May 02 15:57:55 it baiscally does md5(function-contents) May 02 15:58:13 OK, thanks. May 02 15:58:46 if you want more details, the code is fairly comprehensible May 02 15:59:03 https://github.com/openembedded/bitbake/blob/master/lib/bb/codeparser.py May 02 15:59:20 https://github.com/openembedded/bitbake/blob/master/lib/bb/codeparser.py#L192 May 02 16:00:37 thanks, that's actually pretty simple May 02 16:01:06 yeah, just compiles the ast and visits its nodes. pretty straightforward May 02 16:01:22 the shell parsing is uglier, since pysh has to have a new lexer and parser for it, and thatc ode really isn't maintained May 02 16:01:53 pysh was written by the mercurial folks as a way for them to run their unit tests on windows without an actual shell :) May 02 16:03:02 i wrote the original checksumming and code scanning code ages ago, richard did a massive amount of work to integrate it into bitbake and add all the caching so it didn't make things horribly slow May 02 16:03:53 if you're really curious, https://github.com/kergoth/OE-Signatures still exists :) May 02 16:04:21 "We need a way to handle variable references from code in the bb and oe python packages. Either we try to read in the .py files, compile to an ast, and analyze the functions from those that we call, or we need to set the necessary varrefs explicitly. And if we set it explicitly, either we need to set it for every variable that calls the function, or we need to store, somewhere, a mapping of bb/oe function to a list of additional varrefs." still isn't May 02 16:04:21 really handled, sadly. python modules in meta/lib/oe/ for example aren't checksummed, so changes to those won't alter the checksums of the code calling them May 02 16:06:26 i was thinking that it'd be nice to add better tracking of shell variables eventually. i.e. we could determine if a shell function references $foo without either 1) defininig it or 2) exporting it in the metadata May 02 16:06:31 there was talk at one point of checksumming the lib stuff, but I know it wasn't because changes to those files should not affect processing output.. i.e. they should have stable APIs May 02 16:07:02 i think we're dreaming on that, we suck at having stable apis. look at how tightly bound bitbake and oe-core are :) May 02 16:07:24 ya, I won't disagree there.. May 02 16:09:13 Hmm, I forgot the python code scanner picks up execs via Name. we could add those to the list of variables referenced if those exist as variables, for inline python May 02 16:09:27 i.e. currently "${@FOO}" isn't, to my knowledge, recording the dependency on the FOO variable May 02 16:09:33 only ${@'${FOO}'} does May 02 16:09:37 but both are valid syntax May 02 16:09:58 should double check that May 02 16:10:41 oh. no, i'm wrong, it should be handling that. nevermind May 02 16:10:47 deps = deps | (keys & parser.execs) | (keys & parsedvar.execs) May 02 16:10:59 heh May 02 16:11:18 oh, no, i was right the first time, execs only catches *called* Names May 02 16:11:22 * kergoth rolls eyes at self May 02 16:12:55 there'd be potential for issues processing all Names, though. python code could set foo = bar, and then reference foo, and if we also happen to have a var named foo in the metadata it'd think it deps on that. so we'd have to track variable definitions as well to exclude those, and to do that properly we'd need to maintain contexts to handle scope.. May 02 16:13:11 i see why i never added that, now :P May 02 18:36:25 Hmm, do we have code anywhere in oe-core or bitbake to process size suffixes. i.e. to/from the short / "human" form? May 02 18:36:33 i.e. g, m, k, .. May 02 20:02:01 RP: pile of stuff on the bitbake list, just to make sure it's on the radar. no rush, of course, low priority, it's on our roadmap for 2.2 :) May 02 20:02:06 (mentor's, that is) May 02 21:09:50 Hmm, seems like anonymous python execution order has changed..either that or something really weird is going on here May 02 21:09:53 * kergoth scratches head May 02 21:20:41 Does anyone know the correct mailing list for pseudo patches? May 02 21:21:57 georgem: that question was here recently, let me grep the logs May 02 21:22:35 kergoth: I saw, thanks. Is a public holiday today so I've not really looked closely, was confused about the missing v3 but I see its there now! May 02 21:24:01 neverpanic: thanks May 02 21:24:22 2016-04-28 https://p.dnnr.de/mIX0M0buDd2sdD9z May 02 21:24:37 If seebs_ isn't around to answer directly, I'd just do that. May 02 21:25:13 I *need* to add more unit tests to shallow, but we really need more git tests for different states of the DL_DIR In general, and then my head hurts May 02 21:25:14 heh May 02 21:44:47 kergoth: right, the current tests are better than nothing but we could do a lot better May 02 21:45:32 it's easy to avoid or put off. it's a world of pain, really, and we have so many other priorities to address.. May 02 21:52:26 Hmm, am I missing something, or is the wic image fstype sucking in things it doesn't actually need? bootimg is run, but we don't actually need an hddimg file, all we want is the files in the hdddir, and it builds an initramfs if INITRD is set, but wic won't use it.. May 02 22:02:28 kergoth: I suspect there is a lot of cleanup that needs to be done in that area... May 02 22:44:58 why does image-live.bbclass depend on INITRD_IMAGE_LIVE, but then use INITRD for the actual filesystems to use as an initrd? afaict INITRD_IMAGE_LIVE and INITRD_LIVE aren't used anywhere. May 02 22:45:17 also, why are there so many hardcoded assumptions on live images, even when wha tyou're ubilding has nothing to do with live images or installers? May 02 22:45:30 this all needs some serious refactoring, IMO May 02 22:48:57 okay, i think i need to create a new wic plugin to populate an efi boot partition purely based on whats in DEPLOY_DIR_IMAGE, ypassing the HDDDIR / image-live / do_bootimg stuff entirely. then i think it'd behave more to my liking May 03 00:00:45 Hmm, tried a wic create with --bmap, but the image's apparent and actual sizes are both 3.5g.. May 03 00:00:51 doesn't seem to be sparse **** ENDING LOGGING AT Tue May 03 02:59:58 2016