**** BEGIN LOGGING AT Wed Jan 07 02:59:58 2015 Jan 07 08:37:32 morning all Jan 07 08:41:16 good morning Jan 07 09:49:02 good morning Jan 07 09:51:18 hello Jan 07 09:51:37 is there a way to exclude a file from the FILES_* pattern? Jan 07 09:51:40 (dylan) Jan 07 09:52:01 I would like to exclude the .debug folders, otherwise it would be much more work to do it right. Jan 07 09:53:36 is there a list of the supported boards ? Jan 07 09:53:52 (like raspberry pi, beaglebone, banana pi, etc.) Jan 07 09:54:25 Metax: as nobody is required to announce/list/certify his BSP, there is no such thing as a comprehensive list Jan 07 09:54:50 Metax: usually the board vendor says if yocto/oe support is available, or not Jan 07 09:54:56 Metax: I think this is your best bet, http://layers.openembedded.org/layerindex/branch/master/layers/ Jan 07 09:55:10 ok, thx Jan 07 09:55:19 lpapp: this was the page I had Jan 07 09:55:27 (and google of course) Jan 07 09:55:29 with https://www.yoctoproject.org/downloads/bsps Jan 07 09:55:46 but the last doesn't seem complete Jan 07 09:56:00 (no raspberry for example) Jan 07 09:56:05 Metax: of course, it never can be Jan 07 09:56:18 I understand Jan 07 09:56:34 Metax: like my company for example has a bunch of boards that we have layers for, but those are not publicly available, and we don't want them listed Jan 07 09:57:26 Metax: those are mostly intel layers, whereas raspberry pi is not maintained by Intel. Jan 07 09:57:36 so in that sense, it is "complete". Jan 07 09:59:04 ok, thanks Jan 07 09:59:09 you could also have an extended look at the metalayers hosted on git.yoctoproject.org Jan 07 09:59:26 what are the most used boards ? Jan 07 09:59:38 Raspberry I guess, probably beaglebone ? Jan 07 09:59:47 Metax: who knows? Jan 07 09:59:53 and no, i think that its not an intel issue - its an issue of what vendor wants to publically show his stuff Jan 07 10:00:17 ti for example has a well-maintained and extensive layer there too. Jan 07 10:00:18 Metax: you are asking quite broad questions :) Jan 07 10:00:23 (hard to answer) Jan 07 10:00:36 I know :) Jan 07 10:01:03 I'm discovering yocto, and I'd like to know wich boards are ok with it Jan 07 10:01:20 And then, I'll buy it and test Jan 07 10:01:31 out of curiosity: is there any practical use of knowing which layer is the most common? Are you thinking about launching a project and target the most used? Jan 07 10:01:48 right. Jan 07 10:02:08 Metax: well, raspberrypi is cheap, but then again: you will get different answers from different people. Jan 07 10:02:42 personnally, i'm not fond of raspberry Jan 07 10:02:57 it's cheap, but there are better for a few more dollars Jan 07 10:03:18 (banana pi, beaglebone black) Jan 07 10:03:19 like I said, these questions are primarily opinion based and broad Jan 07 10:03:25 I know :p Jan 07 10:04:02 it's just that I'd like to know if the banana pi (for example) is well supported before buying it Jan 07 10:05:00 for instance, you do not even need a board to experiment with Yocto. Jan 07 10:05:21 Yeah, but it's funnier with one :p Jan 07 10:06:12 well, I would go the other way around, personally: what I am trying to achieve Jan 07 10:06:20 and fit or not fit Yocto later Jan 07 10:06:57 Yocto is not an end goal, just means :) Jan 07 10:07:05 lpapp: re excluding .debug folders - no there is no exclusion mechanism; if you don't want them produced, perhaps set INHIBIT_PACKAGE_DEBUG_SPLIT = "1" Jan 07 10:07:21 (unless it is a theoretical project) Jan 07 10:07:42 bluelightning: that will strip the debug files from the -dbg package. Jan 07 10:08:08 lpapp: perhaps you could explain what you're trying to acheive Jan 07 10:08:40 bluelightning: yeah, I think that would be beneficial, so my main issue is that I have tons of files for installation in /opt, include /etc/ configuration files, libs, executables, et c. Jan 07 10:09:02 bluelightning: Yocto seems to generate .debug in there, which is fine since I have executables coming from us to there. Jan 07 10:09:19 bluelightning: but I have another package for "static" things that come from the vendor and already stripped. Jan 07 10:09:48 bluelightning: the 2-3 executables coming from us in the /opt tree would go into our own package and they need .debug into -dbg since that is our software Jan 07 10:10:25 bluelightning: but there are many static files coming from the vendor into /opt and so I thought FILES_ would only catch /opt not to enumerate many files Jan 07 10:11:00 bluelightning: but that will inherently catch the .debug things generated in /opt and will rightfully get an error from Yocto that it is not going into the -dbg package. Jan 07 10:11:57 bluelightning: and in PACKAGES I would put our package prior to the static package so that /opt "catch-all" would catch the rest. Jan 07 10:12:22 bluelightning: that is why I am claiming that excluding .debug would be easier than explicitly listing hundreds of files Jan 07 10:13:52 well, our packaging code does not support exclusions, the way this sort of thing is normally handled is by controlling the order of PACKAGES such that the appropriate package picks up the files first Jan 07 10:14:56 ok, so I would need to do pkg1 -dbg pkg2, where pkg2 is the /opt catch-all. Jan 07 10:18:32 that's what I'd recommend yes Jan 07 10:19:37 thanks. Jan 07 10:57:16 bluelightning: do you know how I could debug why already-stripped does not work, given that the binaries in question are in the right packages-split directory? Perhaps, it was not functional in dylan? Jan 07 10:59:10 lpapp: well, the code that implements the checks is in either package.bbclass or insane.bbclass (we did move all of it to insane.bbclass since then), so it would be a matter of adding print (or more effectively bb.warn() ) calls and figuring out why it's not taking effect Jan 07 11:00:05 bluelightning: ok, was it supposed to work in dylan to start with? Jan 07 11:00:21 as far as I am aware, yes Jan 07 11:00:34 we may even have been using it actively in dylan, check the u-boot recipe Jan 07 11:04:06 bluelightning: empty output for 'grep -rn "stripped" ../meta/recipes-bsp/u-boot/' Jan 07 11:04:36 I guess it was added to the recipe later in that case Jan 07 11:12:49 what is the difference between disabling debug split and already-stripped for non-strip-mixed packages? Jan 07 11:13:02 I mean difference as in difference for the end user, not implementation. Jan 07 11:21:35 INHIBIT_PACKAGE_DEBUG_SPLIT will prevent debugging symbols from being split out at all Jan 07 11:21:46 for all files installed by the recipe Jan 07 11:22:26 yeah, so the difference is only for mixed-strip-packages? Jan 07 11:22:34 if you do not mix that, it is the same effect? Jan 07 11:22:52 no, they aren't at all similar Jan 07 11:22:59 why is that Jan 07 11:23:27 INSANE_SKIP is telling the system to not produce a warning if the symbols aren't even present in the binary file Jan 07 11:24:11 well, if it is split, I would not assume a warning to be asserted Jan 07 11:24:44 I'm not sure what that means Jan 07 11:25:06 if you disable the debug things, I would not expect "already stripped" warnings. Jan 07 11:25:12 since I told the buildsystem to forget about debug things. Jan 07 11:25:52 if you set INHIBIT_PACKAGE_STRIP then yes the warnings will not occur, because the code that checks for the symbols won't even be executed Jan 07 12:44:23 zeddii, you awake yet? Jan 07 12:53:46 bluelightning: how do I use INHIBIT_PACKAGE_STRIP for a particular package in a recipe? Jan 07 12:54:24 similarly as FILES_* ? Jan 07 13:12:38 lpapp: you can't I'm afraid Jan 07 13:13:14 bluelightning: ok, well, then I still need to find a solution for the already-stripped issue. It looked like a workaround. Jan 07 14:02:37 Crofton|work, I'm awake now! Jan 07 14:07:54 hacking around, found one issue on my end Jan 07 14:08:01 this kernel stuff is "fragile" Jan 07 14:08:39 * zeddii understands. Jan 07 14:08:47 damn it Jan 07 14:08:49 I'd rm -rf * and start over if I could Jan 07 14:09:10 did the add "CONFIG_INPUT" without the =y and no error Jan 07 14:09:21 Crofton|work. what's the hot issue ? are the patches not applying ? Jan 07 14:09:28 not sure Jan 07 14:09:38 I backed oe-core up Jan 07 14:10:03 k. I'll start my sanity tests on patches and configs again, and see if anything pops out. Jan 07 14:10:04 trying to reduce the set of things I am tryin gto fix, when I see something build here, I will go forward Jan 07 14:10:25 sounds sane. I'll see what I can find out in the mean time. Jan 07 14:10:29 I think I will start filng nuisnace bugs about cases where it would really help to refuse to build Jan 07 14:11:37 Crofton|work. tag me on them, and I'll take care of the ones that make sense. I have an open bug to make the auditing and sanity more visible (again .. I was asked to hide it years ago), so I can group them together. Jan 07 14:12:10 it is really hard to figure out what is going when kernels build even though your cfg bits are nonsense Jan 07 14:13:41 Crofton|work. I'll dig up the bugzilla I was talking about. you can toss flames and comments in it. Jan 07 14:14:26 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6943 Jan 07 14:14:27 Bug 6943: enhancement, Medium+, 1.8 M2, bruce.ashfield, IN PROGRESS IMPLEMENTATION , kernel-dev: make Kconfig audit output visible Jan 07 14:23:20 ok got a .o for the driver I am trying to add Jan 07 14:23:25 now trying against master Jan 07 14:24:35 zeddii, to be clear, the audit would tell me about options I am tryin gto set, that do not get set in final config? Jan 07 14:25:38 yep. Jan 07 14:26:05 and optionally, halt the build (via a flag) Jan 07 14:26:36 I'm getting my env setup to test now. I'm running out of builders with all the bugs in progress. Jan 07 14:27:51 ok, I do not have an issue with master, just overall crappiness of kernel stuff :) Jan 07 14:28:02 I have the same issue! :P Jan 07 14:28:08 :) Jan 07 14:28:17 I'll add some fuel to the fire on the bug Jan 07 14:28:23 we'll have a beer and commiserate Jan 07 14:28:25 perfect Jan 07 14:28:34 now I down to wic being broken in oe-core/dizzy Jan 07 14:28:39 excellent Jan 07 14:32:15 updated, and I did some SHOUTING even Jan 07 14:34:30 hi Jan 07 14:34:45 gm Jan 07 14:34:56 Can anyone help me in integrating megacity window manager with poky-dizzy Jan 07 14:35:00 ? Jan 07 14:35:12 RP, you are off the hook wrt to me and the kernel, just crappy kernel tooling :) Jan 07 14:35:22 I added my isue to the existing bug Jan 07 14:35:33 and will drink beer with zeddii Jan 07 14:38:36 Crofton|work: great, I'm pleased I'm off the hook on something for a change! :) Jan 07 14:38:46 Crofton|work, I like the shouting :P Jan 07 14:39:11 now back to the pile Jan 07 14:39:22 zeddii: we should probably make the config "warnings" unconditionally fatal and be done with it Jan 07 14:39:42 zeddii: its where we're heading with other areas like packaging Jan 07 14:39:55 adams_: metacity? it's in meta-gnome. Jan 07 14:40:22 RP: agreed. I can do that under the time allocated for my bug. and it has a side benefit of forcing certain people to keep the kernel configs always clean an up to date Jan 07 14:40:27 * zeddii whistles innocently Jan 07 14:40:41 zeddii: ;-) Jan 07 14:40:44 heh, the comment about not alarming the user or breaking the build when doing that would have led to to the solution quickly annoyed me Jan 07 14:41:29 Crofton|work. opinions have shifted. at one point .. we didn't want to alarm everyone. but now .. game on! :P Jan 07 14:41:52 +1 Jan 07 14:42:13 I can't see why someone would not want to know the kconfig does not have options they are asking for Jan 07 14:42:42 * zeddii nods. Jan 07 14:43:01 and the tools will even tell you if it is invalid for a number of reasons .. which would have caught yours and pointed it out. Jan 07 14:43:48 * zeddii wonders if he'll go 0 for 4 on ECL* talks. I failed all of 2014 to get one accepted. Jan 07 14:44:15 ELC even. Jan 07 14:44:22 *sigh* back to hacking Jan 07 14:52:31 RP: thanks for super fast merge of last 2 patches Jan 07 14:52:58 rburton: RP: any progress on merging libav-9 and REQUIRED_DISTRO_FEATURES changes? They are on ML for months Jan 07 14:53:27 JaMa: now i had a problem with the av series… distro features one is still on my todo list :/ Jan 07 14:53:36 JaMa: np, the kernel one is obviously causing issues in particular Jan 07 14:53:36 with the patches growing in my jansa/master branches, the world builds will be less and less relevant to the state of current master Jan 07 14:53:51 JaMa: good news is that my personal inbox says <200 threads, before xmas it was almost 400! Jan 07 14:54:32 cool, my says 4659 messages just for oe-core.. I need some smarter way of filtering them :) Jan 07 14:54:36 * rburton drops the pcmanfm upgrade series, it's broken Jan 07 14:55:10 JaMa: i've now finally got a small script to move messages in imap based on git logs, as per everyone else Jan 07 14:55:15 yes Jan 07 14:55:21 its like a rite of passage - writing the tool to do that Jan 07 14:55:40 rburton: I think that is just you and I isn't it? :) Jan 07 14:55:54 JaMa: that sounds more like my inbox :/ Jan 07 14:56:26 rburton: so it moves patches to different folder after they are merged to some branch? Jan 07 14:56:50 JaMa: yes, that is what mine does, using simplistic matching on the subject lines and git commit first line entries Jan 07 14:57:17 How i can replace matchbox with metacity Jan 07 14:57:18 looks useful, maybe we should improve the git hook to use the same matching Jan 07 14:57:24 JaMa: i use gmail so oe-core mails get tagged, and get archived on merge Jan 07 14:57:35 JaMa: I think it would make patchwork much nicer Jan 07 14:57:42 because the currently used digest didn't match with any patchwork change for months :/ Jan 07 14:59:18 yes trying to keep 3 places (branches, patchwork, imap) consistent is boring and takes a lot of time, more scripting would be nice Jan 07 15:07:08 JaMa: I agree, I've been wondering about some custom tooling Jan 07 15:14:02 i have a baytrail based board and thinking to try yocto on it. is yocto supported on baytrail? Jan 07 15:17:05 hitlin37: yes, the intel-corei7-64 BSP in meta-intel supports that Jan 07 15:19:44 RP: gerrit maintains all 3 in one place, but I know you don't like it :) Jan 07 15:20:11 i'm having all kinds of issues getting openjdk-7 or openjdk-8 to build on any platform. I know jdk-8 only works on aarch64 and i've tried several platforms (currently working through the qemu* images as a test but i've tried wandboard-quad, t4240rdb-64b, edgerouter and aarch64). is there a known combination that currently works? Jan 07 15:20:31 I'm working from yocto/master Jan 07 15:20:43 JaMa: "don't like" is an understatement :/ Jan 07 15:21:04 I don't think I've found a web interface I hate more :/ Jan 07 15:21:45 RP: i haven't seen the one you're looking at but i assure you, there are worse. Jan 07 15:23:20 ok, fair enough.. just had to mention it as we agreed that we need some custom tooling just to be able to deal with incomming patches and review and that's exactly what gerrit does Jan 07 15:23:31 honestly current patchwork isn't much help Jan 07 15:24:57 it mostly acts as shared imap folder, biggest advantage for me is that pwam can reach pw's http easier than git am my gmail inbox Jan 07 15:31:46 rburton: when is someone going to fix the systemd failure? Jan 07 15:32:13 could check out reviewboard as an alternative to gerritt. haven't played with eitehr much, myself, though i know the reviewboard devs Jan 07 15:32:15 * kergoth yawns Jan 07 15:35:48 we were trying reviewboard + stash and found tight integration of git repo and review in gerrit easier to use Jan 07 15:36:47 phabricator also looks nice (as UI), but too different to what I'm used to (so I cannot objectively compare) Jan 07 15:36:49 morning Jan 07 15:54:13 rburton: thanks for the reply. the one i have here is intel atom E3825 Jan 07 15:55:17 ah, i think that one is also there in dual core version of minnowboard Jan 07 15:55:26 so may be it has support from yocto Jan 07 15:56:15 * hitlin37 checks minnowboard project Jan 07 15:58:19 if you have a baytrail board you want meta-intel Jan 07 15:58:48 meta-minnowboard is for the original minnowboard which wasn't baytrail Jan 07 16:01:21 ah. Jan 07 16:01:23 hmmm Jan 07 16:03:52 hitlin37: FYI: http://www.elinux.org/Minnowboard:MinnowMaxYoctoProject Jan 07 16:05:14 thanks bluelightning Jan 07 16:05:37 rburton: yup. i mean the newer version of minnowboard. http://www.pcper.com/category/tags/atom-e3825 Jan 07 16:06:06 that one has the same atom as i have here on my board. atom e3825 Jan 07 16:06:47 i actually managed to flash Lubuntu 14.04 on its emmc and it boots fine. but consumes most of the space out of its 4gb Jan 07 16:09:33 i like it that i can touch it and its not heated at all Jan 07 16:15:40 bluelightning: the boards i have here has BIOS on it. do you think i can try with yocto provided image and make it boot from usb to it? asking this question as i don't know how yocto plays with BIOS. Jan 07 16:16:33 * hitlin37 starts to fetch the meta-intel tree Jan 07 16:17:58 should i fetch daisy or the newer release dizzy Jan 07 16:18:37 * hitlin37 wonders why all the yocto releases starts with d Jan 07 16:23:59 bluelightning: I think I will create two recipes for the two packages then if strip cannot be set per on a package basis. Jan 07 16:24:12 using an .inc from both with require. Jan 07 16:24:31 it would be nice to support this from within one recipe in the future though. Jan 07 16:27:25 bluelightning: ha! grep -rn "already-stripped" ../meta/ -> empty output Jan 07 16:27:33 if i understand, yocto do a common release across both intel and arm. or it diffeers for each arch. Jan 07 16:28:35 lpapp: ah, right... I guess my memory was faulty, in dylan there was no way to turn off that warning Jan 07 16:32:14 bluelightning: :O Jan 07 16:32:34 bluelightning: so you also recommend two separate recipes or there is still a nicer way? Jan 07 16:32:47 (we cannot update dylan now as we need to focus on the release) Jan 07 16:33:15 you could patch in the ability to disable the warning, if you are happy to carry that patch Jan 07 16:33:33 that's probably the only way other than the solutions already discussed Jan 07 16:33:45 other than just ignoring the warning Jan 07 16:34:02 bluelightning: I am also getting an error due to this, remember. Jan 07 16:34:37 ok, so maybe I missed that, can you remind me of the error as opposed to the warning? Jan 07 16:35:39 bluelightning: it is trying to split already stripped binaries Jan 07 16:35:47 ERROR: QA Issue: non debug package contains .debug directory: ... Jan 07 16:36:10 (sorry, split = create .debug) Jan 07 16:37:18 lpapp: we talked about that, the solution is to reorder PACKAGES - have you tried that? Jan 07 16:38:51 zeddii: Are your patches somewhere? Jan 07 16:39:08 zeddii: I'd like to check what is there and what is still pending Jan 07 16:39:45 bluelightning: i tried the steps from the wiki for simple 32 bit image but got this error on first run of . IOError: file $HOME/source/meta-intel/conf/layer.conf not found in /home/test/source/poky/meta-yocto:/home/test/source/poky/build:/home/test/source/poky/meta:/home/test/source/poky/meta-yocto-bsp Jan 07 16:40:19 i mean first run of bitbake core-image-minimal Jan 07 16:41:36 hitlin37: you can't use $HOME in there I'm afraid, it needs to be a proper path Jan 07 16:46:39 bluelightning: I do not wish to have .debug for already stripped binaries since it feels pointless, no? Jan 07 16:47:05 so basically I wished to split and I was told that already-stripped would also split. Jan 07 16:48:42 lpapp: I'm afraid we don't currently offer anything to explicitly handle that mixed setup, certainly not in dylan Jan 07 16:49:28 bluelightning: thanks. that worked! building now Jan 07 16:50:53 bluelightning: two recipes or backport that is? Jan 07 17:00:10 lpapp: I'm not understanding the question - sorry can you rephrase? Jan 07 17:12:50 bluelightning: I see two solutions: 1) Backporting the already-stripped feature 2) Create two recipes and I can explicitly split in the "static" recipe in which the files are already stripped. Jan 07 17:18:16 lpapp: right, yes Jan 07 17:33:27 bah Jan 07 17:51:17 We are living under edge now rburton Jan 07 17:51:30 what is building now, may fail in 3min Jan 07 17:51:32 heehehe Jan 07 18:25:09 bluelightning: would it be difficult to backport already-stripped or just the matter of a couple lines? Jan 07 18:26:08 lpapp: AFAIR it was part of a refactoring effort so you may find it easier to implement that one thing from scratch, but it would probably be worth double-checking Jan 07 21:43:02 hello:) i would like to ask you for help. 1) I created bitbake core-image-sato 2) deployed .hddimg to USB using USB-ZIP method 3) booted Atom PC from usb -> "ramdisk not found". so i figured out that /dev/ram0 does not exist in rootfs and also i found out a thread that says CONFIG_BLK_DEV_RAM has to be set in .config file in poky linux-yocto. However, still when bitbaking core-image-sato there is no /dev/ram0 under rootfs. maybe there Jan 07 21:43:19 . Jan 07 21:43:33 to set CONFIG_BLK_DEV_RAM in? Jan 07 22:02:55 arcomivi, so you set CONFIG_BLK_DEV_RAM in an additional kernel fragment file ? Jan 07 22:05:55 arcomivi, it's better to use a fragment file than modifying files under tmp/work/ Jan 07 22:06:13 arcomivi, those changes will be lost when you bitbake clean/rebuild Jan 07 22:06:58 arcomivi, dunno about linux-yocto kernel, but you might wanna double-check that you have devtmpfs enabled in the kernel by the sounds of it Jan 07 22:10:31 no, i do not have a fragment config/kernel file. I am using standard from linux-yocto build, at least i think this is used. Jan 07 22:11:30 devtmpfs - did not look into this again. At least i would not know that this is enabled. Jan 07 22:12:33 CONFIG_DEVTMPFS is enabled under .config in linux-yocto Jan 07 22:14:36 so what would be the best way to create a fragment file? an bbappend under poky/meta/recipes-kernel/linux ? Jan 07 22:16:03 arcomivi, yeah, via a .bbappend file, in preferrably in a layer that you create yourself Jan 07 22:16:08 arcomivi, http://www.yoctoproject.org/docs/1.7/kernel-dev/kernel-dev.html Jan 07 22:16:21 arcomivi, "2.2.3. Changing the Configuration" Jan 07 22:17:37 yep, already saw this, but actually did not want to use this. I thought a standard would work, but no problem, i will try this option. Is anything else known not working straight forward when booting from USB? Jan 07 22:18:49 arcomivi, I don't use the Atom, so I'm of no help there Jan 07 22:19:51 ok, thank you anyways, i will try to proceed ;) Jan 07 22:20:18 arcomivi, no problem, good luck Jan 07 22:22:05 kroon, thank you! i will need it **** ENDING LOGGING AT Thu Jan 08 02:59:59 2015