**** BEGIN LOGGING AT Fri Jan 31 02:59:58 2014 Jan 31 05:05:45 Hi. I have a question for any yocto gurus out there. We want to override a default installed configuration file with one of our own in our own layer for a standard package. To be more precise, we have setup our own layer and we have added lighttpd into our RDEPENDS for our layer. But now we want to use our config file and not the one that comes by default with the lighttpd package. Thoughts, pointers? Jan 31 05:06:32 I tried adding a bbappend receipe into our layer for the lighttpd package, but haven't had any luck getting it to work. Jan 31 05:13:07 We actually want to do this for a few standard packages, lighttpd is just an example Jan 31 06:00:48 thirtythreeforty: yeah, right, I did not notice it. Perhaps, I should not use irc after waking up. Jan 31 06:01:02 haha Jan 31 06:01:27 any ideas, lpapp? Jan 31 07:23:20 rburton: ping Jan 31 09:14:43 rburton: if I understood correctly, I should not check the bblayers.conf into our repository since it would be generated out the sample file when needed, right? Jan 31 09:27:26 There are two vesion of bison in meta/recipes-devtools/bison, 2.3 and 2.7.1, how do I get bitbake to use version 2.3 Jan 31 09:28:42 dguthrie: set the preferred version. Jan 31 10:14:14 morning all Jan 31 10:26:34 rburton: hi, have you seen my question? Jan 31 10:38:03 I've put PREFERRED_VERSION_bison-native = "2.3" in the bb file but bitbake is still compiling and installing bison-native-2.7.1??? Jan 31 10:42:14 dguthrie: put it in local.conf or your distro conf, otherwise the setting is specific to the recipe Jan 31 10:42:28 ie the resolver can't see it Jan 31 10:42:37 rburton: the tmp issue was noexec... Jan 31 10:43:44 rburton: Thanks, that fixed it Jan 31 12:31:28 rburton: so I should not check the bblayers.conf in, inside the build folder, right? When it is needed, it will be automated for every developer checking out the repository if I use the ##COREBASE## properly in the meta-foo/conf/... bblayers sample conf, right? Jan 31 12:33:05 lpapp: that's right. Jan 31 12:33:44 the bblayers typically has hard coded absolute path, so it's not appropriate to check it in. Jan 31 12:34:28 ndec: yes, thanks... I previously used TOPDIR though not to have it absolute. :) Jan 31 12:41:08 interesting, building core-image-minimal requires more than 10 G B? Jan 31 12:41:11 10 GB* Jan 31 12:41:18 (ran out of the disk space...) Jan 31 12:41:43 12 GB* Jan 31 12:42:30 lpapp: compilers and kernels are big. use rm_work if you have limited space. Jan 31 12:43:17 ah, right, I forgot the rm_work magic in the new checkout... Jan 31 12:43:22 thanks. Jan 31 12:43:23 # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf Jan 31 12:43:23 # changes incompatibly Jan 31 12:43:24 LCONF_VERSION = "6" Jan 31 12:43:29 LAYER_CONF_VERSION vs. LCONF_VERSION Jan 31 12:44:07 rburton: TEMPLATECONF does not work for me. Jan 31 12:44:14 it is generating the bblayers based on the yocto stuff. Jan 31 12:44:28 oh, wait. Jan 31 12:45:05 rburton: yes, that is correct Jan 31 12:45:21 this is my built script: #!/bin/bash Jan 31 12:45:21 TEMPLATECONF=meta-polatis/conf Jan 31 12:45:21 . oe-init-build-env Jan 31 12:45:23 bitbake myimage Jan 31 12:45:39 rburton: should I use TEMPLATECONF slightly differently? Jan 31 12:46:07 rburton: this is what it generates, http://pastebin.kde.org/pxejzojxi Jan 31 12:46:37 rburton: this is in my sample, http://pastebin.kde.org/pqocxhjzt Jan 31 12:48:28 rburton: did I do anything wrong? Jan 31 12:52:29 rburton: note that, I cannot use OEROOT because it was only added in dora. Jan 31 13:06:34 * danielki wonders what's the best way to autostart a custom app as non-root user Jan 31 13:06:59 danielki: init script doing su? Jan 31 13:07:26 ok, I'll give that a try Jan 31 13:07:41 systemd can do that for you of course ;) Jan 31 13:07:59 danielki: using start-stop-daemon? Jan 31 13:08:22 well, this device isn't using system atm, and think I already spent too much time making it neat :) Jan 31 13:08:31 s/system/systemd/ Jan 31 13:08:44 I wonder if a switch to systemd is meant to be big. Jan 31 13:09:01 lpapp: the problem is, I would have to find out Jan 31 13:09:28 and I can't rationalize the risk in this case Jan 31 13:09:31 a proper switch to systemd is invasive Jan 31 13:10:06 why? Jan 31 13:10:25 because its best to port your init scripts to units Jan 31 13:10:41 zecke: thanks, that sounds like a good idea Jan 31 13:13:35 rburton: is that not straight-forward? Jan 31 13:13:46 depends Jan 31 13:14:15 just saying, whilst it's initially just a distro feature change, actually taking advantage fully is more work Jan 31 13:53:51 JaMa: how would you like to see Kevin's name in the change? I do not have any opinion about it, so please give the pattern you would like to see. :) Jan 31 14:00:12 JaMa: denix : i am trying to build QT5 SDK. i am using dora, so i cherry pick the 2 patches from denix, and when i build my image with -c populate_sdk the resulting SDK does not contain nativesdk-qtbase as i would expect. Jan 31 14:00:25 ndec: QT is Quick Time. Jan 31 14:00:34 i am sure i am missing something obvious.. but i don't see what. Jan 31 14:00:40 ndec: what you are referring to is Qt (Q toolkit) Jan 31 14:01:11 lpapp: yeah.. it's a bit pedantic, but thanks for the note. Jan 31 14:02:38 ndec: it is somewhat serious if you do not get used to the right project term, branding, etc. Jan 31 14:02:48 you may run into other troubles. :) Jan 31 14:06:21 JaMa: I am leaning towards replacing base-passwd with a different tool based on that debian would not accept profile based configuration. Jan 31 14:06:32 it would allow more flexibility... I see at least 3-4 profile scenarios out there now. Jan 31 14:14:11 what's the proper way to create the home directory of a custom user? do I have to do it at first boot? Jan 31 14:14:34 danielki: I would create it before usermod... Jan 31 14:15:00 problem is, the user building the image will not have the rights to create files with arbitrary user ids Jan 31 14:15:30 although, we seem to do it from initscript. Jan 31 14:16:21 ah Jan 31 14:16:27 so it is built in already? Jan 31 14:16:36 hmm? Jan 31 14:16:47 it was just a hack from us.... there must be better solutions. :-) Jan 31 14:16:52 ah Jan 31 14:17:56 it would be nice if it was an image configuration thing. Jan 31 14:18:50 hmm, I am surprised that openembedded and bitbake masters build fine on Archlinux. :-) Jan 31 14:19:41 rburton: is there an example out there for TEMPLATE_CONF? Jan 31 14:20:44 rburton: oh, it is working with TEMPLATE_CONF=meta-foo/conf . oe.... Jan 31 14:21:18 TEMPLATECONF=meta-polatis/conf Jan 31 14:21:18 . oe-init-build-env Jan 31 14:21:27 oh, it was not working from my script because they are on different lines, I think! Jan 31 14:29:44 does the LAYER_CONF_VERSION vs LCONF_VERSION difference deserve a patch? Jan 31 14:36:08 lpapp: from the old patch it looks like Kevin was author of the * part and Scott did the /bin/sh part Jan 31 14:37:38 lpapp: "by Kevin Tian , 2010-07-06" format would be OK I suppose Jan 31 14:39:16 lpapp: and IIRC you said that "Invalid [configuration]" isn't correct for nobash.patch and I agree that this part should be "Pending" or better "Submitted" if someone cares Jan 31 14:44:57 JaMa: I have just discussed it in #debian-mentors. Jan 31 14:45:03 JaMa: and they would not accept it upstream. Jan 31 14:45:16 JaMa: they want to have bash as the default, and they do not wanna add configuration. Jan 31 14:45:45 IMO, a minor profile configuration would be nice for that, but the fact is unfortunate that these patches (i.e. use cases) will not be upstreamed. Jan 31 14:45:45 ok Jan 31 14:46:28 JaMa: but in that case, I should put Scott back, too, right? Jan 31 14:48:48 Kevin, right? Jan 31 15:07:24 JaMa: yeah, I just followed you with Scott. : Jan 31 15:07:26 :-) Jan 31 15:07:54 is it a political decision that yocto does not yet have a forum, or it is just the matter of resource lack? Jan 31 15:31:41 I am trying to override the network interfaces file, I have created a bbappend that adds an extra file path to where my interfaces file is located. For some reason it isn't finding my interfaces file first. How do I list the search paths that bitbake is using to find files? Jan 31 15:32:38 gjohnson: you need to prepend it Jan 31 15:33:13 FILESEXTRAPATHS_prepend := "${THISDIR}/init-ifupdown-1.0:" works for me Jan 31 15:33:37 danielki: I did that with FILESEXTRAPATHS_prepend := "${THISDIR}/init-ifupdown:" and it didn't seem to work Jan 31 15:34:04 gjohnson: you have a directory of that name, with the interfaces file in it? Jan 31 15:34:27 danielki: I do Jan 31 15:34:51 strange; make sure your bbappend is actually picked up Jan 31 15:35:43 danielki: I am doing a qemu build, I noticed that in the poky directory qemux86 has its own interfaces file. Does a machine directory get higher priority when searching? Jan 31 15:35:56 that could be Jan 31 15:36:41 I'm not that knowledgeable about all this, all I know is that the bbappend works for me. I do not have another interfaces in a machine config though. Jan 31 15:40:19 danielki: It appears that a directory based on the machine name takes priority of a general directory Jan 31 15:40:33 ah, that kinda makes sense Jan 31 15:42:38 * danielki wonders if it would be reasonable to list a user's home directory in a /etc/default/volatiles/ file Jan 31 15:43:24 "This configuration file lists filesystem objects that should get verified during startup and be created if missing." <-- very tempting :) Jan 31 15:44:30 itd be badly overloading something designed for an entirely different purpose Jan 31 15:44:50 volatiles is for populating dirs in volatile locations, like ramdisks, to ensure necessarys tructure is there for processes that need to write to those paths Jan 31 15:45:11 yeah Jan 31 15:45:25 on the other hand, the purpose is not *that* different Jan 31 15:45:45 alternatively, I could create the user dir in the same init script which starts the app Jan 31 15:46:34 adduser doesn't create the homedir based on /etc/skel? Jan 31 15:47:01 it does, but we have /home on a separate partition so I had to explicitly disable that for the rootfs build Jan 31 15:47:11 s/partition/UBI volume/ Jan 31 15:48:04 also, I'm not sure that would work for arbitrary UIDs anyway, if the user running the build is not allowed to create files with those Jan 31 15:48:12 ah, I see. I suppose one could enhance the rootfs creation process to move the existing content into the other partition Jan 31 15:48:20 thats not an issue Jan 31 15:48:59 our builds run under pseudo, which is like fakeroot. in appropriate contexts, software believes we're root, and any permissions/ownership changes are stored in a persistent db, which other processes run in that context will see, including rootfs creation tools Jan 31 15:49:08 aaaaah Jan 31 15:49:20 quite handy, that :) Jan 31 15:49:29 I wondered how that could work, and suspected something like this -- but good to know :) Jan 31 15:49:29 but yeah, you could definitely use volatiles for this to get the job done Jan 31 15:49:45 and the UBIFS image creation tools make use of that DB? Jan 31 15:49:59 it uses LD_PRELOAD to intercept common calls Jan 31 15:50:06 and hands back its "fake" info instead of the real fs Jan 31 15:50:12 so yes, transparently Jan 31 16:05:33 kergoth: ah cool Jan 31 16:30:31 hmm Jan 31 16:31:12 can opkg support package group installation? Jan 31 17:13:43 IMAGE_FEATURES += "ssh-server-openssh" -> this does not seem to install the sftp server. I have this in my image recipe. What shall I do to get the sftp server deployed, too? Jan 31 17:14:49 I would even consider it a bug that it ships this config file: Subsystem sftp /usr/lib/openssh/sftp-server Jan 31 17:15:06 it either should not ship a config line like that, or it should ship the sftp-server by default. Jan 31 17:18:17 lpapp: you have to install the openssh-sftp-server package, provided by the openssh recipe Jan 31 17:18:41 zibri: I will file a bugreport. Jan 31 17:18:59 thanks for the workaround idea.. I would like to have it installed for the image though. Jan 31 17:19:10 is there a workaround for that, too? Jan 31 17:19:54 just yet another dependency, maybe? Jan 31 17:20:58 I mean into IMAGE_INSTALL? Jan 31 17:21:00 just add to IMAGE_INSTALL somewhere Jan 31 17:21:03 exactly Jan 31 17:21:20 would it make sense to make it an image feature instead of install? Jan 31 17:23:39 i guess... if you really want to, you could probably add it as an rdepend from a bbappend on packagegroup-core-openssh Jan 31 17:29:50 zibri: I am now checking how the big the sftp server is Jan 31 17:30:01 that is my only assumption why it would not be added by default... if it is big enough, that is. Jan 31 17:30:34 zibri: if I add a new image install like this to the image recipe, "bitbake myimage" will get it right? Jan 31 17:30:41 or I need to clean up something before? Jan 31 17:31:51 it will get it right Jan 31 17:32:14 k, 10x. Jan 31 17:33:01 ah yes, someone told me that image recipes are always re-evaluated unlike package recipes. Jan 31 17:33:41 update-alternatives: Error: cannot register alternative last to /usr/bin/last since it is already registered to /bin/last Jan 31 17:33:44 update-alternatives: Error: cannot register alternative mesg to /usr/bin/mesg since it is already registered to /bin/mesg Jan 31 17:33:50 update-alternatives: Error: cannot register alternative wall to /usr/bin/wall since it is already registered to /bin/wall Jan 31 17:34:10 getting this all the time when trying to install anything with opkg when the sysvinit configuration is called from probably some maintainer script. Jan 31 17:34:13 any idea why? Jan 31 17:35:02 danielki: you were also using sysv, right? Jan 31 17:35:18 yes Jan 31 17:36:14 danielki: using a flash fs? Jan 31 17:36:33 yes, the rootfs is UBIFS Jan 31 17:37:15 got the start-stop-daemon solution working btw Jan 31 17:39:43 danielki: does reboot sync properly for you? It does not seem to sync properly here on this fs... Jan 31 17:41:39 I currently have a problem with an occasional UBI kernel trace, after which it continues to work but hangs on reboot/halt. Other than that, I haven't seen any issues. Jan 31 17:42:03 strange.. I am not sure if reboot is supposed to do proper sync for flash filesystems. Jan 31 17:42:15 I'm pretty sure it is Jan 31 17:42:30 it should umount, which implies sync Jan 31 17:42:50 anything else would be crazy Jan 31 17:43:08 zibri: IMAGE_INSTALL += "openssh-sftp-server" did not help. Jan 31 17:43:23 danielki: well, it is crazy. Jan 31 17:43:38 zibri: still do not have /usr/lib/openssh Jan 31 17:44:31 zibri: it is either not enough, or my image recipe is wrong for this. Jan 31 17:45:16 zibri: this is the short image recipe, http://pastebin.kde.org/pbomq7mna Jan 31 17:47:06 oh, gosh, nvm, of course I flashed the wrong image... Jan 31 17:47:39 danielki: it does not seem to do proper sync for us, neither on jffs2, nor ubifs. Jan 31 17:52:07 lpapp: you can inspect the populated rootfs in the image's work directory before flashing Jan 31 17:53:46 ls -ld /usr/lib/openssh/sftp-server Jan 31 17:53:46 -rwxr-xr-x 1 root root 59388 Jan 28 14:33 /usr/lib/openssh/sftp-server Jan 31 17:53:58 I do not see why such a small sftp server would not be included by default. Jan 31 17:54:08 would it have any disadvantage or just go ahead and patch it in oe-core? Jan 31 17:54:40 sftp is necessary for FileZilla and other sftp only applications... :-/ Jan 31 17:54:43 small for you doesn't mean small for everyone Jan 31 17:54:52 or even pscp.exe default to sftp these days. Jan 31 17:55:05 bluelightning: I do not follow, it is 59 KB Jan 31 17:55:31 compared to a core image minimal system, it is negligible, probably even compared to openssh. Jan 31 17:56:34 i'm with lpapp, including sftp in packagegroup-core-openssh, but our targets have lots of flash =). Jan 31 17:56:37 at the very least, some documentation could have helped, but then again: why generate an sftp enabled config? Jan 31 17:56:55 zibri: lots of means ? Jan 31 17:57:30 I have never seen yet a non-functional openssh server with sftp Jan 31 17:57:31 ~256-512M i guess Jan 31 17:57:45 sftp seems to be the default and only availability for several apps Jan 31 17:57:56 it is somewhat ironic that even p_scp_ defaults to sftp, not scp. :-) Jan 31 17:58:14 zibri: ok, we have much less than that. Jan 31 17:59:19 zibri: btw, got a clue for the sysvinit configuration issue? Jan 31 18:00:05 I cannot install any package with opkg due to that. :-) Jan 31 18:00:51 nope, haven't looked at it, i haven't seen it myself and we use systemd Jan 31 18:03:39 I am very concerned about space as few have only a few megs, but sftp is negligible even for us compared to its usefulness. Jan 31 18:03:46 s/few/we/ Jan 31 18:07:40 unfortunately, several softwares do not support scp at all... so sftp is the "stable" way to handle ssh for us. Jan 31 18:10:19 zibri: I think you probably meant packagegroup-core-ssh-openssh Jan 31 18:11:38 zibri: but if I add it there, the image feature (ssh) will grab this package group underneath, right? Jan 31 18:11:39 lpapp: yes, that's the one. Jan 31 18:11:59 lpapp: huh? Jan 31 18:12:05 zibri: "huh?"? Jan 31 18:12:16 i didn't understand what you said Jan 31 18:12:27 zibri: IMAGE_FEATURES += "ssh-server-openssh" Jan 31 18:12:36 will that include sftp with patching the group? Jan 31 18:12:43 I do not know how that feature works underneath. Jan 31 18:12:58 I would not like to replace that with an explicit group myself if possible. Jan 31 18:13:26 Ah, yes. Have a look at core-image.bbclass, it defines a PACKAGE_GROUP_ssh-server-openssh = "packagegroup-core-ssh-openssh" Jan 31 18:14:03 yeah, I did not grep yet. Jan 31 18:14:04 thanks. Jan 31 18:14:47 zibri: I am not sure it deserves its own group with only openssh added. Jan 31 18:15:04 but it is how it is done now anyway. Jan 31 18:16:57 zibri: anyway, I will leave it minimal then, although one could argue that it would still be possible to stay minimal just by adding openssh... Instead, I will file a bugreport for an sftp enabled default ssh daemon configuration Jan 31 18:17:14 since that at the very least should be sed'd out. Jan 31 18:24:13 zibri: thanks for the help. Jan 31 18:26:06 do_install is not the right way for customizing the subpackage contents, right? Jan 31 18:26:28 I should use FILES_${PN}-foo/bar/baz or I can do it nicely with do_install, too/ Jan 31 18:26:29 ? Jan 31 18:51:35 danielki: are you also using bootlogd? Jan 31 18:51:43 dunno Jan 31 18:51:53 danielki: could you please check Jan 31 18:52:09 I am not enabling anything like that explicitly, but I get errors from Yocto about it. Jan 31 18:52:18 I mean a Yocto generated image. Jan 31 18:52:37 well yeah, there is a /etc/init.d/bootlogd Jan 31 18:52:48 with sysv... it seems that I would need to enable legacy pts in the kernel, but I wonder if the /var/log/boot.log stuff is useful at all... how it is different from dmesg, etc. Jan 31 18:53:01 danielki: do you also have /var/log/boot? Jan 31 18:53:25 nope Jan 31 18:53:31 strange. Jan 31 18:53:41 Starting Bootlog daemon: bootlogd: cannot allocate pseudo tty: No such file or directory Jan 31 18:53:47 are you getting anything like that during the boot? Jan 31 18:53:58 * lpapp is just reading this thread, https://www.mail-archive.com/yocto@yoctoproject.org/msg12563.html Jan 31 18:54:39 I think I have seen that at some point, which would explain why there is no var/log/boot Jan 31 18:54:40 http://askubuntu.com/questions/330407/how-to-save-boot-log-from-failed-boot Jan 31 18:54:42 ah, right. Jan 31 18:54:54 it is useful when your system does not boot properly. Jan 31 18:55:04 and you wanna inspect the boot log in a subsequent rescue boot. Jan 31 18:55:13 bootlogd should probably be ported to Unix98 PTYs Jan 31 18:55:49 if that message is due to missing kernel support for BSD ptys Jan 31 18:56:36 I do not know anything bootlogd, nor do I enable it, yet I am getting it when building an image with Yocto. Jan 31 18:58:13 what makes me worry is enabling "legacy" tty. Jan 31 18:59:15 yes, legacy pty would be BSD pty Jan 31 18:59:28 pty, sorry. Jan 31 18:59:48 that wasn't meant as a correction :) Jan 31 19:00:18 though I thought the boot log would go to the syslog, too. Jan 31 19:00:25 probably not as early as that. Jan 31 19:02:33 right, it is ./meta/recipes-core/sysvinit/sysvinit/bootlogd.init and ./meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb Jan 31 19:03:30 seems, it is not there for systemd. Jan 31 19:21:47 michael_e_brown: I have rebased the patches again Jan 31 19:21:52 yesterday Jan 31 19:22:12 python-misc is always catch the rest net Jan 31 19:22:46 so we might have to package a given lib to python package Jan 31 19:52:55 michael_e_brown: the new patchset also fixes the runtime error you saw which needed python3-misc to fix now needed bits from misc are packaged properly in core package Jan 31 21:00:42 khem: you around? Jan 31 21:29:27 RP: would be nice to have a datasmart method to get a variable with removals applied, for anonymous python code running before _remove processing, so we don't have to poke into bitbake internals to apply them Jan 31 21:46:54 "?=" can override "??=" for a variable setting? Jan 31 21:47:47 or what is the difference between "?=" and "??=" ? Jan 31 21:49:35 oh, http://docs.openembedded.org/bitbake/html/ch02.html#id398548 Jan 31 22:38:02 Hi folks - query: Let's say my package also builds a bunch of tests (and other files needed for testing). Is there a commonly accepted "best practice" for installing those tests in the rootfs? I don't really want them going into /usr/bin, for example. Jan 31 22:46:33 you mean convention as in OE or FHS or ? Jan 31 22:47:01 i'd probably stick them under /usr/share/ Jan 31 22:47:21 the tlp recipe uses /var/lib/ltp i think Jan 31 22:47:24 wrotte: ideally you should make them fit into the ptest framework, putting them in the appropriate place for that, but otherwise i'd say ${libdir}/${BPN}/ or similar Jan 31 22:47:27 *ltp Jan 31 22:47:36 datadir is only appropriate for non-arch-specific scripts and the like, iirc Jan 31 22:47:48 see PTEST_PATH and ptest.bbclass if you want to go that route Jan 31 22:47:51 yeah, ltp is bash Jan 31 22:48:19 but they moved themselves anyway a while back... Jan 31 22:48:26 Thanks mr_science & kergoth Jan 31 22:48:30 I'll take a look at ptest Jan 31 22:48:31 np Jan 31 22:49:07 ptest is just a convention, there's a place you put stuff, a particular way to run the tests, and a convention for the output, and a ptest-runner is provided to run all ptests, as well as a complementary package install bit so you can install all ptests for all the packages installed in a given image Jan 31 22:49:59 that sounds like the way to go, or else just ${libdir}/${BPN} Jan 31 23:00:01 kergoth: agreed, would need some careful naming but I can see the uses for it Jan 31 23:28:27 Hmm, it'd be kind of nice to be able to change the default QA problem behavior, for items not listed either in ERROR_QA or WARN_QA. I could see an argument in favor of making unlisted entries, e.g. new QA checks, error by default, for a distro that's more strict about quality. Maybe I'll look into adding a variable to change the default Jan 31 23:28:35 s/change the default/allow changing the default/ Jan 31 23:46:03 kergoth: we can error out on parsing and ask them to be added to either ERROR_QA or WARN_QA Feb 01 00:04:19 Evening... Feb 01 00:07:22 Anyone ever played with PACKET_MMAP by any chance? Got some weird behaviour on my i.MX6 board (3.0.35 kernel) where it runs much slower than normal sockets and perf shows it as spending 60% of its time in v7_flush_kern_dcache_area - looks like a proper bug but dont have any other boards / later kernels I can take a pop at reproducing with... Feb 01 01:36:18 pev: does your kernel have http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/057480.html Feb 01 01:46:03 khem`: Ah, interesting, no! I'll test now... Feb 01 01:48:16 khem`: btw we couldn't error on parsing, as the available package qa types is only known by 1) ALL_QA, which is ERROR_QA + WARN_QA, or 2) at runtime when package_qa_handle_error is called. would have to either be fatal at do_package time, which isn't much better than ERROR_QA, or would have to make the default behavior controllable, afaict Feb 01 01:48:22 heh Feb 01 02:14:21 Thanks, khem. I'll try those out next week. What I have seems to be working great so far. Feb 01 02:25:14 kergoth: ah, yes but then if we create another variable that wont fix the issue of dangling QA either Feb 01 02:25:35 michael_e_brown: OK thanks Feb 01 02:28:28 * khem` larts ubuntu Feb 01 02:42:12 khem`: the "dangling" case currently does a bb.note(). I intend to add a var DEFAULT_QA or somesuch with values note/warn/error, or similar, to alter the default behavior for unlisted entries Feb 01 02:42:31 might not be ideal, but it would let a distro choose to make it fail by default for unlisted tests Feb 01 02:42:35 s/tests/checks/ Feb 01 02:42:57 * kergoth digs Feb 01 02:46:01 kergoth: ok thats good Feb 01 02:46:53 hacking on my auto python deps code, converted it to a package_qa, and realized i'd get no output without adding it to a _QA var :) Feb 01 02:46:54 khem`: Nope, good catch but doesnt seem to be the culprit... Feb 01 02:47:19 pev: do you see it doing lot of cache activity ? Feb 01 02:48:18 khem`: Unfortunately perf stat doesn't work on this board so only got the output of perf top to look at Feb 01 02:49:02 ok, thats good enough Feb 01 02:57:28 pev: you see it taking longer time in v7_flush_kern_dcache_area or too many calls ? Feb 01 02:59:29 khem`: Frustratingly perf top only shows time spent in the function based on samples rather than entries - it is about 70% of total samples though (and a firther 10% is raw_spin_unlock_irqrestore) **** ENDING LOGGING AT Sat Feb 01 02:59:58 2014