From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Suneetha Lakshmi G Sent: Friday, March 10, 2017 8:25 AM To: yocto@yoctoproject.org Subject: Re: [yocto] help
Hi All, Im new to yocto and trying to build for my customer device im facing this issue. | arm-linux-gnueabi-xgcc: error: unrecognized command line option '-mgeneral-regs-only' | arm-linux-gnueabi-xgcc: error: unrecognized command line option '-mcmodel=large' | make: *** [opkg-compare-versions] Error 1 | ERROR: oe_runmake failed Please guide how to progress further. [ras] please provide what target you are building from, where you got your yocto layers from, what bitbake command you are using. My WAG is that your toolchain is misconfigured, possible because you haven't specified a MACHINE variable. Regards, Suneetha ________________________________ From: yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org> <yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org>> on behalf of yocto-requ...@yoctoproject.org<mailto:yocto-requ...@yoctoproject.org> <yocto-requ...@yoctoproject.org<mailto:yocto-requ...@yoctoproject.org>> Sent: Friday, March 10, 2017 7:20 PM To: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> Subject: yocto Digest, Vol 78, Issue 45 Send yocto mailing list submissions to yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> To subscribe or unsubscribe via the World Wide Web, visit https://lists.yoctoproject.org/listinfo/yocto or, via email, send a message with subject or body 'help' to yocto-requ...@yoctoproject.org<mailto:yocto-requ...@yoctoproject.org> You can reach the person managing the list at yocto-ow...@yoctoproject.org<mailto:yocto-ow...@yoctoproject.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of yocto digest..." Today's Topics: 1. Re: Raspberry Pi2 Fails to boot into LXDE. (Steve Plant) 2. Re: update mechanisms (Kristian Amlie) 3. Proposal: dealing with language-specific build tools/dependency management tools (Alexander Kanavin) ---------------------------------------------------------------------- Message: 1 Date: Fri, 10 Mar 2017 13:31:40 +0000 From: Steve Plant <ste...@hotmail.com<mailto:ste...@hotmail.com>> To: Gary Thomas <g...@mlbassoc.com<mailto:g...@mlbassoc.com>> Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>> Subject: Re: [yocto] Raspberry Pi2 Fails to boot into LXDE. Message-ID: <sg2pr0301mb20164f99a2af83afc01ecdcfd1...@sg2pr0301mb2016.apcprd03.prod.outlook.com<mailto:sg2pr0301mb20164f99a2af83afc01ecdcfd1...@sg2pr0301mb2016.apcprd03.prod.outlook.com>> Content-Type: text/plain; charset="iso-8859-1" Thanks Gary, You where spot on! I have now been able to SSH into the rpi and have posted the Xorg.log file to the mailing list. I think Xorg is failing to load correctly because it cannot find the evdev module. Looking into how to fix this now...... Regards, Steve. ________________________________ From: yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org> <yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org>> on behalf of Gary Thomas <g...@mlbassoc.com<mailto:g...@mlbassoc.com>> Sent: Friday, 10 March 2017 5:42 a.m. To: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> Subject: Re: [yocto] Raspberry Pi2 Fails to boot into LXDE. On 2017-03-10 01:55, Steve Plant wrote: > OK, I have spent the last day googling my heart out trying to find the > Xorg.log file without any luck. > > > The problem is that due to the rpi hanging on boot, the only way I can access > the SD card to look for the file is place > it in a USB SD card reader and use my VirtualBox based Debian to "ls" > directores etc. > > Having established that there is no file located at /var/log/Xorg.log (there > isn't a log directory) but there is a > symbolic link in the var directory - goes nowhere. > > > After goggling I discovered that the file could also be in the > ~/.local/share/xorg/Xorg.0.log, however if I try to look > there I get "permission denied" and cannot seem to get to the root directory > of the card and I can't find a way around > this as I'm trying to access this directory through the USB card reader. > > > Looked everywhere with no answers, Is there anyone who could help me here?? /var/log is on a volatile file system (i.e. it does not live on the SD card) If you can get into your board via SSH, you can copy the file and send it > ------------------------------------------------------------------------------------------------------------------------ > *From:* Khem Raj <raj.k...@gmail.com<mailto:raj.k...@gmail.com>> > *Sent:* Wednesday, 8 March 2017 5:17 p.m. > *To:* Steve Plant > *Cc:* yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> > *Subject:* Re: [yocto] Raspberry Pi2 Fails to boot into LXDE. > > On 17-03-08 12:40:51, Steve Plant wrote: >> Hi All, >> >> >> Very new to all this linux world, and especially Yocto. >> >> >> I'm working on a embedded project at the moment using a raspberry pi2 board. >> >> >> I have used toaster with Morty 2.2 to compile an image >> using"rpi-basic-image", to this I have added the following bitbake variables: >> >> Bitbake variables >> >> DISTRO >> poky >> DL_DIR >> /home/steve/poky/downloads >> IMAGE_FSTYPES >> ext3 jffs2 tar.bz2 rpi-sdimg >> IMAGE_INSTALL_append >> packagegroup-core-x11-base packagegroup-lxde-base connman >> PACKAGE_CLASSES >> package_rpm >> SSTATE_DIR >> /home/steve/poky/sstate-cache >> >> DISABLE_OVERSCAN >> 1 >> GPU_MEM_1024 >> 512 >> >> I have dd'ed the image to an SD card increased the sdb2 partition to the max >> size and powered up the rpi. Everything looks fine to start with, as it >> displays the four raspberrys in the top left, then the white "Yocto Project" >> splash screen complete with small blue dot to the side appears, the progress >> bar moves across to 100 percent, then the screen turns black with a white > cursor in the middle and it appears to freeze with only a very dim one second > flash of the "act" led. >> >> >> I have then connected the 7" touchscreen and apart from the added >> multicolored square at the very beginning I get the exact same boot up >> problem, hangs on the black screen with white cursor (good to see its all >> resized correctly for the TfT through!!) >> >> >> Before adding the packagegroup-core-x11-base and packagegroup-lxde-base I >> successfully copied over and ran the rpi-basic-image with no problem, ending >> up with a usable console. >> >> >> Looking for any help here, I'm thinking I've missed adding a package, or >> some type of local.conf instruction. any suggestions would be >> appreciated............. > > Can you send the content of /var/log/Xorg.log file ? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- _______________________________________________ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto> yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto> lists.yoctoproject.org Discussion of all things about the Yocto Project. Read our Community Guidelines or learn more about how to participate in other community discussions. lists.yoctoproject.org Discussion of all things about the Yocto Project. Read our Community Guidelines or learn more about how to participate in other community discussions. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170310/74aab5d4/attachment-0001.html> ------------------------------ Message: 2 Date: Fri, 10 Mar 2017 14:35:02 +0100 From: Kristian Amlie <kristian.am...@mender.io<mailto:kristian.am...@mender.io>> To: Patrick Ohly <patrick.o...@intel.com<mailto:patrick.o...@intel.com>>, Eystein M?l?y Stenberg <eyst...@mender.io<mailto:eyst...@mender.io>> Cc: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> Subject: Re: [yocto] update mechanisms Message-ID: <0135756b-1d20-a743-4f82-8f45becea...@mender.io<mailto:0135756b-1d20-a743-4f82-8f45becea...@mender.io>> Content-Type: text/plain; charset=utf-8 On 10/03/17 14:02, Patrick Ohly wrote: > On Wed, 2017-03-01 at 16:35 -0800, Eystein M?l?y Stenberg wrote: >> On Tue, 2016-12-06 at 10:45 +0100, Patrick Ohly wrote: >>> On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote: >>>> Hi Patrick, >>>> >>>> On 30/11/2016 15:59, Patrick Ohly wrote: >>>>> I've started a Wiki page >>>>> https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the >>>>> moment, but might as well be mentioned already now. >>>> >>>> I have seen Mariano added an entry for SWUpdate, too, thanks - I would >>>> like to edit for better explanation on some parts. Should I try to edit >>>> directly the page or is it better to discuss it here ? >>> >>> Use your own judgment. If its uncontroversial, the feel free to edit the >>> page directly, otherwise let's discuss it here. >>> >>> If feel that putting information directly into the table is too limiting >>> (it should be brief), then feel free to start a complete section about >>> SWUpdate. >>> >>> I'll do the same for swupd. Editing the sections should be possible >>> without conflicts, we just have to be more careful about editing the >>> table concurrently. >> >> I updated the Mender part of the wiki now that the stable version Mender >> 1.0 is released. These changes should not be controversial, but let me >> know if you disagree. We are planning to keep the Mender section >> up-to-date as we release new versions, as I think this is what you expect. > > Yes, that's useful. > >> Are there any plans for next steps or is the wiki the "final state" in >> terms of integrating OTA updates in Yocto/OE? > > My own conclusion is that it is impossible to integrate a specific OTA > update into Yocto/OE (because there's no single solution that fits all > requirements) and/or it would be unfair to those solutions that don't > get such special testing. In that sense the Wiki page is the final > result of the investigation. Anyone interested in picking a solution can > go there, consider the pros and cons, and then make a choice. Makes sense. We can always revisit this at a later point, if one method starts to emerge as the preferred option for most people. > However, I see room for some collaborative work that then can happen in > Yocto/OE: > * carrying local system configuration changes across system > updates: I find it promising to investigate the "stateless" > concept and have started some exploratory work, see > > https://wiki.yoctoproject.org/wiki/Stateless#Status_and_goals_for_.22stateless.22_in_Yocto > (more on that soon) What's the relation (if any) between this and a read-only rootfs? Also this may be only vaguely related, but I have it in my queue to finish the built-in partitioning of rootfs images [1], which will help divide the filesystem into a stateful and a stateless part. The wic part is done [2], but ext4 images are not covered yet. [1] It works by choosing which sub directories of the complete rootfs you want on each partition. [2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=10712 > * supporting UEFI-based machines Great, this is something we are interested in as well! -- Kristian ------------------------------ Message: 3 Date: Fri, 10 Mar 2017 15:49:01 +0200 From: Alexander Kanavin <alexander.kana...@linux.intel.com<mailto:alexander.kana...@linux.intel.com>> To: openembedded-architect...@lists.openembedded.org<mailto:openembedded-architect...@lists.openembedded.org>, Yocto Project <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>> Subject: [yocto] Proposal: dealing with language-specific build tools/dependency management tools Message-ID: <37d4f98c-9102-f4bf-c6cc-f64e1ffbc...@linux.intel.com<mailto:37d4f98c-9102-f4bf-c6cc-f64e1ffbc...@linux.intel.com>> Content-Type: text/plain; charset=utf-8; format=flowed Hello all, *Introduction* The new generation of programming languages (think node.js, Go, Rust) is a poor fit for the Yocto build model which follows the traditional Unix model. In particular, those new development environments have no problem with 'grabbing random stuff from the Internet' as a part of development and build process. However, Yocto has very strict rules about the build steps and what they can and can not do, and also a strict enforcement of license and version checks for every component that gets built. Those two models clash, and this is a proposal of how they could be reconciled. I'll also send a separate email that talks specifically about MEAN stack and how it could be supported as Yocto - take it as a specific example for all of the below. *Background* The traditional development model on Unix clearly separates installation of dependencies needed to develop a project from the development process itself. Typically, when one wants to build some project, first the project README needs to be inspected, and any required dependencies installed system-wide using the distribution package management's tool. When those dependencies change, usually this manifests itself in a previously unseen build failure which is again manually resolved by figuring out the missing dependency and installing it. This can be awkward, but it's how things have been done for decades, and Yocto's build system (with separate steps for fetching, unpacking, building, packaging etc.) is built around the assumption that most software can be built this way. Unfortunately, this situation is changing. The new development environments, such as Go, Rust or node.js see this approach as cumbersome and getting-in-the-way for developers. They want projects' setup to be as quick and automatic as possible - and it should also be cross-platform. So each such environment comes with a specialized tool which handles installation of dependencies and bypasses the distribution package management altogether. Typically these dependencies are fetched from the Internet and installed into the project tree. The details are hidden; it's assumed that developers don't want to know or care. In particular, specific versions of dependencies can be only weakly specified or ignored altogether (that is, the latest commit is always fetched), licensing is totally overlooked, a list of what was installed cannot be trivially obtained, and repeating the procedure the next day may result in a different set of code being pulled in, because someone somewhere added a commit to their github repo. This does not work well in Yocto context. Yocto project prides itself on being specific and exact about what gets build, how it gets built and what license is attached to each component. So we need to somehow enforce that with the new model, and avoid the situation where separate, incompatible, and difficult to grasp solutions are developed for each language environment. *Design considerations* 1. I would like recipes to remain short and sweet and clear. In particular, node.js projects can pull in hundreds of dependencies; I want to keep their metadata out of the recipe and somewhere else, for readability, clarity, and maintainability. 2. I don't want to implement custom fetchers, or otherwise re-implement (poorly) those language-specific build and dependency management tools. Let's use npm, cargo and go as much as we possibly can and let them do their job - yes, that also includes them fetching things from the internet for us. 3. When things need to be updated to a new version, manual editing of metadata should be avoided: when there are hundreds of dependencies, a tool should modify the metadata, and human should only inspect the changes. *How do we deal with this?* By introducing a lockdown file that lives next to the recipe. The concept is already implemented in npm, but needs to be made generic and come with a common API that is using the file to verify the build. *What is a lockdown file?* The file captures all of the recipe dependencies that are pulled in by the build tool. For each such dependency the following information is provided (this is really similar to what is in recipes, and that is on purpose: - name - description (optional) - verification data (this is specific to each language, but can be version, git commit id, a checksum and so on). The only requirement is that it maps to a unique set of code. - license string - license file path - license checksum *How is the lockdown file used?* 1. It needs to be generated in the first place when adding a new recipe. For example: bitbake -c generate_lockdown recipe would fetch and unpack the recipe code, then run npm/cargo/go to pull in the dependencies, then walk the project tree and generate the lockdown metadata. Sometimes the tools can help here somewhat, but other times they can be used only for fetching, and verification data has to be figured out by inspecting the tree with our custom-written code. This is the hard part that we have to deal with. 2. It can be used to perform a 'loose' build of the recipe that does not guarantee reproducibility. We have to accept this: some projects just don't care about it, and offer no support to those who want reproducibility. We should at least provide a way to build such projects in Yocto. The information in lockdown file is not enforced; it's merely compared against the actual build and any differences presented to the user as warnings. This is a recipe setting. 3. It can also be used to perform a 'strict' build of the recipe that enforces what is in the lockdown file. The information in the lockdown file is given to the language-specific tool to help it fetch the right things (whenever the tool makes it possible), and then is used to compare to what was fetched, but this time any mismatches stop the build. Exactly how this happens is specific to each language, and again, it is the hard bit that we need to deal with. 4. When a recipe is updated to a new version, the lockdown file needs to be updated as well. One possibility is to generate a new lockdown file (as in point 1), and then a human can compare that against the old lockdown file. bitbake -c update_lockdown recipe 5. Packaging Go by default is compiling everything into a static executable, so there are no separate packages. All dependencies' licenses should be rolled into the package: lockdown file tells what they are and where they are in the build tree. Other environments do install the dependencies somewhere in the system, so those should be packaged separately: lockdown file is used to get a list of them and attach licenses to them. Installation paths (things that FILES_ is set to) should typically be easy to figure out from dependency names. *Conclusion* This is only a preliminary idea: I understand that the devil is in the details, and there are plenty of details where things may not work out as planned, or there's something else I didn't think of that should be accounted for. So flame away! ------------------------------ -- _______________________________________________ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto End of yocto Digest, Vol 78, Issue 45 *************************************
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
