**** BEGIN LOGGING AT Thu Dec 29 03:00:00 2016 Dec 29 14:07:08 Hi, I'm using poky/morty, added my own meta-layer where my machine config resides. Now I would like to create an initramfs. I found "initramfs-boot" and would like to make use of it. How to do that :) ? Dec 29 14:12:48 What I want is an additional initramfs file which gets bundled to the fit-image... Dec 29 14:15:59 kalpu: initramfs as in a rootfs image that is used to pivot to the full rootfs (after kernel boot) or initramfs as in you just want to package your rootfs as an "initramfs"? Dec 29 14:17:49 kalpu: also regarding bundling, do you want to bundle the rootfs into the fitimage or into the kernel blob? Dec 29 14:19:11 nrossi: I just want to boot into a pretty small initramfs where I can do maintenance stuff. If I boot into this initramfs, I'll be able to decide by u-boot kernel-cmd-flags. Dec 29 14:20:12 kalpu: If you have specific requirements for packages/etc. in this maintenance rootfs, then best bet is to make a custom rootfs which packs what your need. Dec 29 14:20:35 kalpu: because you want to use the same kernel, bundling the initramfs into the fitimage is likely a better option Dec 29 14:21:42 how to make another custom rootfs (as initramfs) and pack it automagically into my current fit image? Dec 29 14:22:21 Oh, busybox and wpa-supplicant would be enough... Dec 29 14:22:31 kalpu: exactly ;) Dec 29 14:22:37 kalpu: Getting some links for you :) Dec 29 14:22:50 cool :-) Dec 29 14:25:22 kalpu: So assuming you are familar with creating a custom image recipe, you need to set INITRAMFS_IMAGE = "" (http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#var-INITRAMFS_IMAGE) Dec 29 14:26:33 kalpu: To generate a fitimage, you will need to set your KERNEL_IMAGETYPE = "fitImage". (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-fitimage.bbclass for more specifics) Dec 29 14:28:07 also set "KERNEL_CLASSES += "kernel-fitimage" where you are setting the imagetype, so that you bring in the fitimage class. Dec 29 14:28:45 But isn't this a bit redundant, because I already have a setup for my big rootfs. And there is recipie called initramfs-boot which just starts a shell. Dec 29 14:28:50 kalpu: then "bitbake " should be sufficent Dec 29 14:29:16 kalpu: sure you could just use that image (if its an image), Dec 29 14:29:31 ah, okay, so this can reside in the same machine config? Dec 29 14:29:51 but that recipe is intended to be used in a live-cd boot flow Dec 29 14:30:01 kalpu: yep same machine config Dec 29 14:30:17 okay, cool :-) I'll try that! THANKS!!! Dec 29 14:42:37 hya everybody, I am pretty new to BitBake, is there any option which makes bitbake to output the gcc/make output on stdout ? Dec 29 14:53:59 pedr0_: if your feeling really keen "-v" does output that. But i think what you are probably after is the log.* files in "tmp-glibc/work////temp/log.*" Dec 29 14:55:01 I am trying to build a package which uses autotools Dec 29 14:55:07 -vv tells me : Dec 29 14:55:08 + [ -e Makefile -o -e makefile -o -e GNUmakefile ] + bbnote nothing to compile Dec 29 14:55:56 pedr0_: dive into the work dir manual or via -c devshell and poke around :) Dec 29 14:56:09 what is -c devshell Dec 29 14:56:10 ? Dec 29 14:56:19 "bitbake -c devshell" Dec 29 14:57:16 it can't open the display (I am over SSH) is there any option to have it working anyway ? :-) Dec 29 14:57:49 tmux? Dec 29 14:58:05 or you can just cd down into the directory Dec 29 15:05:57 if I want to modify the meta-platform/recipes-kernel/linux/linux_4.7.bb, I should use devtool edit-recipe linux to do that? Dec 29 15:08:29 I do not have an X11 display as I am connected to SSH, fixed by enabling x11 forwarding .. let us see how difficult it gets now :) Dec 29 15:13:11 pedr0_: sounds like your S variable isn't set to the correct path for the sources, so no makefile exists. also obviously make sure you inherit autotools Dec 29 15:16:15 but does it sound right to you that I have to set S=${WORKDIR}/namefolder where namefolder is the folder's name of the unpacket tar.gz ? Dec 29 15:19:37 I am in the front of the devshell ... but I can't fathom how to use it Dec 29 15:20:19 it's not that complicated. devshell opens a shell inside S. that's it Dec 29 15:20:26 it isn't magic. ls to see what files are in the source tree Dec 29 15:20:39 wow, there are none Dec 29 15:20:47 that sounds like a problem Dec 29 15:20:50 so ls .., to see what's in WORKDIR instead of S Dec 29 15:20:57 as nrossi said, look around Dec 29 15:21:06 do I need to build BEFORE running devshell Dec 29 15:21:08 ? Dec 29 15:21:19 devshell runs after fetch, unpack, and patch Dec 29 15:22:02 oks, I've definitely discovered a problem, there is nothing in there Dec 29 15:22:05 thanks Dec 29 15:22:32 make sure the tarball has what you expect, make sure the tarball url/path is correct in SRC_URI, etc. Dec 29 15:22:33 np Dec 29 15:23:24 it is a local one (SRC_URI = "file://ooc-1.3b.tar.gz) Dec 29 15:27:06 hi everyone. i'm trying out yocto for the first time and following the beginners guide, but when i run bitbake, it gets stuck on parsing recipes (at 51%) - well at least i'm assuming it got stuck, unless this should take an eternity^^ Dec 29 15:27:45 i'm using a vagrant vm as a build system (on macosx), with the build dir on the host system via nfs, and the tmp dir in tmpfs Dec 29 15:30:05 peacememories: i don't know if thhat's your problem, but build dir over nfs is going to be..... veeeeeery painfull Dec 29 15:30:32 I had the same problem ... but I do not remember what the solution was .. at least exactly Dec 29 15:31:13 does it output anything at all ? Dec 29 15:33:53 no, it just shows the progress bar Dec 29 15:33:58 any logs i can check? Dec 29 15:34:12 (just a sec, switching to an actual irc client^^) Dec 29 15:35:33 well no then, I apologize I had a different problem as in my case it did not print anything on the screen altogether Dec 29 15:35:46 thanks anyways :) Dec 29 15:38:10 there's apparently lo logs created Dec 29 15:40:41 peacememories: use ps or top, see if the bitbake or it's worker processes are alive and or doing something. Dec 29 15:41:28 bitbake is still running, but using next to no cpu time Dec 29 15:41:54 cooker's using a lot of memory, but not much else Dec 29 15:42:03 well "a lot of" Dec 29 15:42:13 well you could try to strace it to see what it is up to Dec 29 15:42:43 or use a python debugger .... Dec 29 15:43:37 there is the option -DDD - that would generate an awful lot of info but it might give you an hint of where it is Dec 29 15:43:45 bitbake -DDD <..> Dec 29 15:43:55 peacememories: oh just a quick check your tmpfs, how big is it set to be and how full is it? Dec 29 15:45:08 the tmp dir is 40kb big at the moment. also, i was wrong before, it's not on a tmpfs, but on the vm disk, which is 40gb in size Dec 29 15:45:37 (i keep mixing up which linux distros use tmpfs for /tmp and which don't^^) Dec 29 15:46:10 peacememories: /tmp is normally not a tmpfs on desktop distros Dec 29 15:46:34 used arch for a long while^^ Dec 29 15:46:44 peacememories: I would recommend just trying to build using only the local VM disk. If that works then NFS is the issue Dec 29 15:47:07 i can try that too. will need more than about 40gb of space though, right? Dec 29 15:47:35 interesting too: sending sigint doesn't cleanly shut down bitbake Dec 29 15:47:50 `timeout while attempting to communicate with bitbake server` Dec 29 15:48:06 peacememories: You can use rm_work to avoid needing large amounts of space Dec 29 15:48:38 rm_work? Dec 29 15:49:21 add INHERIT += "rm_work" Dec 29 15:49:35 to your build/conf/local.conf Dec 29 15:49:51 look for rm_work here : https://www.yoctoproject.org/docs/1.8/yocto-project-qs/yocto-project-qs.html Dec 29 15:50:47 40GB it is not a lot though - it really depends what you are doing, I am experimenting with a pocky and my df tells : Dec 29 15:51:01 /dev/sda1 226G 134G 82G 63% / Dec 29 15:51:19 that is a container where I am just doing the Yocto stuff Dec 29 15:51:47 (134G it's what is used) Dec 29 15:53:25 I am debugging my autotools issue - I have made some progress as the bb tool now find the tarball, extracts it fine and moves on in building it Dec 29 15:53:40 What to do to add a custom initramfs to a fitimage? Dec 29 15:54:00 I already create the fitimage in a machine-config Dec 29 15:54:37 Let me rephrase my question: What to do to add a custom initramfs to a already existant fitImage that gets created in a machine-config-file? Dec 29 15:56:31 I can see the content of my tarball with ls in the devshell (no path change needed) - it fails to compile though as it jumps in a directory named "build" inside my recipe's folder <..>/build/tmp/work/i586-poky-linux/ooc/1.0-r0/build - such folder looks different from the original tarball Dec 29 15:56:57 by default autotools will use a separate source vs build directory Dec 29 15:57:06 if your project doesn't support that, you can inherit autotools-brokensep Dec 29 15:57:12 though better yet would be to fix it to support it instead Dec 29 15:57:39 yeah, but I do not own this code, let me try with yout fix first Dec 29 15:58:00 kalpu: If you set INITRAMFS_IMAGE, you should get two fitimage files in your images dir, one with the initramfs and one without Dec 29 15:59:09 it works now, thanks a LOT Dec 29 16:00:13 such recipe generates a library (static) to be used by another tool, would you know a recipe example that tries to do the same ? Dec 29 16:00:24 hmm, building directly in the vm still hangs Dec 29 16:00:53 nrossi: So I get a fitImage which consist of Kernel+DeviceTree+InitramFS ? Dec 29 16:01:21 kalpu: yep, but also one which is just kernel+devicetree Dec 29 16:01:29 ah, okay, cool Dec 29 16:01:45 kalpu: The one with the initramfs will have the value of "INITRAMFS_IMAGE" in its name Dec 29 16:05:31 sorry:uch recipe generates a library (static) to be used by another RECIPE, is there any example I can follow ? I basically need to use the .a file generated from my recipe for another C program I wrote, which is under another recipe Dec 29 16:06:39 install it where you'd normally install such a library (${libdir} under ${D}) and reference it with -l as usual Dec 29 16:06:47 and of course make the second recipe DEPENDS on the first Dec 29 16:07:34 okay, reading the manual thoroughly definitely helps^^ i had to switch the package manager to deb-based, now i'm at least on 53%^^ Dec 29 16:08:33 would that result in the static library being part of the final generated image ? I guess not Dec 29 16:08:49 kergoth: do you know if there is a particular reason for deactivating do_fetch & co in image.bbclass ? downloading a file to override in the rootfs sounds like a common usage pattern to me... Dec 29 16:08:51 pedr0_: no, not unless you add the -staticdev package of the first recipe to your image manually Dec 29 16:08:53 I do not want the image to contain the static library Dec 29 16:08:57 oks Dec 29 16:09:00 cheers Dec 29 16:09:22 boucman_work: I think I've had to do it once or twice in the past 10 years :) but yeah, it's certainly a valid thing to do. you could certainly drop the noexecs in the recipe Dec 29 16:09:40 peacememories: fair warning, the deb/dpkg support doesn't get near the attention and testing that opkg & rpm get Dec 29 16:09:51 should still work, just keep it in mind Dec 29 16:10:25 kergoth thanks for the warning :) i could switch to a fedora vm or something i guess. right now i'm stuck on 53% though^^' Dec 29 16:10:27 kergoth: ok, someone will probably submit a patch soon (not me, i'm training someone on "how to contribute" :P ) Dec 29 16:11:03 kergoth: I have a lot of "no user" use-cases : nobody to tweak config files after the fact, everything needs to be done at image-build time Dec 29 16:11:03 boucman_work: you should be able to undo it in the image itself if need be, on a per-image basis, no? Dec 29 16:11:14 * kergoth nods Dec 29 16:11:19 and since there are some per-images variants, I can't do that in packages Dec 29 16:11:28 peacememories: ah, you meant the host. that shouldn't be too relevant Dec 29 16:11:31 * kergoth nods Dec 29 16:12:03 kergoth: yes, but that sounds like a generic enough use-case that I think it should be activated by default (I don't really understand why it was deactivated in the first place) Dec 29 16:12:58 probably just an optimization, no point running tasks that do nothing, i.e. configure/compile were noexec'd too, but this does sound like a use case we should support, particularly if the reasoning was just an optimization Dec 29 16:13:39 how do I concatenate two variables in bb ? Z="${A}""${B}" <- does it look correct ? Dec 29 16:13:58 morning Dec 29 16:14:06 kergoth: a follow up patch would be a way to easily provide an overlay-type source and automatically apply it to the image, but that one would have to be explicitely enabled. Dec 29 16:14:12 pedr0_: no Dec 29 16:14:17 pedr0_: "${A}${B}" Dec 29 16:14:18 done Dec 29 16:14:27 bitbake doesn't care how many variables you reference Dec 29 16:14:38 the quoting is for Z, not for A and B Dec 29 16:14:51 to put it another way, you don't quote references, but variable definitions Dec 29 16:14:56 Z = "${A}${B}" is fine Dec 29 16:15:15 see also the bitbake manual, it covers the syntax Dec 29 16:16:10 it looks like nano moved to a git server and now I'm having problems building Dec 29 16:19:55 I tried to modify the nano.inc file to reflect the changes but I'm still new to Yocto so it would failed on do_configure Dec 29 16:20:37 we'd need more info to assist, can you put the do_configure log on a pastebin? Dec 29 16:21:50 I just flushed everything to start all over so the log file is gone Dec 29 16:22:26 the build worked a few days ago, then it seems nano moved it's repo to git Dec 29 16:22:31 from ftp Dec 29 16:22:56 sorry to keep bothering - I am doing okay with the static lib (${D}/{libdir}) what's the right place for the header files ? Dec 29 16:25:05 ... I wonder .. in my desktop system I haven't done anything more than typing 'make install', is it possible to achieve the same effect ? I am a bit worried that doing it by hand (coping files on the {libdir} etc etc would cause some mistake as I am could forget to copy sth Dec 29 16:26:36 it already does that by default Dec 29 16:26:46 autotools.bbclass defines a do_install that runs make install with DESTDIR set to ${D} Dec 29 16:29:16 I was following these directions https://boundarydevices.com/morty-yocto-release/ Dec 29 16:30:32 again, that doesn't really tell us a whole lot. when you have a problem, people need exact error messages and logs, not summaries Dec 29 16:32:27 I'm rebuilding now to get that to you. BUT the recipe in morty/sources/meta-openembedded/meta-oe/recipes-support/nano looks for and FTP site that does not exist anymore Dec 29 16:33:48 it moved to git https://www.nano-editor.org/git.php Dec 29 16:34:39 yes, you've said that repeatedly. i don't really see the problem. yocto provides mirrors to pull from the tarball from, and i'm sure master will move to git if it hasn't already Dec 29 16:34:51 okay, i fixed the problem with parsing (it was too little ram) Dec 29 16:35:02 peacememories: ah! interesting Dec 29 16:35:13 buut i've go different problems now^^ Dec 29 16:35:47 bitbake complains about `free inode is running low` Dec 29 16:37:00 okay, that's apparently because the shared virtualbox fs doesn't have enough inodes Dec 29 16:48:20 this could be somewhat self inflicted. open embedded was down for over a day so the mirror would have been down too **** BEGIN LOGGING AT Thu Dec 29 16:57:07 2016 Dec 29 17:00:44 peacememories: quick google.. says no. you would need to recompile the kernel module. Dec 29 17:01:01 okay, thanks Dec 29 17:01:15 most likely that check is from bitbake, in which case yes, i't sjust a variable. Dec 29 17:02:37 search the bitbake manual for BB_DISKMON_DIRS for reference, or just look in conf/local.conf, as most likely your distro's local.conf.sample is what's setting it in the first place Dec 29 17:02:52 so I shouldn't need to manually copy the static library by hand using install -m 0755 ${S}/libs/libooc.a ${D}${libdir}/ Dec 29 17:02:56 in my do_install Dec 29 17:02:57 i.e. BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" that 100K is inodes, the 1G is free space Dec 29 17:03:04 pedr0_: assuming it's an automake based project, no Dec 29 17:04:09 peacememories: kergoth: looks like there is a stackoverflow about this exact issue : http://superuser.com/questions/999830/virtualbox-shared-folder-has-insufficient-inodes Dec 29 17:04:50 nrossi: yes, if you read the entirety of the question: Modifying the config file to change the panic thresholds seems to have worked. There are actually two levels of checking. A "STOP" level and an "ABORT" level. By default "STOP" is set to 100,000 inodes. Changing both STOP and ABORT to 999 inodes allows the build to proceed, but I'm not sure if it will cause other problems down the road. Dec 29 17:04:54 which references what i just said Dec 29 17:05:00 * kergoth shrugs Dec 29 17:05:24 afk Dec 29 17:06:28 oks, the makefile I have defined uses LDFLAGS, but I can't find it in the compiler command Dec 29 17:06:32 I read your reply and saw the note you mention, but just incase i posted that link. Sorry if i confused anyone :| Dec 29 17:06:54 I meant : makefile says LDFLAGS += -looc [..] $(CC) -o $@ $^ -g $(LDFLAGS) Dec 29 17:07:03 but I do not see the -looc in the command line output Dec 29 17:07:09 and in fact it fails to link Dec 29 17:07:33 is there anything I need to pass to the oe_runmake command in my recipe ? Dec 29 17:11:31 okay, it's not aborting now. thanks a lot :) **** BEGIN LOGGING AT Thu Dec 29 18:01:37 2016 Dec 29 18:11:29 Question: if I'm following https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F, what can I do for my custom recipes that fetch their code from git repos on bitbucket or github? Dec 29 18:11:55 I've got checkout directories in the downloads dir already, but I don't understand how to get the build process to use the local mirror instead of trying to clone across the network. Dec 29 18:14:00 the clones have to be in the correct location in downloads with the correct names, and the repos have to be bare Dec 29 18:14:09 if you want to use a local checkout/clone, see the documentation on the externalsrc class Dec 29 18:16:43 exit Dec 29 18:20:10 bare repos? Dec 29 18:20:16 Ah, meaning with no .git in them. Dec 29 18:20:21 I'll look at that documentation. Dec 29 18:21:05 the downloads dir used as DL_DIR by bitbake has a specific format. Dec 29 18:21:12 particularly for SCM repositories Dec 29 18:21:21 adding stuff there manually is unlikely to do what you want Dec 29 19:48:37 kergoth: so to be clear, if I want to use cached clones of git repos for recipes, I have to rewrite the recipes to treat the clones as external source rather than using bitbake's normal build process (via cmake, as I actually do)? Dec 29 19:51:39 your best bet is to populate your local mirror using the contents of an existing bitbake DL_DIR. don't try to clone it yourself externally Dec 29 19:51:54 if you do, you have to do so with —bare and make sure the name and path are correct Dec 29 19:52:05 but it really depends on your requirements Dec 29 19:54:33 that said, there's no need to rewrite anything, you can use a bbappend to do it, in your own local layer, if you do want to use externalsrc. that's how 'devtool modify' works Dec 29 19:54:48 but again, depends on the use case. are you doing active development, populating a mirror site, or..? Dec 29 20:17:42 Any meta-intel folk around? Dec 29 20:18:49 Basically, I've got some projects that our client develops, and which they're having us integrate into a Yocto build for them. Dec 29 20:19:03 They want to be able to mirror everything on a machine and build from there, without the network. Dec 29 20:19:23 They also keep their own sources for these projects on a git repo. Dec 29 20:19:30 I've written Yocto recipes that integrate them. Dec 29 20:20:40 could you not just use PREMIRRORS to fetch from those git uris, rather than trying to mess with the contents of DL_DIR? Dec 29 20:39:30 oh, that looks like exactly what I need! Dec 29 20:39:32 let me try that out. Dec 29 21:05:58 Hmmm. I tried setting BB_FETCH_PREMIRRORONLY="1" in conf/local.conf, and I also set up the PREMIRRORS_prepend with the file:// URI to my local clone. I get the same complaint about network access being disabled as I did before when I actually build, though. Dec 29 21:06:30 check the do_fetch log Dec 29 21:06:41 and make sure the PREMIRRORS syntax is correct Dec 29 21:06:47 for example, using file:// is wrong Dec 29 21:06:56 that will result in using cp or wget, not git Dec 29 21:07:14 instead,k you should use git:// with ;protocol=file, which will pass the file:// uri to git, but use bitbake's git fetcher rather than the file fetcher Dec 29 21:07:18 give that a try, if you would Dec 29 21:07:38 but should still verify the mirror is being applied correctly by examining the urls checked in do_fetch Dec 29 21:12:29 hmmm, I *was* doing that wrong, but let's see if it helps. Dec 29 21:12:46 no, the git commands composed by do_fetch still seem to refer to the original git server. Dec 29 21:13:03 ssh://git@bitbucket.org/$CLIENT/$PROJECT.git Dec 29 21:21:49 kergoth, rather than quizzing you, let me google for a bit. Dec 29 21:25:23 PREMIRRORS and MIRRORS aren't a single regex, they're a url constructed of multiple regexes Dec 29 21:25:45 that is, the url is first split into its components, and then it does the search/replace on each component that exists, individually Dec 29 22:09:51 right, I have 'PREMIRRORS = "git://.*/.* git:///home/esennesh/$CLIENT/repos;protocol=file \n "' Dec 29 22:10:07 Which should catch git urls, correct? Dec 29 22:12:01 $CLIENT is unlikely to do anything at all. Dec 29 22:12:06 that's a shell variable reference, not a bitbake one Dec 29 22:17:10 nono, that's actually metasyntactic, to refer to me blanking out the name of our client for this conversation. Dec 29 22:30:29 ahh, right :) Dec 29 22:31:19 i worry that might actually replace the entirety of the path, including the name of the repository. you might have to adjust the search/replace to grab the last part and replace it back with \1, or replace with PATH (special replacement keyword that includes the path component Dec 29 22:31:27 you should be able to see exactly what was returned from the search/replace in the do_fetch log, though Dec 29 22:31:29 which should be informative Dec 29 22:31:34 see the 'returning' lines **** ENDING LOGGING AT Fri Dec 30 03:00:00 2016