**** BEGIN LOGGING AT Fri Aug 05 02:59:58 2016 Aug 05 07:36:23 morning folks Aug 05 07:36:46 khem: ping... and sorry for pinging you directly Aug 05 07:37:59 I submitted https://patchwork.openembedded.org/patch/128313/ and have further updates for the same installation scripts Aug 05 07:38:29 Should I base the further changes on top of the submitted one or wait till it gets merged? Aug 05 07:46:25 morning Aug 05 07:49:06 Is there any problem if I use updated sstate cache from a remote location, which is newer than my local sstate cache Aug 05 08:08:18 awaisb: send that as another patch unless its related to the fix in question. if it is then submit a v4 Aug 05 08:08:38 Guest71731: should not be, Aug 05 10:01:45 does anybody know how dropbear+systemd reacts to read-only rootfs ? there seem to be code to deal with that case for systemV init but not systemd... Aug 05 10:34:20 <_jmk> umm. I'm using my own plain kernel recipes to build the kernels, but I'm having issues exporting KERNEL_VERSION from those properly. any handy tricks? Aug 05 10:45:01 <_jmk> so I just want to export the contents of the kernel release file via the datastore and/or global as usual. wasn't as straight forward as I had hoped :-/ Aug 05 10:51:30 _jmk, have you checked the kerenl.bbclass ? Aug 05 11:13:00 <_jmk> jkroon_, yes. it's not obvious from that what the magic is to get it to export. Aug 05 11:18:32 _jmk, have it exported so that other recipes can access it ? I think you'd have to export it yourself in a common .inc or .bbclass file Aug 05 11:18:54 at least thats what module_base.bbclass seems to do Aug 05 11:31:44 <_jmk> jkroon_, indeed seems that way. so there is no way to implement own standalone kernel recipes correctly :-/ ? Aug 05 11:42:27 <_jmk> issue comes mainly from out of tree modules as 'inherit module' will go oof if it doesn't know the exact version. I'm not even entirely sure why it was done that way that it needs to know that version since it could just as well access System.map, config etc what ever it needs via symlinks Aug 05 12:44:14 im trying to add, "rpi-sdimg" to my IMAGE_FSTYPES in toasters bitbake variables and unable to do so any ideas? Aug 05 12:44:49 _jmk: I believe it fetches info from ./work-shared/kernel/$machine/kernel-build-artifacts/kernel-abiversion Aug 05 12:45:59 ../sources/poky/meta/classes/module-base.bbclass:export KERNEL_VERSION = "${@base_read_file('${STAGING_KERNEL_BUILDDIR}/kernel-abiversion')}" Aug 05 12:46:20 does your kernel populate that dir? Aug 05 13:07:10 r0r0: you should just be able to go to the 'bitbake variables' page, click the icon next to the IMAGE_FSTYPES variables, type "rpi-sdimg" at the end of the value and click 'save' Aug 05 13:08:42 tried that but it just does the list and when I click save its still the same Aug 05 13:08:52 distro is poky Aug 05 13:09:27 git branch : krogoth Aug 05 13:09:54 r0r0: sounds like a bug :/ Let me check Aug 05 13:10:01 thanks Aug 05 13:10:27 layer is added for meta-raspberrypi Aug 05 13:13:41 r0r0: sorry, I forgot. Krogoth shippedh with a bug that prevents you from adding IMAGE_FSTYPES not currently listed in Toaster. I Aug 05 13:14:01 anyway I can force it in there Aug 05 13:14:01 ? Aug 05 13:15:37 r0r0: you should be able to change the value of IMAGE_FSTYPES in the local.conf file Aug 05 13:16:09 if I do that will that apply to every new project I add into toaster? Aug 05 13:16:36 r0r0: no. Toaster creates a separate build directory for each project, with its own local.conf file Aug 05 13:17:03 so they are like build-toaster-2 / build-toaster-3 Aug 05 13:17:04 like that Aug 05 13:17:05 ? Aug 05 13:17:12 r0r0: yes Aug 05 13:17:21 making more sense now :-) Aug 05 13:17:43 r0r0: if you want to apply the change across toaster, you can try to use the django admin interface to change the value of IMAGE_FSTYPES in the whole toaster instance Aug 05 13:17:57 nope dont wanna do that lol Aug 05 13:17:57 r0r0: haven't tried that in ages though, so I can't guarantee it will work Aug 05 13:18:09 I noticed on yoctoproject.org/toaster that it allow for users Aug 05 13:18:18 mine doesnt have that.. is that a different branch Aug 05 13:18:18 ? Aug 05 13:18:56 r0r0: no, that is a window in the future of Toaster :) we only use it to discuss and design new features. It's not a real toaster: it's only a design prototype Aug 05 13:19:13 gotcha Aug 05 13:20:08 so im looking in these local.conf files for each build only seeing that the MACHINE_TYPE is set to the default and not what I specified in toaster Aug 05 13:20:11 is that normal? Aug 05 13:21:04 r0r0: yes it is Aug 05 13:21:26 I just wanted to make sure that it references my IMGE_FSTYPE change Aug 05 13:21:36 r0r0: there is another file in /conf called toaster.conf that will apply the toaster configuration Aug 05 13:21:55 r0r0: btw, you might try changing the value of IMAGE_FSTYPES in toaster.conf instead. Aug 05 13:22:10 I saw that and thought about changing it but when I change the value in toaster it doesnt reflect there in the toaster.conf Aug 05 13:22:37 I tried switching from ext3 to ext4 just to see if that file would be updated Aug 05 13:22:37 r0r0: that makes sense, of course Aug 05 13:22:39 r0r0: any change to local.conf should definitely work for you Aug 05 13:22:42 it wasnt Aug 05 13:22:53 okay well I will give it a whirl :-) Aug 05 13:23:10 r0r0: let us know how it goes. Now I am curious :) Aug 05 13:23:23 anyway I can figure out which build folder belongs to which project? Aug 05 13:23:44 r0r0: not easy, sorry. The project id is in the url Aug 05 13:24:22 so if my project is project/2 I can safely assume that build-toaster-2 is what im after? Aug 05 13:24:28 toastergui/project/3/builds/ corresponds to build-toaster-3 Aug 05 13:24:33 ok Aug 05 13:24:37 thanks :-) Aug 05 13:25:05 r0r0: np. Sorry for the annoying fstypes bug. It's fixed in master at least :) Aug 05 13:25:23 hwo can I pull down the master? I thought I did Aug 05 13:25:41 I dont mind the extra work to get the issue fixed Aug 05 13:26:40 is it the master for poky? because when I cd into my poky and did a git checkout master Aug 05 13:26:44 it said it was already on master Aug 05 13:27:45 r0r0: if you select the release as master, its going to clone the master branch of poky Aug 05 13:28:12 r0r0: master will not build the krogoth release I'm afraid Aug 05 13:28:27 been working for me so far Aug 05 13:28:33 for building krogoth Aug 05 13:28:48 except all these hickups with the pi stuff Aug 05 13:29:09 which release should I be using? Aug 05 13:29:14 instead of krogoth? Aug 05 13:30:04 r0r0: can you click on the "i" icon in the top bar of Toaster and let us know what you have there? Aug 05 13:30:12 f5da2a5913319ad6ac2141438ba1aa17576326ab Aug 05 13:30:20 Git branch Aug 05 13:30:20 krogoth Aug 05 13:31:25 r0r0: so you are using Toaster from Yocto Project Krogoth. If you want to build the krogoth release that's the right thing to do Aug 05 13:32:04 ok so I guess my best bet is to just wait until krogoth is patched? Aug 05 13:32:22 beyond the manual edit to hack the imagefs_type Aug 05 13:33:16 r0r0: well, it's even worse than that. It is very unlikely we will patch Krogoth to fix that bug, so you will need to use the manual hack :( Aug 05 13:34:24 ok, guess my next question is so when new version comes out do I need to rebuild toaster completely? Aug 05 13:34:39 or can I add it into my existing setup? Aug 05 13:40:32 r0r0: you will need to scrap your existing installation and set up the new version, I'm afraid. Also, the next release will not build krogoth: too many big changes have happened to be able to provide backwards compatibility Aug 05 13:41:17 r0r0: jeez, we are not painting a pretty picture, are we? ;) Aug 05 13:42:31 im fine with scrapping my install just want to know which builds to pull down in order to set the FSTYPE without an issue Aug 05 13:44:05 I will just keep watching for new stuff to come out. adding in the rpi-sdimg into the local.conf worked without issue. Aug 05 13:44:59 hoping in a future build of toaster allows to auto update without having to rebuild. Aug 05 13:48:44 thanks for the help btw belen1 Aug 05 13:49:56 r0r0: no worries. Any other questions / issues, we are happy to help as we can :) Aug 05 13:51:03 awesome, thanks again. one last thing... are those default image types stored somewhere in the toaster DB where I could just add it in? Aug 05 13:51:21 *FSTYPES Aug 05 13:52:32 r0r0: they come from meta-poky/conf/toasterconf.json file Aug 05 13:52:58 r0r0: you could change the value there, then reload the Toaster configuration Aug 05 13:53:01 seems like a lot more are showing up than whats in that file Aug 05 13:53:13 thats why I was wondering Aug 05 13:53:39 r0r0: ah, you mean the list. Sorry. I believe the list is currently hardcoded. Let see if I can find the file Aug 05 13:54:32 thanks it would be cool if it was just in the DB and I could add it in, I tried searching for files containing those strings but ended up looking at only a few possibilities which made me think DB Aug 05 13:56:15 r0r0: They comes from bitbake/lib/toaster/orm/models.py line 25 I think Aug 05 13:57:07 r0r0: I guess you should be able to change the list to add the fstype Aug 05 13:57:21 that was what I was thinking Aug 05 13:57:21 cool Aug 05 13:58:17 after sdding that into the Target_Image_File do I need to reload something? Aug 05 13:58:20 *adding Aug 05 14:05:50 r0r0: you should see your new fstype at the bottom of the list of types if you click the "change" icon in the IMAGE_FSTYPES variable Aug 05 14:06:52 seems like I need to restart something it didnt show up Aug 05 14:08:39 r0r0: that worked for me, although I am using sqlite, not mysql Aug 05 14:08:56 yea using mysql here Aug 05 14:09:10 let me just restart everything Aug 05 14:10:09 r0r0: yes, you might try restarting apache and toaster Aug 05 14:13:27 that worked Aug 05 14:15:20 r0r0: excellent. At least you won't need to be editing files every time to create a project Aug 05 14:15:36 yup think this is a much better solution Aug 05 14:22:47 so in toaster in order to add in packages like nodejs for example I will still need to add them into "IMAGE_INSTALL_append =" after adding their layer? Aug 05 14:23:14 I would thinking adding the layer would just automatically do that for you... Aug 05 14:34:40 r0r0: adding a layer just means you can build software Aug 05 14:34:58 you wouldn't want to add meta-multimedia and end up with mythtv in all your images Aug 05 14:35:15 ah Aug 05 14:35:19 especially if you only added meta-multimedia for a single library Aug 05 14:41:39 so im looking at packes included in the build is just did and it shows that ive included nodejs and nodejs-npm but its not actually in the image, any thoughts? Aug 05 15:16:43 r0r0: you have 2 ways to add packages to an image in Toaster. 1) you can add the package names to IMAGE_INSTALL_append in the 'BitBake variables' page, then rebuild your image. 2) you can create a custom image from the 'new custom image' tab. You will need to select an image to start from, save it with a new name, then you will be able to choose which packages you want to add to it. Once you are done adding packages, you build it Aug 05 15:17:13 the SDK I have just received is horrendous... (I won't name anyone) Aug 05 15:17:23 did you know that to add an ipk to an existing rootfs you could Aug 05 15:17:30 1) untar ther tar.gz rootfs Aug 05 15:17:36 2) find the ipk you want to add Aug 05 15:17:43 3) unpack the ipk using ar Aug 05 15:17:47 awesome :( Aug 05 15:17:55 and they advertise yocto as officially supported Aug 05 15:18:05 nice Aug 05 15:18:27 oh, and for stuff that doesn't come from the yocto build they are based on (i.e stuff the develop themselves) they simply copy a big rootfs Aug 05 15:18:36 so they break the whole package management system Aug 05 15:26:55 thanks Belen, got it working. got this pi booting into QT in around 11 seconds from a cold boot Aug 05 15:27:04 lol fast! Aug 05 15:27:25 r0r0: \0/ Aug 05 17:26:11 my colleague is trying to build an image and getting this: https://paste.kde.org/ptwv2xt7w/yuddet/raw got a clue? Aug 05 17:53:52 AFK for a few hours. Aug 05 17:58:19 kergoth: any idea? ^ You are usually one of those answering difficult issues :) Aug 05 17:59:36 lpapp: looks like a network issue to me? Aug 05 18:01:41 Fetcher failure: Fetch command failed with exit code 128, output: Aug 05 18:01:41 Connection closed by 192.168.3.15 Aug 05 18:01:41 fatal: The remote end hung up unexpectedly Aug 05 18:01:43 yep Aug 05 18:01:57 git needs auth? Aug 05 18:02:38 yes, it does, but I believe my colleague typed those in. Aug 05 18:02:48 Also, I thought that he was also using ssh keys like me. Aug 05 18:03:13 so what I can come back to him with is probably trying to clone the repository from that IP address without Yocto to see whether it succeeds? Aug 05 18:03:18 or what exactly? Aug 05 18:03:35 he is trying to use his Yocto setup at work from home over VPN Aug 05 18:03:45 it all works fine when he uses Yocto directly at his desk in here. Aug 05 18:03:50 It's probably git ls-remote which fails Aug 05 18:03:51 this problem seems to appear over VPN. Aug 05 18:03:55 I see. Aug 05 18:04:15 so perhaps I could send him a git command to try outside Yocto? Aug 05 18:04:23 the IP address above is our internal git server Aug 05 18:08:15 whats the best way to delete failed builds in toaster? Ive been using /manage.py builddelete but have been running into trouble... is there any better way? Aug 05 18:08:39 I'd try git ls-remote and git rev-list in the git folder of the recipe in download cache that fails Aug 05 18:09:48 neverpanic: thank you. Aug 05 18:11:18 the relevant code is http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/git.py and http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/__init__.py, def get_srcrev Aug 05 18:12:37 cheers. Aug 05 18:32:08 hello Aug 05 18:33:23 i have a problem with building my image derived from core-image-base, kernel modules are not being built and installed Aug 05 18:34:28 my machine conf includes this: Aug 05 18:34:30 MACHINE_ESSENTIAL_EXTRA_RDEPENDS = " kernel-modules kernel-devicetree" Aug 05 18:34:53 and my image recipes defines this: Aug 05 18:34:57 MACHINE_EXTRA_RDEPENDS += " \ Aug 05 18:34:57 kernel-module-usb-f-rndis \ Aug 05 18:34:58 kernel-module-tpm \ Aug 05 18:34:58 kernel-module-tpm-rng \ Aug 05 18:35:00 kernel-module-tpm-i2c-atmel \ Aug 05 18:35:00 " Aug 05 18:35:06 but the modules are not being built Aug 05 18:35:18 and /lib/modules on rootfs is empty Aug 05 18:35:54 any idea what i'm doing wrong Aug 05 18:45:01 is it safe to delet the build-toaster-* folders if you want to start new? Aug 05 18:47:17 I'm attempting to create a secondary filesystem of debug-only tools. Are there any good examples of making one filesystem depend on another? I can create my second file system but RPM installs a number of extra packages. I'd like to keep it to the minimum set of "extra" packages for this second filesystem. Aug 05 18:47:44 As in, the do_rootfs RPM run installs packages that are already in the base filesystem onto the secondary filesystem. Aug 05 18:52:37 iskander: MACHINE_ESSENTIAL_EXTRA_RDEPENDS adds packages to packagegroup-core-boot.bb, and MACHINE_EXTRA_RDEPENDS to packagegroup-base.bb. you'd need to make sure that they image you're using includes those as appropriate. Aug 05 18:53:03 ok, will do, thank you Aug 05 18:54:48 a protip is to set up some kind of recursive search shell helper btw, that searches e.g. bb, bbappend, inc, conf, and py files Aug 05 18:55:11 ag (silver searcher) is nice and speedy Aug 05 18:57:29 and yeah, it's bad if you have to do that all the time. the documentation maintainer is friendly if you feel like submitting stuff. i do it all the time. Aug 05 19:00:00 the problem must be with my machine config, because if i change back to default 'beaglebone' then it works with my image recipe Aug 05 19:00:27 but not with my own machine conf, the same image bb Aug 05 19:01:21 yeah, all drivers were installed with the default machine Aug 05 19:01:25 hmm Aug 05 19:02:34 iskander: bitbake -e might be nice for debugging. there you'll see the values of all the variables and how they got those values (in comments above them). Aug 05 19:03:14 ok, i'll compare both Aug 05 19:03:42 IMAGE_INSTALL has the set of packages that get installed Aug 05 19:04:17 it might also include packagegroups though, and any runtime dependencies of packages will get installed too Aug 05 19:04:29 could also try searching for some driver names, etc. Aug 05 19:05:08 * Ulfalizer needs to get some food Aug 05 19:06:50 iskander: change it to MACHINE_EXTRA_RRECOMMENDS = "kernel-modules" Aug 05 19:08:17 mompls Aug 05 19:10:51 hmm, error, kernel module not found Aug 05 19:11:40 i made a copy of beaglebone.conf, rename it, they should be identical, and still no kernel modules if i set MACHINE to beaglebone-black Aug 05 19:12:06 are you using meta-ti ? Aug 05 19:12:40 no, my own layer Aug 05 19:13:25 can you show the output of bitbake -e | grep -r "^BAD_RECOMMENDATIONS=" Aug 05 19:13:35 mompls Aug 05 19:16:44 empty, BAD_RECOMMENDATIONS="" Aug 05 19:18:12 maybe my kernel recipe is incorrect Aug 05 19:18:33 i had to add COMPATIBLE_MACHINE_beaglebone-black = "beaglebone-black" Aug 05 19:18:46 i patched kernel 4.4 to add cape manager support Aug 05 20:09:38 anyone around to answer some toaster questions? Aug 05 20:11:46 esa máquina incluso tiene vinculado un disco virtual de 500GB :) Aug 05 20:14:15 iskander: I dont know why it wont compile the modules then Aug 05 20:14:24 you seen to have all needed stuff Aug 05 20:14:52 ok, thank you, i'll try to figure it out Aug 05 20:40:39 I'm creating a readonly image with yocto 1.7 Aug 05 20:41:21 I create a rw partition , and I'm linking all the rw files to readonly fs Aug 05 20:42:38 there's a less painfull mode to do this? Aug 05 20:48:11 I'm havnig problem with connman , all the configuration will be saved in the /var/lib/connman, using the initramfs this folder will be readonly Aug 05 21:12:05 khem, you still here ? Aug 05 22:20:42 yes Aug 05 22:23:51 using my own machine conf somehow messed up my image Aug 05 22:24:13 i changed back to beaglebone machine and it's working again Aug 05 22:24:34 i had to use core-image-base as basis, else kernel modules are not installed Aug 05 22:33:50 and finally kernel module autoloading is working too :) Aug 05 22:36:03 i found another problem with linux-yocto kernel bbappend Aug 05 22:37:02 if i place my patches in a subfolder but config fragments then linux-yocto can't be built, problems with config fragments Aug 05 22:37:20 but when fragments and patches are on the same level then it works Aug 05 22:37:52 i noticed that i'm not the only one who has this problem, some guy reported it too Aug 05 23:18:24 you need to add the path using FILESEXTRAPATHS_prepend := "${THISDIR}/files:" in your bbappend Aug 05 23:18:38 then it will recognise files/ folder in your layer Aug 05 23:19:29 what did you have in your machine config Aug 05 23:19:48 usually its better to include the parent conf and then make tweaks Aug 05 23:20:35 one big change that happens is that you have a new MACHINE and you have to accound for that through out metadata since therre might be overrides looking for beaglebone Aug 05 23:21:00 so usually folks add the refeence machine name to OVERRIDE via adding it to MACHINEOVERRIDES Aug 05 23:21:15 i have FILESEXTRAPATHS_prepend := "${THISDIR}/files:" in my linux-yocto bbappend Aug 05 23:21:31 but i placed patches in a subfolder in 'files' Aug 05 23:21:40 and that caused trouble Aug 05 23:22:08 thanks for the hint with MACHINEOVERRIDES, i'll try it out Aug 05 23:26:50 khem, how do i use MACHINEOVERRIDES correctly ? Aug 05 23:27:05 google is no help this time Aug 05 23:27:38 MACHINEOVERRIDES = "beaglebone" ? Aug 05 23:31:26 found this in qemux86copy.conf: MACHINEOVERRIDES .= ":qemux86" Aug 05 23:32:36 thanks for your help Aug 05 23:33:06 bye **** ENDING LOGGING AT Sat Aug 06 02:59:58 2016