**** BEGIN LOGGING AT Tue May 05 02:59:59 2015 May 05 05:45:02 hi guys May 05 05:49:59 I'm trying to build images for several machines. Each of the machine inherits from intel-core2-32 machine definition. I'd like to override the default /etc/network/interfaces file. May 05 05:50:26 What I did is I created my machines.conf inside my meta-drix/conf/machines/ May 05 05:51:25 Then, inside the meta-drix/recipes-cores I created a init-ifupdown directory, that contains : May 05 05:51:38 - init-ifupdown_1.0.bbappend May 05 05:52:05 - all the machines/files/interfaces tree. May 05 05:52:12 But it's not working :( May 05 05:56:14 drix: you need to create a bbappend for init-ifupdown, which just adds your directory to the FILESEXTRAPATHS May 05 05:57:13 yes, that's what I did, here is the content : May 05 05:57:15 FILESEXTRAPATHS_prepend := "${THISDIR}/${MACHINE}/files:" May 05 05:57:45 oh you are doing it in reverse... you should just have "files//content" May 05 05:57:57 then your prepend can just be "${THISDIR}/files:" May 05 05:58:22 and that will let bitbake handle the priority based on the overrides May 05 05:59:44 oh, thanks, i'll try this. May 05 06:00:34 http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/recipes-core/init-ifupdown May 05 06:00:46 thats an example of how you should do it ;) May 05 06:01:52 Thanks, May 05 06:02:05 thus, I need to use the base package name of the machine name ? May 05 06:02:51 oh you dont need to use "BPN", "files" is fine. the meta-intel layer uses files: http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/meta-fri2/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend?h=master May 05 06:02:58 BPN = Binary Package Name May 05 06:03:59 Alright, thanks. I'll try with files. May 05 06:04:21 actually, its "Bare Package Name"... silly me.. :P http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html#var-BPN May 05 06:13:49 Thanks, another question, May 05 06:15:16 as I'm a newbie on yocto, (but quite resourceful :p), can you tell me what's the most important parts I have to read in the bitbake & yocto mega manual ? I don't know where to start, and I'd like to understand all the principles instead of asking google each time I have an issue May 05 06:16:10 As you know, those manuals are huge! May 05 06:16:15 drix: Hmmm i am not sure on good materials. I learnt by playing with things. May 05 06:16:24 drix, read the source then, or go by the examples May 05 06:17:02 drix, I agree, the manual needs to be cut down, but from what I've seen the manual doesn't cover half of the stuff thats in there May 05 06:17:31 That's what i'm doing! But sometimes, I'm trying to do some things, and I'm quite sure there are better practices :p May 05 06:17:54 Yes, and I'm not enough brave to read the whole thing May 05 06:18:31 drix: i'd suggest to drop the bitbake and mega manual, and just go for the yocto dev manual. May 05 06:18:33 drix, unfortunately, the best practices are slowly evolving, most likely there will be a refactor of bitbake/yocto one day, but for now you just have to swim with it May 05 06:18:44 drix: some of the other layers might already do what you are trying to do, its always a good idea to have a peek at them. The easiest way is to look by recipe/etc have a look on layers.openembedded.org May 05 06:19:02 drix: it should contain the vast majority of what you need to actually use the whole thing May 05 06:19:49 drix, but if you have the time, you could be the catalyst for change, and refactor the build to correlate to the manual May 05 06:20:50 It's perhaps too early for that May 05 06:21:36 drix, not really, you sound like you understand the basics, the only problem is that there is a lot of legacy shit thats undocumented May 05 06:21:50 nrossi: That's what I'm doing, openembedded meta is very interesting May 05 06:22:06 LetoThe2nd: Thanks! May 05 06:22:27 drix: yw May 05 06:23:42 redengin: to be honest I'm using yocto for a week... I guess it's a good start. May 05 06:24:51 drix, as you get into it, you'll find out it easy to start from bitbake and make a sensible set of build recipes without the legacy hacks May 05 06:25:49 it all depends on how much time you have to customize your OS May 05 06:26:31 btw, anyone here done an ipad digitizer replacement (broken glass)? May 05 06:36:04 nrossi: it works, my /etc/network/interfaces has been correctly overriden, thanks! May 05 06:38:37 congrats May 05 08:25:55 morning all May 05 11:25:36 hello everyone May 05 11:26:11 need help for fixing a bug May 05 11:26:15 Required build target 'core-image-minimal' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-minimal', 'syslinux'] May 05 11:26:56 i get it while building core-image-minimal for a imx53qsd May 05 11:28:42 khalebios: sounds like the layer you use for board support is buggy, arm boards usually don'T bring syslinux May 05 11:29:09 ka6sox: and core-image-minimal certainly has no direct dependency on syslinux, i build it all the time without. May 05 11:29:19 khalebios: ^^^^^^^ May 05 11:29:22 ka6sox: sry May 05 11:30:40 khalebios: did you follow https://community.freescale.com/docs/DOC-1616#jive_content_id_iMX53_QSB__Quick_Start_Board May 05 11:31:49 i am trying to build with hob. i choose imx5qsb as machine May 05 11:32:01 yes i follow it May 05 11:32:22 thats contradictory... you say hob, but hob is mentioned there nowhere May 05 11:32:46 generally i'd suggest to stay away from hob. i've never gotten anything good out of it. May 05 11:33:58 oooh sorry. but i just start using it. May 05 11:34:12 I thought it's work like bitbake May 05 11:34:55 nope, hob is just gui frontend, and unfortunately one that doesn'T work too well. May 05 11:35:11 better do things manually, on the CLI May 05 11:39:46 ok. so i am retrying with bitbake May 05 11:41:57 khalebios: you have always beenusing bitbake, hob is just a gui that calls bitbake ;) May 05 14:56:59 YPTM: Ready-Access Number: 8007302996 Access Code: 2705751 May 05 14:57:44 YPTM: Stephen Joined May 05 14:58:00 YPTM: armin is on May 05 15:00:33 YPTM: Jussi Kukkonen joined May 05 15:02:38 hi Sona joined May 05 15:02:42 YPTM: Michael here. May 05 15:02:47 YPTM: Mark is here May 05 15:02:48 YPTM: Richard joined May 05 15:03:10 YPTM: Denys is joining May 05 15:03:21 AlexV. joined May 05 15:03:49 Saul joined May 05 15:03:53 YPTM AlexV. joined May 05 15:04:07 YPTM: cristian joined May 05 15:04:14 * fray still has an action to enter a few of my requests to bugzilla still May 05 15:11:41 YPTM is over May 05 15:12:58 could someone fix flashing yocto..i hate this freescale MFGTOOL. it keeps coming back with its ugly set of files to flash. May 05 15:14:31 hitlin37: hehe, better fix fsc then ;) May 05 15:15:01 fsc? May 05 15:16:49 hitlin37: the "flashing" process that you complained about is freescale-specific ;) May 05 15:39:09 Is there a way to continue to use the 'quilt' workflow with a "yocto-fied" kernel recipe? When I devshell into the kernel sources 'quilt' is no longer set up with the patches. I'd like to continue to use quilt to modify/refresh patches that have been applied to the kernel. Is this possible with the yocto workflow. It works quite nicely with non-kernel recipes. May 05 15:39:28 hmmm May 05 15:42:11 It seems the yocto-kernel help script allows you to add/remove a kernel patch . . . but not modify one. So it appears the that the workflows assume any patch you apply is perfect and does not require modification. May 05 15:42:59 Glenn__: I could be wrong and zeddii may correct me, but I think the assumption is that you'd be using git to work on patches to the kernel May 05 15:43:29 if you're doing anything beyond just applying someone else's "finished" patches, that is May 05 15:44:08 yeah, quilt? why would you want to do that? May 05 15:45:08 I mean I am ok with the quilt _workflow_ and I'll use git to apply a quilt stack of "git format-patch" outputs, but it will be a cold day in hell before I actually use quilt itself again. May 05 15:45:09 Unfortunately, I'm developing patches against what's been pulled from a standard kernel. I don't have a seperate (external to yocto) kernel tree. I wanted to be able to tweak my patches within the devshell. May 05 15:45:53 still not sure I follow what you are trying to do... May 05 15:46:13 I guess my experience with quilt hasn't been so bad ;-( The TI staging kernels don't appear to be fully "yocto-fied" yet and still support my quilt workflow. May 05 15:46:39 but, what do you have in your quilt queue? May 05 15:47:08 are they really raw patch chunks, or are they proper commits with commit logs etc? May 05 15:48:25 Basically, I have some third-party patches (their origin lost). I apply these patches to a Yocto'fied kernel using the usual SRC_URI approach. Patches apply but build fails. I want to dev-shell in, tweak/refresh the patch, and then try again. May 05 15:48:41 They are raw patch chunks. May 05 15:50:34 ok, even then you can trivially git-ify them ; in the kernel you really don't want to be leaving uncommitted changes floating around. May 05 15:51:05 For the, the awkward work flow is the pull down the Linux kernel sources outside of yocto, apply my patches there, try to build it there, and once I get it to build correctly, use git to generate the patches which I then copy back into my yocto environment (or point Yocto at my separate kernel tree). May 05 15:52:17 e.g. to gitify a series manually -- for i in `cat series` ; do git apply $i ; git add -A ; git commit -m 'auto applied patch '$i ; done May 05 15:52:30 hi May 05 15:52:32 there is git quiltimport too IIRC. May 05 15:52:44 blueness: it seems that no could help me with the kernel issue on the mailing list. May 05 15:52:47 no one* May 05 15:54:53 These are one-off changes . . . I'm not too worried about uncommitted changes at this point. Just trying to quickly iterate on the patch without having my own git branch/repository. Just looking to patch on top of an existing one. Guess my Git-fu isn't as advanced as yours ;-) May 05 15:55:17 well, no time to learn like the present. :) May 05 15:55:40 once you have things applied, you can poke at the chunks with "rebase -i" May 05 15:56:06 want to scan over the last 10 patches and poke at some of them? May 05 15:56:13 git rebase -i HEAD~10 May 05 15:56:44 May 05 15:57:02 git add -u May 05 15:57:12 git commit --amend May 05 15:57:16 git rebase --continue May 05 15:57:23 that is basically it. May 05 15:58:46 once you get comfortable with stuff like that, you get to play with cool stuff like "git add --patch" --- which allows you to stage and commit select chunks of unstaged changes. May 05 15:59:00 you'll never go back to quilt. May 05 15:59:15 Yes, but wouldn't this be done outside the context of the devshell? I can do all this with my own git cloned kernel sources. I assume I'd have to modify the kernel recipe to use external sources (or pull from my private repo which likely would reside locally). May 05 15:59:46 can do git operations inside or outside the devshell. May 05 16:00:28 But my git operations would disappear once I do a "cleansstate" or "cleanall" right? May 05 16:01:10 Unless I was using my own repo and point the Yocto recipe at it. May 05 16:02:09 yeah, you can either use your own repo, or once you are happy with your patches, format-patch them back out and have them dynamically git-am'd by yocto on each new clean build. May 05 16:02:47 FWIW, this is why I've been pushing to get devtool / externalsrc working well for the kernel May 05 16:02:51 e.g. to capture your last 10 changes in a quilt like fashion... May 05 16:03:08 git format-patch -o mydir HEAD~10..HEAD May 05 16:03:16 cd mydir May 05 16:03:26 ls -1 |grep -v series > series May 05 16:03:29 better to learn the fundamentals .. than hack with a wrapper script. May 05 16:03:45 +1 May 05 16:04:54 anyone who spends even a fraction of their day being a patch monkey would be well served getting comfortable with rebase/format-patch etc. May 05 16:05:20 Okay . . . still not a Git guru . . . much to learn. For some reason at the devshell prompt Git says I'm in the middle of a rebase operation. I can't seem to complete it with git rebase --continue. Is this expected? May 05 16:06:11 depends on the exact case, what you did, what is in there, why exactly git cannot complete it, etc. May 05 16:06:35 try to check git diff May 05 16:06:36 zeddii: which wrapper script do you mean? May 05 16:06:42 yours :) May 05 16:07:14 and anyone elses. I'm just having fun with you :) May 05 16:07:19 I did nothing more than "bitbake my-linux-kernel -c devshell". May 05 16:07:34 Glenn__, what you are seeing is the build system trying to help limp along your raw patch that failed to apply IIRC. May 05 16:08:02 No, that patches apply cleanly. It's the module build that fails. May 05 16:08:29 show me exactly what "git status" shows in the devshell then, since I'm not sure what you are seeing. May 05 16:08:33 So I did a bitbake cleansstate followed by bitbake devshell. May 05 16:08:35 zeddii: it doesn't wrap this part of things at all though, once the tree is set up - the rest is up to you and git... May 05 16:08:46 pastebin if it is a sea of crap.... May 05 16:09:10 On branch linux-3.16.y You are currently rebasing. (all conflicts fixed: run "git rebase --continue") May 05 16:10:17 bluelightning: I did try some early versions you posted. I'll revisit. Like I said, I'm just having fun yanking random chains :) May 05 16:10:34 Glenn__, what does git status report when you drop into that devshell ? May 05 16:11:00 I just showed you: On branch linux-3.16.y You are currently rebasing. (all conflicts fixed: run "git rebase --continue") nothing to commit, working directory clean May 05 16:11:08 odd. May 05 16:11:15 Yes, truly. May 05 16:11:21 and you tried to continue and that failed? May 05 16:11:49 Glenn__, what is output of "ls .git/rebase-*' May 05 16:11:56 git rebase --continue Stray /home/gschmott/Projects/yocto/bbb-a2b-distro/build/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto-botic/3.16.1+gitAUTOINC+9a35988df6-r1/linux/.git/rebase-apply directory found. Use "git am --abort" to remove it. May 05 16:12:29 some patches, mostly if they don't have commit headers, have parts dumped in there to help fix and resolve. I wonder if when the queue is run that some last bits are left dangling. May 05 16:12:37 I did the git am --abort. May 05 16:12:59 yes, that should be fine, if there was some poo inadvertently left behind by something. May 05 16:13:08 It cleaned the directory. But I suspect it will re-appear after cleansstate/cleanall May 05 16:13:15 * zeddii nods. but I'd like to reproduce that here. May 05 16:13:40 * paulg checks a local build, but suspects status will be clean. May 05 16:14:18 Glenn__, let me try a couple of local patches. For now, if you do that git am --abort, you should be good to go with more git operations. May 05 16:14:44 okay . .. good to know. Thanks. May 05 16:17:23 Just confirmed it happens every time for me . . . my dumb luck. Guess I'll just have to git am --abort every time. Likely I'll have to redirect my recipe to use my own kernel repo outside the yocto 'work' directory. Seems like that's the preferred workflow for making kernel changes. May 05 16:17:50 Glenn__, that would be a bug. I'll try and reproduce it here. May 05 16:18:48 I'm on daisy (1.6, right?) if it helps May 05 16:19:00 to be clear, you can just quilt init and manage fixes on top of the git branches, but you still need to export them to your later and drop them in the SRC_URI to be applied later. May 05 16:19:10 which is the same if the entire queue was pushed with quilt. May 05 16:20:22 Just devshell and "quilt init". How does it know which patches were applied to the kernel. I see the ".meta" directory has a lot of that info. May 05 16:20:40 I was thinking of your own additions. May 05 16:21:03 so yah, it doesn't build a series for quilt, because the branches may not be pure patches, they may be merges, etc. May 05 16:21:38 there was an intermediate step from quilt -> guilt -> git for managing the queues. but guilt has the same issues with everything needing to be a particular type of patch. May 05 16:21:49 okay. well my additions are now buried in the .meta directory. I was hoping I could somehow point quilt at those and re-create the ".pc" file that quilt appears to be parsing. May 05 16:22:36 that's what I used to do with guilt, and eventually it catches flames. I have the scars to prove it :) May 05 16:23:18 Glenn__, but out of curiosity. I bet I could cobble something like that together again. I'll poke at that idea. May 05 16:24:21 Sounds like the path forward is to develop patches in your own external kernel repo and just point Yocto at it until your recipe is working and then redirect the SRC_URI to point to a non-local repo. May 05 16:24:58 I do all my work with a flow not unlike that. since doing anything serious with the patches, needs the full history and git-foo. May 05 16:25:22 That would be nice enough for me . . . if you did get something working it would save me some time. Can I assume quilt will continue to work with non-kernel recipes in the future for doing patches? May 05 16:25:57 yep. although there is a git patch mechanism as part of oe-core, so I suppose some might switch. May 05 16:26:29 * zeddii goes to hack on that idea while eating lunch! May 05 16:26:41 After all . . . GIT still is not universal . . . who is to say somebody might try to store their kernel in SVN ;-) May 05 16:27:14 hah. I have all the horror stories of svn, cvs, clearcase and mecurial, all with kernels shoved into them :) May 05 16:28:17 I'm sure . . . sometime corporate policy pushes version control into strange (dark) corners. May 05 16:45:08 halstead: ping May 05 17:08:07 back on my /etc/network/interfaces file issues. I can see the file overriden, but I'm not able to get the network working properly. I'm using systemd and I can see that networking.target is marked as dead. Does anyone got this issue ? May 05 17:20:43 I'm using the intel-core2-32 machine definition + the interfaces file override. That's it May 05 20:02:36 I need to version my builds and have that version number appear in a file within the image. The only way I can figure to do this is to use a Makefile, modify a recipe and a file, then launch 'bitbake Is there already a built-in mechanism to do this in Yocto? May 05 20:03:30 you could include your version in the DISTRO_VERSION, which already gets put in the rootfs, or you could just add a shell command to ROOTFS_POSTPROCESS_COMMAND if you dont mind the file being non-package-controlled May 05 20:03:40 I suppose, 'make release' for deployment and 'make test' for development. May 05 20:04:13 I think that the make process is the best bet May 05 20:04:42 you could just set a var in auto.conf from the shell, or use an env var with BB_ENV_EXTRAWHITE rather than modifying a recipe on demand May 05 20:05:15 yeah, and keep a hidden file with the last deployment release number. May 05 20:05:33 maybe not hidden, but you get the idea May 05 20:06:00 AndersD: ping May 05 20:06:14 env var is interesting, I'll check that out, thanks Ken May 05 20:07:15 if that was a name, it's not correct. if it's a nick reference, it's a typo :) May 05 20:07:27 kergoth: oops May 05 20:08:40 kergoth: sorry Chris May 05 20:08:43 heh May 05 20:08:52 np May 05 20:09:49 dorileo, ping May 05 20:09:56 AndersD: I saw your comment on bruno's patch "systemd: split modules into packages", do you mean you want to add PACKAGECONFIG just for the "new options"? and leave the old default config not as a PACKAGECONFIG opt? May 05 20:11:04 otavio: have you seen the bruno's patch last version? May 05 20:11:28 I mean the last version of bruno's patch May 05 20:11:43 Sorry if I wasn't being clear... No, I'm certainly for creating PACKAGECONFIG[xxx]="..." for both new and old features. May 05 20:12:06 dorileo: I didn't review it yet May 05 20:12:07 What I'm against is adding lots of things to DISTRO_FEATURES. May 05 20:12:20 otavio: ok, no problem... May 05 20:12:49 AndersD: ok, but, what if I want a distro with just the very minimal of systemd? May 05 20:13:04 AndersD: how can we change it to make it possible? May 05 20:13:21 When you enable the different PACKAGECONFIGS, using PACKAGECONFIG += "xxx yyy" you should make sure that you mimick the existing configuration. May 05 20:14:08 Only use @{bb.contains("DISTRO_FEATURES",....) for /big/ things, most likely things that already are DISTRO_FEATURES. May 05 20:15:09 If I want to have a different set of PACKAGECONFIGS enabled in my own distro, I add a bbappend to systemd, settig PCAKAGECONFIG="..." to whichever options I want to have enabled. May 05 20:15:31 AndersD: so, with that we should for example add PACKAGECONFIG_pn-system = "" to distros for example, is that what you mean? May 05 20:16:16 actually PACKAGECONFIG_systemd = "" etc May 05 20:16:24 AndersD: is that right? May 05 20:16:55 No, keep a PACKAGECONFIG="..." in the systemd recipe that's more or less equal to what it is today. May 05 20:17:41 If we want to change this in our own distros, then yes, either add PACKAGECONFIG_pn-systemd in your distro.conf, or add a bbappend in your distro layer. May 05 20:17:45 AndersD: ok, I agree with that, and for the new stuffs we do the PACKAGECONFIG stuff on distro side, right? May 05 20:18:36 Yes, if you want it enabled. Sure, there might be some new features that we want to enable per default, but such changes should be discussed on the mailing list. May 05 20:18:54 AndersD: looks fair to me... May 05 20:19:32 So in essence, for most of the new features, add the PACKAGECONFIG[feature] definitions to the systemd recipe, but do not activate them. May 05 20:19:58 right May 05 20:19:59 Good! With that change, I think we'll be ready for a merge, or at least /very/ close to it. May 05 20:20:20 AndersD: nice, thanks for clarifying and reviewing.... May 05 20:20:29 And I look forward to that. (I want this split in my own builds...) May 05 22:05:16 RP: the strip failure is coming from gcc-cross May 05 22:05:33 RP: gcc-cross/4.8.4-r0/temp/log.do_populate_sysroot.7211:ERROR: runstrip: ''strip' --remove-section=.comment --remove-section=.note --strip-unneeded --remove-section=.pdr '/home/ubuntu/work/daisy/build-pacexi3v2/tmp/work/mips32el-rdk-linux/gcc-cross/4.8.4-r0/sysroot-destdir/home/ubuntu/work/daisy/build-pacexi3v2/tmp/sysroots/x86_64-linux/usr/include/gcc-build-internal-mips32el-rdk-linux/mipsel-rdk-linux/libgcc/libgcc_s.so.1'' strip command failed May 05 22:06:02 the reason is that host version of strip is trying to run over target ( mips ) binaries May 05 22:06:37 this is that hack of stashing the contents from one recipe to be retrieved as part of another recipe thing May 05 22:53:41 zeddii: pingii ? **** ENDING LOGGING AT Wed May 06 02:59:58 2015