7880 2015-06-11 13:46:49 +0000 Toaster uses the same /tmp dir across releases 2016-05-04 10:17:54 +0000 1 1 7 Build System, Metadata & Runtime Toaster toaster 1.8 x86 Multiple VERIFIED FIXED GUI design available Medium+ normal 2.1 M4 9209 9058 1 belen.barros.pena eduard.bartosh alexandru.c.georgescu alexandru.damian belen.barros.pena bluelightning brian.avery cristiana.voicu jessica.zhang stanciux.mihail alexandru.costinx.roman --- New (Never tested) No (bug/feature does not impact docs) oldest_to_newest 51641 0 belen.barros.pena 2015-06-11 13:46:49 +0000 If I build with master, and then build with a stable release, the builds with the stable release will fail. Apparently, this is caused by Toaster reusing the same /tmp directory for the second build. 52434 1 stanciux.mihail 2015-07-16 12:50:16 +0000 *** Bug 8022 has been marked as a duplicate of this bug. *** 53228 2 michael.g.wood 2015-08-19 15:22:49 +0000 Proposed intermediate fix - new tmp dir for project - On release change rm tmp dir 53386 3 brian.avery 2015-08-25 14:41:03 +0000 *** Bug 8204 has been marked as a duplicate of this bug. *** 54542 4 brian.avery 2015-09-23 14:35:38 +0000 tmp needs to be :tmp_toaster_<release> unfortunately we also need to fix buildhistory it needs to be buildhistory_toaster_<release> 55919 5 belen.barros.pena 2015-10-28 13:54:16 +0000 I had a brief conversation with Paul Eggleton about this issue, and he believes that projects should not share anything apart from sstate-cache. This effectively means we should have a build directory per project, and an option to share the sstate directory across projects. In Paul's words: "we would probably be asking if you want the sstate-cache shared when creating the project and then set it according to that checkbox" 55920 6 bluelightning 2015-10-28 13:57:02 +0000 As a response to Brian's mention of buildhistory above, that issue goes away if we keep the build directories separate, because then the default path still works. 56067 7 brian.avery 2015-11-01 18:16:31 +0000 brian concurs. I think Pauls approach is cleaner and may solve several issues at once. will try out an implementation. 56080 8 belen.barros.pena 2015-11-02 11:34:15 +0000 (In reply to comment #7) > brian concurs. I think Pauls approach is cleaner and may solve several > issues at once. will try out an implementation. If we go for this, we'll need to add the sstate-dir option somewhere in the UI. Marking the issue as needing design. 56580 9 belen.barros.pena 2015-11-18 13:56:54 +0000 (In reply to comment #8) > (In reply to comment #7) > > brian concurs. I think Pauls approach is cleaner and may solve several > > issues at once. will try out an implementation. > > If we go for this, we'll need to add the sstate-dir option somewhere in the > UI. Marking the issue as needing design. There is now design for this: check the design document attached to bug 8422 57033 10 belen.barros.pena 2015-12-04 09:25:29 +0000 Something else has occurred to me: what will be the naming scheme for the build directories for each project? If the plan is using the project name, then we'll need to make sure that we enforce a unique name policy for projects in Toaster. Right now, you can create more than one project with the same name, as reported by bug 7005. We'll need to validate the project name when you are creating the project, and show you a little message if another project with the same name exists in the Toaster instance. I'll come up with something. 58250 11 brian.avery 2016-01-26 19:08:57 +0000 Until this gets fixed, the workaround is to stick with one release for a given instance of toaster. If you really need to switch releases, you can run one instance of toaster on port 8000 (the default) in dir /home/me/toaster1/ and another on port 8001 in dir /home/me/toaster2. To set the port when starting toaster do : . /home/me/poky/bitbake/bin/toaster webport=8001 start If it's not set, it will default to port 8000. 58534 12 alexandru.c.georgescu 2016-02-04 09:57:54 +0000 seems that the issue still exists in YP 2.1_M2.rc1 master/3d2c0f5902cacf9d8544bf263b51ef0dd1a7218c 58704 13 eduard.bartosh 2016-02-07 18:09:22 +0000 I'm not sure I understand what needs to be done here. User has to initialize build environment *before* starting toaster. Specifying build directory is part of this. Does it mean that this is documentation issue? Should we suggest user to use non-default build directory? 58706 14 belen.barros.pena 2016-02-07 18:58:55 +0000 So the problem is that although Toaster happily allows you to select different releases of the Yocto Project, there is no connection between the release you select and the build directory used for the builds. As a result, the same build directory is used for different releases, and that causes build failures. (In reply to comment #13) > I'm not sure I understand what needs to be done here. > > User has to initialize build environment *before* starting toaster. > Specifying build directory is part of this. I guess this will need to change. Toaster needs to create a separate build directory for each project. 59160 15 brian.avery 2016-02-17 17:41:51 +0000 I don't think that the user initializing the build dir before starting toaster needs to change. Instead we will end up with something like: toaster/build -- this was created by sourcing poky/oe-init-build-env and is where you would do command line builds that toaster is listening to. toaster/build-Project1 - when you make a project, this build dir is initialized and a bitbake memres server is started and attached to it. toaster/build-ProjectN - more of the same. The fix for bug 8422 means that we will leverage sstate and downloads across all the projects so that rebuild times will be low. 59490 16 eduard.bartosh 2016-02-26 10:23:28 +0000 We decided to do builds by simply running bitbake instead of running 2 resident processes: bitbake server and bitbake observer. This should make implementation of this feature much simpler and reliable. Running bitbake with toasterui requires toasterui to run in build mode. Currently it can only run in observer mode. Here is a fix for this: https://lists.yoctoproject.org/pipermail/toaster/2016-February/003952.html Please, review. 59784 17 eduard.bartosh 2016-03-08 10:06:08 +0000 It turned out that we still need to run bitbake server to support builds for older releaases, so I had to reimplement the implementation. Here is first draft: https://lists.yoctoproject.org/pipermail/toaster/2016-March/004068.html Please, review. 59794 18 eduard.bartosh 2016-03-08 16:38:18 +0000 v2 has been sent for review: https://lists.yoctoproject.org/pipermail/toaster/2016-March/004093.html 59894 19 eduard.bartosh 2016-03-11 12:28:32 +0000 sent v3: https://lists.yoctoproject.org/pipermail/toaster/2016-March/004132.html 60887 20 eduard.bartosh 2016-04-07 08:21:25 +0000 The fix has been merged to bitbake master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a43a16b9fd471d719761354eaab81409d4b07470 61917 21 alexandru.costinx.roman 2016-05-04 10:17:54 +0000 Verified on master.