Re: [yocto] Is Yocto the right fit for my project?
Howdy! On Wed, Nov 20, 2019 at 01:12:52PM +, Richard Barrass wrote: > Hello, > > I am a lead engineer on project where we run a well-known Linux distribution > on-top of a SBC (Intel Quad Pentium processor based) driving a 27" display. > We have a 32GB SSD to run from, which we partition with multiple EXT4 > partitions to help with potential corruption mitigation if the device is > switched off 'hard'. > > But, with the well-known Linux distribution comes a lot of things we don't > need, plus the potential ability to 'break' in to our application which is > running full-screen. > > We basically need > > QT 5.12 runtime (our application) > SSH > OpenVPN > Wifi > Ethernet > Modem (via Telit modem) > USB-ACM > USB-Memory stick > > Is this something I should be looking to the yocto project for, or should I > be looking at a more 'traditional' custom linux distro. Certainly doable. > > The only other aspect, is that we have future plans to cost reduce the > application to be running on a Pi based, 10" display system ... If thats a set goal, then it makes YP even more interesting for you. > > Any thoughts and ideas would be appreciated. Prepare for a steep learning curve and a lot of headshaking each time you say "but I just want to". But you will be rewarded with an awesome amount of control and power if you make it through. Have a look at https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj to get an idea how things work. Greetz > > Regards > Richard > > -- > Richard Barrass > > [BassettElectronicSystemsLtd_Logo] > Bassett Electronic Systems Ltd. Solutions under one roof. > T: 01793 859974 E: > r.barr...@bassettelectronics.com<mailto:r.barr...@bassettelectronics.com> > Unit 23-25 Whitehill Industrial Estate, Whitehill Lane, Royal Wootton > Bassett, Wiltshire, SN4 7DB > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Device is unable to BOOT or INSTALL with generated .hddimg
As the question was almost simultaneously cross-posted on stackoverflow, see answer there: https://stackoverflow.com/questions/58947276/device-is-unable-to-boot-or-install-with-generated-hddimg/58948913#58948913 Greetz On Wed, Nov 20, 2019 at 06:40:35AM +, Oriya, Raxesh wrote: > All, > > I have device which has following configuration: > > - Chipset architecture - `Intel NM10 express` > - Processor - `Atom D2550 Dual Core` > - Display - `DVI` > - Volatile Memory - `2GB DDR3` > - Storage - `16GB` > > **Objective**: Device should run yocto embededded OS successfully > > What I have done, > > - Downloaded three required yocto layers for warrior branch i.e. 1. poky 2. > meta-openembedded 3. meta-intel > - Modified `local.conf` with `MACHINE ??= "intel-core2-32"` > - Ran `source poky/oe-init-build-env` > - Generated `.hddimg` by bitbake `core-image-minimal` > - Flashed `.hddimg` to thumb drive through `dd` command > > Attached thumb drive to device and I could see BOOT and INSTALL option, upon > clicking any of them nothing happens(not even logs) i.e. Blank screen > > Troubleshooting I tried out are, > > 1. Tried to boot `lubuntu` and it was successful > 2. Replaced kernel & initrd of `lubuntu` with yocto's one and booting was > successful which indicates there is no issue with kernel or initrd in > `.hddimg` generated by yocto > 3. Tried some experiment with `syslinux` as well but didn't work out > > Regards, > Raxesh > > -- > _______ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GCC version 8 upgrade
On Thu, Oct 31, 2019 at 11:49:38AM -0400, Bishop . wrote: > How silly would it be to try and get GCC sdk v8 complied and installed for > Jethro? Lets call it "quite demanding" instead of "outright silly", ok? Greetz > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Reducing the size of the image by optimizing python
On Sat, Oct 19, 2019 at 04:32:26PM +, Abhi Arora wrote: > I am planning to install it in my host machine and see if I am able to run my > scripts and manually add or remove modules and python packages to get minimal > required system for my scripts. > > For that I need to access python3-misc and what it installs. Its not something that directly corresponds to a standard desktop distribution. Rather, its "everything that would otherwise be left behind", see: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/python/python3_3.7.4.bb#n323 So its just like the advice was already: remove it, see what breaks, and then add smaller bits and pieces again until everything works as desired. Greetz > > > > Get Outlook for Android<https://aka.ms/ghei36> > > > From: Yann Dirson > Sent: Saturday, October 19, 2019 8:51:52 PM > To: richard.pur...@linuxfoundation.org > Cc: Abhi Arora ; Khem Raj ; > yocto@yoctoproject.org > Subject: Re: [yocto] Reducing the size of the image by optimizing python > > You can also look at the package dependency graph (see the file > generated by bitbake -g) to get a better idea of what pulls what. > > 2019-10-19 17:10 UTC+02:00, richard.pur...@linuxfoundation.org > : > > On Sat, 2019-10-19 at 14:55 +, Abhi Arora wrote: > >> Thanks your for the suggestion. > >> > >> From where I can find out what modules and packages python3-misc > >> downloads and installs? I am new to yocto and Don't know where to > >> look for. I tried grep but didn't help me. > > > > python3-misc is a package. You can look at its dependencies to see what > > it adds to the image. > > > >> And how about optimization using pyc file? Is it doable? > > > > Start simple. If you have python3-misc installed its using a lot of > > space and is the sensible place to start with trimming things down. > > > > Optimising to just pyc files is an optimisation further than most > > people find they need and will be much harder to do. > > > > Cheers, > > > > Richard > > > > > > > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > > > -- > Yann Dirson > Blade / Shadow -- http://shadow.tech > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [npm] duplicate code
On Mon, Oct 07, 2019 at 09:33:46PM +0200, Stefan Herbrechtsmeier wrote: > Hi Jean-Marie, > > Am 07.10.19 um 14:16 schrieb Jean-marie Lemetayer: > > > I thought about your idea of using Yocto to manage NPM package > > > dependencies and I ran into an issue. NPM projects can have multiple > > > dependencies on a single package, and sometimes with multiple versions. > > > NPM will manage this by creating sub 'node_modules' tree. > > > > Here is an example with a newly created angular application. The app > > depends on 3 different version of 'ansi-regex'. NPM will install the > > packages this way: > > node_modules/ansi-regex @ 2.1.1 > > node_modules/cliui/node_modules/ansi-regex @ 3.0.0 > > node_modules/inquirer/node_modules/ansi-regex @ 4.1.0 > > node_modules/string-width/node_modules/ansi-regex @ 3.0.0 > > node_modules/@angular/compiler-cli/node_modules/ansi-regex @ 4.1.0 > > I use symbolic links instead of folders, append the major version to the > folder name and move the folders into the main node_modules folder. At the > moment I use one version per major version or first version unequal to zero: > > node_modules/ansi-regex-2 > node_modules/ansi-regex-3 > node_modules/ansi-regex-4 > node_modules/cliui-X/node_modules/ansi-regex -> ../../ansi-regex-3 > node_modules/inquirer-X/node_modules/ansi-regex -> ../../ansi-regex-3 > node_modules/string-width-X/node_modules/ansi-regex -> ../../ansi-regex-3 > node_modules/@angular/compiler-cli-X/node_modules/ansi-regex -> > ../../../ansi-regex-4 > node_modules/abc-X/node_modules/ansi-regex -> ../../ansi-regex-2 > node_modules/abc-X/node_modules/cliui -> ../../cliui-X > node_modules/abc-X/node_modules/inquirer -> ../../inquirer-X > node_modules/abc-X/node_modules/string-width -> ../../string-width > node_modules/abc-X/node_modules/@angular/compiler-cli -> > ../../../@angular/compiler-cli-X > > > > How can you handle that with Yocto ? I am not sure but I think it is not > > possible. > It is possible and Yocto could do even more. If you take a look at the > package ansi-regex you realize that the project increase the major version > only because they change the minimum required nodejs version. This means you > could replace all ansi-regex version by the last version, add some symbolic > links to the ansi-regex package and provide all versions by the same > package. I think it would be dangerous to assume this holds true for other packages too. In the semantic versioning world as npm packages expectexd to behave - and nodejs itself certainly does! - a change in the major version means a breaking change of some kind. > > Regards > Stefan > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fetching Yocto layers
I'd like to throw kas into the discussion too, I've been using it quite successfully. https://github.com/siemens/kas Greetz On Mon, Sep 02, 2019 at 03:34:28PM +0200, Alexander Kanavin wrote: > On Mon, 2 Sep 2019 at 15:05, Brian Silverman wrote: > > > The tags chosen above are based on what we test and ship. So my issue is > > that someone has to correctly follow the above instructions for different > > versions of multiple layers if they want a reproducible build of a specific > > version of mylayer-image. > > > > Is there a canonical why to encode this information within my layer? > > Obviously I could script the above, store it in my layer, and have the user > > run that script. But, that seems very unyocto-like. > > > > At the moment Yocto project does not have an off-the shelf setup for > multiple layers. You are welcome to provide and maintain one, until then it > is indeed custom scripts, or tools like Google's 'repo', or maybe git > submodules could work. > > Alex > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Support NAND flash
On Thu, Jun 06, 2019 at 09:15:46PM +1000, JH wrote: > More specific, looks to me that the drivers are OS based, the eCos has > NAND I/O, the OpenWRT has some support NAND I/O as well, how does the > Yocto support? This is not exactly a "how does the yocto" support-thing. Yocto is not the OS. The OS by itself is the Linux kernel, which has extensive NAND support in a lot of varieties. If you want to have a look, see https://elixir.bootlin.com/linux/latest/source/drivers/mtd and especially the nand subdirectory. In a nutshell it goes like this: if you buy a board, ask whomever gave it to you for a kernel plus config that works. Also, they are in most cases also obliged to tell you how to write something to the (NAND-)flash. For the userspace side, there is the mtd-utils suite: http://www.linux-mtd.infradead.org which is already nicely packaged for OE: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/mtd/mtd-utils_git.bb So these are your starting points, you have to apply them to your specific setup yourself. The only common things I can think of is: 1) make sure your kernel+config support the flash chip in use 2) install the mtd-utils for interacting with it. Greetz. > > Thank you. > > Kind regards, > > - JH > > On 6/6/19, JH wrote: > > Hi, > > > > Has anyone used NAND? Does the MTD already support the NAND driver or > > do you have to work our the detailed driver yourself? Could you share > > your experiences how to build the image and to hand and access the > > NAND if it is required? > > > > Thank you. > > > > Kind regards, > > > > - JH > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_rootfs failed (not sure why)
Hi Gaurav, On Fri, May 17, 2019 at 03:42:02PM +0900, Gaurav Kalra wrote: > Hi, > > I am new in the Yocto world and have started learning the concepts recently. > A big thanks to the broadcasts on twitch and numerous youtube videos. As the broadcaster on Twitch, thanks for letting us know. It is much appreciated! > What I am doing: Modifying boot2qt ( > https://codereview.qt-project.org/gitweb?p=yocto/meta-boot2qt.git;a=shortlog;h=refs/heads/thud) > as my blueprint for raspberry-pi. > > Mostly: > 1. Modifying the configuration of packages (e.g., systemd conf files) > 2. Adding new recipes > 3. Keeping Qt updated > > "Sometimes", I face this strange error in do_rootfs(), while > installing binutils-lic package inside the image. > > [...] > ERROR: seesv-embedded-qt5-image-1.0-r0 do_rootfs: Unable to install > packages. Command > '/media/gvkalra/66bef40b-d84f-4ad0-ada6-a025b494ca5d/seesv-distro/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/seesv-embedded-qt5-image/1.0-r0/recipe-sysroot-native/usr/bin/opkg I'm not sure if it applies here, but I have encountered problems with long pathes. Especially the leading part with the UUID *might* be problematic. Have you tried in a location closer to root? Greetz Josef > --volatile-cache -f > /media/gvkalra/66bef40b-d84f-4ad0-ada6-a025b494ca5d/seesv-distro/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/seesv-embedded-qt5-image/1.0-r0/opkg.conf > -t > /media/gvkalra/66bef40b-d84f-4ad0-ada6-a025b494ca5d/seesv-distro/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/seesv-embedded-qt5-image/1.0-r0/temp/ipktemp/ > -o > /media/gvkalra/66bef40b-d84f-4ad0-ada6-a025b494ca5d/seesv-distro/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/seesv-embedded-qt5-image/1.0-r0/rootfs > --force_postinstall --prefer-arch-to-version install opkg > packagegroup-b2qt-embedded-base packagegroup-b2qt-embedded-gstreamer > packagegroup-b2qt-embedded-tools packagegroup-b2qt-qt5-modules > packagegroup-base-extended packagegroup-core-boot > packagegroup-core-ssh-dropbear packagegroup-core-tools-debug > packagegroup-core-tools-profile run-postinsts' returned -11: > [...] > Installing openssh-lic (7.8p1+git) on root > Downloading > file:/media/gvkalra/66bef40b-d84f-4ad0-ada6-a025b494ca5d/seesv-distro/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/seesv-embedded-qt5-image/1.0-r0/oe-rootfs-repo/cortexa7t2hf-neon-vfpv4/openssh-lic_7.8p1+git-r0_cortexa7t2hf-neon-vfpv4.ipk. > Installing binutils-lic (2.31) on root > Downloading > file:/media/gvkalra/66bef40b-d84f-4ad0-ada6-a025b494ca5d/seesv-distro/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/seesv-embedded-qt5-image/1.0-r0/oe-roo > ERROR: seesv-embedded-qt5-image-1.0-r0 do_rootfs: Function failed: do_rootfs > ERROR: Logfile of failure stored in: > /media/gvkalra/66bef40b-d84f-4ad0-ada6-a025b494ca5d/seesv-distro/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/seesv-embedded-qt5-image/1.0-r0/temp/log.do_rootfs.21682 > ERROR: Task > (/media/gvkalra/66bef40b-d84f-4ad0-ada6-a025b494ca5d/seesv-distro/sources/meta-seesv/meta-seesv-distro/recipes-qt/images/seesv-embedded-qt5-image.bb:do_rootfs) > failed with exit code '1' > [...] > > Notice: > In the log "Downloading > file:/media/gvkalra/66bef40b-d84f-4ad0-ada6-a025b494ca5d/seesv-distro/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/seesv-embedded-qt5-image/1.0-r0/oe-roo", > bitbake didn't finish writing the whole path to the console. (I don't know > why) > > I have tried "bitbake -c cleansstate binutils" and rebuilding the image > (again same error) > > Previously when I faced this error, I deleted everything and started from > scratch (compiling everything) - it worked! > But it takes too long, so this time I thought it's best to discuss in the > mailing list. > > Any ideas of what could be the reason? > > PS: I am open to share any logs you'd like to have. > > -- > Gaurav Kalra > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto-Advocacy] Yocto Project Upcoming Conferences and Developer Days
Howdy! On Sun, May 05, 2019 at 05:07:30PM -0700, Behan Webster wrote: > If community building is the plan please don’t exclude OpenEmbedded from the > name nor the material (in other words, acknowledging which parts are from > OpenEmbedded). Part of the community building aspect is going to have to be > acknowledging that Yocto Project is an umbrella project made up of other > projects, and then celebrating those projects. > > The original idea I put forward was to have a joint OpenEmbedded/Yocto > project 2-day event to replace the separate ypdd and OEDEM, not merely a > larger Yocto project event. > > I am personally already seeing a negative reaction to these plans from > others, which is IMHO sadly contributing to destroying community instead of > building it. > > I, personally, would like nothing more than a simpler way to describe the > whole thing. However as it stands we essentially have 2 camps that continue > to separate instead of coming together. Let’s try and fix that bit first. Completely agreed. I've personally never understood the (until now, mostly) friendly mutual heckling, but its a thing we have to cope with and sort out. The sooner, the better. > And I surely hope that things other than beer and wine are made available. > There are actually a lot of attendees who don’t drink from what I can tell, > which was made extremely evident to me in Edinburgh where the non alcoholic > options kept on running out and how much alcohol was left at the end of the > night. Wine and beer isn’t a draw for everyone anymore. Another point I'm just stepping up to fully support. We can run out of booze - its better if we don't but hey, we absolutely must not run out of water and coffee. Greetz PS: Yes, its actually *ME* writing that. > > Thanks, > > Behan > > Sent from my Mobile Computer which is also a phone > > > On May 3, 2019, at 11:01 AM, Volosincu, Andreea S > > wrote: > > > > Greetings, > > > > Yocto Project is pleased to announce the plans for the upcoming Embedded > > Linux Conferences in NA and Europe. > > > > Here is a snapshot of our schedule: > > > > ELC NA – Wednesday, August 21 - 23, 2019, Hilton San Diego Bayfront, San > > Diego, CA > >Yocto Project is a sponsor. We’ll see you on the show > > floor > > > > ELC NA Dev Day – Tuesday, August 20, 2019 - 8:00AM - 6:00PM > > Set-up: 1 Meeting Room - Classroom Seating ( 60 people) > > Level: Intermediate – Advanced. Participants will receive beginner material > > (videos and presentations) as pre-requisites > > Includes: Morning Break, Buffet Lunch, Beer & Wine Reception with light > > appetizers > > > > ELCE – Monday, October 28 -30, 2019, Lyon Convention Centre, Lyon, France > > Yocto Project is a sponsor. We’ll see you on the show floor > > > > ELCE Yocto Project Summit – Dates & Times: > > Thursday, October 31, 2019 - 8:00AM - 6:00PM > >November 1, 2019 - 8:00 am - 6:00PM > > Set-up: > > Day 1: 1 Meeting Room - Theater Seating for 100 for Yocto Project talks > > Day 2: 2 Meeting Rooms - Mixed Classroom/Theater seating for 60 & Classroom > > seating for 40 (for maintainers and users) > > Includes: > > Morning Break for 2 days > > Buffet Lunch for 2 days > > Beer & Wine Reception with light appetizers for 1 day > > The goal for the second day of the summit is to build and bring the > > community together. We are interested to hear your opinions and ideas on > > how that day and those rooms should be used for. Please send your ideas to > > Andreea Volosincu and Philip Balister. > > > > We will call out an Advocacy meeting in a couple of weeks to go over plans > > and vote on the ideas for the second day of the summit. > > > > Thanks! > > Andreea > > Yocto Project Advocacy Lead > > -- > > ___ > > yocto-advocacy mailing list > > yocto-advoc...@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto-advocacy > -- > ___ > yocto-advocacy mailing list > yocto-advoc...@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto-advocacy -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto-Advocacy] Yocto Project Upcoming Conferences and Developer Days
day of the summit is to build and bring the > > community together. We are interested to hear your opinions and ideas on > > how that day and those rooms should be used for. Please send your ideas to > > Andreea Volosincu and Philip Balister. > > > > We will call out an Advocacy meeting in a couple of weeks to go over plans > > and vote on the ideas for the second day of the summit. > > > > Thanks! > > Andreea > > Yocto Project Advocacy Lead > > > > > > > > > > -- > > ___ > > yocto-advocacy mailing list > > yocto-advoc...@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto-advocacy > -- > ___ > yocto-advocacy mailing list > yocto-advoc...@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto-advocacy -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to make writable permission for home/root in read-only rootfs (yocto build)
Hello, On Tue, Mar 19, 2019 at 03:56:00PM +0530, Arunkumar V wrote: > HI > > can any one explain me how to config the /home/root as writable in > read-only rootfs? > > is any setting to do with local file or .bbclass? > if any macros need to be enable, please No, it does not work like this on a directory based approach. General Linux concepts regarding filesystems permissions apply, so its basically an all-or-nothing thing. Having said that, please find some inspiration in this thread: https://lists.yoctoproject.org/pipermail/yocto/2019-February/044166.html Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] npm offline build for yocto
Hi Jan, On Thu, Mar 07, 2019 at 10:37:26AM +0100, Jan Kiszka wrote: > Hi Michael, > > I found your progress report (and unanswered question) on that topic in > http://lists.openembedded.org/pipermail/openembedded-core/2018-April/268639.html. > Did this effort go further? > > I just ran into it again while updating > https://github.com/siemens/meta-iot2000 to Node.js >v6. I also played with > prefilling the cache, but likely in the wrong way. We've had our share of fun ourselves by now, especially with the event-stream module being hijacked and removed. To my knowledge none of the existing nodejs package managers (npm, yarn, ...) do support pure fetching neither explicit caching. The only thing that seems to be mostly working fine is using an explicit caching proxy like lazy-npm to externally cache the remote repositories. Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Make one directory writeable
Hi Bhupendra, On Wed, Feb 13, 2019 at 12:51:17PM +0530, Bhupendra Singh wrote: > Hello > > I have built core-image-minimal with read only rootfs then now I want to > make one directory (like /mnt) writable. > > Is it possible to make one directory writeable in read only rootfs if yes > ,please tell me how can I do same. This is not exactly yocto specific, general linux concepts apply. You can use a secondary, tertiary, ... partition or starage device and then mount that as read-write. But it always has to be a seperate filesystem. There is no way to make only one path of a given filesystem RW, it always means that the whole filesystem is writeable. Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] am335x evmsk screen init:id"00" respawning too fast disabled for 5 minutes yocto sumo
Howdy! On Wed, Nov 28, 2018 at 03:50:02PM +, n.stanisavlje...@polycaptil.fr wrote: > Hello everybody > > here is an introduction of my situation : > > I build a custom board from schematic of sitara AM335x-evmsk starter kit. > I succeed to make a custom OS with yocto (krogoth version) and to boot this > OS (embedded Linux) on my custom board. > > This custom board contain a touchscreen (same touchscreen like in the > AM335x-evmsk starter kit). > > All worked fine on this board while I used krogoth version on yocto. > > my problem : > > Few time ago, I decided to migrate to sumo version of yocto. > I build with success the OS (embedded Linux) with yocto sumo version for my > custom board, but when I try to boot this OS, it's stop/lock and print the > following message : > > "INIT:Id'00' respawning too fast : disabled for 5 minutes" (I put a > screenshot of this message ridden on putty). > Every 5 minutes I got this message and I can't acces to the user session on > putty and on the touchscreen, all board is locked. This is probably because you are basing off something that sets SERIAL_CONSOLES for the yocto-kernel, like http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf?h=master#n23 If you are using a custom tree which does not use the special driver for the uart, then you should be fine by setting SERIAL_CONSOLES ?= "115200;ttyS0" in your MACHINE config > > I don't understand why this problem appear when I build a OS with the sumo > version on Yocto. > I have not this problem when I build a OS with the krogoth version on yocto. > > Somebody can help me to solve this problem ? > what can I do ? > Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Git tool/command problems with YOCTO Open Source repos
it is quite independent how the layers (and many are proprietary layers) > > are built. So you can use "repo" or "kas" (my preferred one) for that. > > > > Best regards, > > Stefano Babic > > > > -- > > = > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > > = > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] /boot/ content into root filesystem?
Hi Tim, On Wed, Jun 13, 2018 at 11:57:10PM -0400, Tim Hammer wrote: > I would like to include the kernel Image and DTB files in the /boot/ > directory of the root filesystem that will be installed in flash memory ( > *vs.* a separate partition with the /boot/ content). IMAGE_INSTALL += "kernel kernel-devicetree" should do that neatly. See also: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n548 and https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-devicetree.bbclass#n6 Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Getting the version of Yocto that is being used.
On Thu, Apr 12, 2018 at 01:11:17PM +0100, Richard Collins wrote: > I get the following for DISTRO. > > DISTRO= "yogurt" > DISTRO_VERSION= "BSP-Yocto-RK3288-PD17.1.1" > For further reference by anyone who is reading this in the archive: the supplier is Phytec, and the distro layer is here: https://git.phytec.de/meta-yogurt/ Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Quick hack for compiling old and outdated YOCTO Jethro for Renesas iwg20m
Howdy! On Mon, Mar 19, 2018 at 05:38:47PM +0100, Zoran Stojsavljevic wrote: > [vuser@localhost conf]$ bitbake core-image-minimal > WARNING: Host distribution "Fedora-27" has not been validated with this > version of the build system; you may possibly experience unexpected > failures. It is recommended that you use a tested distribution. > > My question is: does anybody know quick hack how to fix this error? The first, simplest and most obvious would be to try and build with a supported distro. Just fire up some generic debian/ubuntu docker and see what happens. Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][Meta-Raspberrypi] Yocto apt sources.list for Raspberry Pi
Hello! On Sun, Feb 25, 2018 at 09:38:52PM +0800, Laigui Qin wrote: > I am building the GNU Linux with Yocto for Raspberry Pi using > meta-raspberrypi. Everything is good (with help of google search and yocto > manual) until I added apt support to the image. As I am a little confused > which Repository URL I should put in the sources.list, I tried the Raspbian > repository. However, when I do apt-get upgrade I got following error which is > not expected. Any idea on this effort? Unless you are planning to run your own repository server: none. There is certainly support for doing that, look for topic on "package feeds" in the Yocto documentation. Your snippet below looks like you are trying to use the raspbian repositories, which certainly won't work. You have to understand that what you have built is *NOT* a replacement for a raspbian installation that will just fill in - it is a whole separated, custom distribution and in no way related to any package repository thats out there. So if you actually want to use those, then you have also to use their base distribution. If you want to stick with Yocto, your two choices are: - just include everything you need in the build. (thats the common one) - run a custom package feed server (can be done, but probably you're better off with already existing solutions then. Greetz Joe > > root@raspberrypi-cm3:~# sudo apt-get upgrade > Reading package lists... Done > Building dependency tree > Reading state information... Done > Calculating upgrade... Done > The following packages have been kept back: > base-files cpp diffutils g++ gcc git initscripts libcap2 libgcc1 libgmp10 > libsysfs2 libusb-1.0-0 libwbclient0 netcat ntp procps samba-common usbutils > The following packages will be upgraded: > busybox ethtool sysfsutils > 3 upgraded, 0 newly installed, 0 to remove and 18 not upgraded. > Need to get 562 kB of archives. > After this operation, 1114 kB of additional disk space will be used. > Do you want to continue? [Y/n] > Get:1 http://archive.raspbian.org/raspbian wheezy/main armhf busybox armhf > 1:1.20.0-7 [438 kB] > Get:2 http://archive.raspbian.org/raspbian wheezy/main armhf ethtool armhf > 1:3.4.2-1 [98.7 kB] > Get:3 http://archive.raspbian.org/raspbian wheezy/main armhf sysfsutils armhf > 2.1.0+repack-2 [24.5 kB] > Fetched 562 kB in 5s (96.0 kB/s) > (Reading database ... 16225 files and directories currently installed.) > Preparing to unpack .../busybox_1%3a1.20.0-7_armhf.deb ... > Unpacking busybox (1:1.20.0-7) over (1.24.1-r0) ... > dpkg-deb (subprocess): unable to execute tar (tar): No such file or directory > dpkg-deb: error: subprocess tar returned error exit status 2 > dpkg: error processing archive > /var/cache/apt/archives/ethtool_1%3a3.4.2-1_armhf.deb (--unpack): > subprocess dpkg-deb --control returned error exit status 2 > dpkg-deb (subprocess): unable to execute tar (tar): No such file or directory > dpkg-deb: error: subprocess tar returned error exit status 2 > dpkg: error processing archive > /var/cache/apt/archives/sysfsutils_2.1.0+repack-2_armhf.deb (--unpack): > subprocess dpkg-deb --control returned error exit status 2 > Errors were encountered while processing: > /var/cache/apt/archives/ethtool_1%3a3.4.2-1_armhf.deb > /var/cache/apt/archives/sysfsutils_2.1.0+repack-2_armhf.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] tiny-linux distribution with raspberrypi error
On Fri, Nov 17, 2017 at 05:36:33PM +0100, Zoran Stojsavljevic wrote: > Let me redefine the question? May I? Of course you may. > > What is the difference while building an IMAGE="core-image-minimal" > using DISTRO="poky-tiny" > versus building an IMAGE="core-image-minimal" using DISTRO="poky"? If you look at http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky-tiny.conf then everything is laid out nicely. Running throuhg the most important parts: - it includes poky.conf, so it directly derives from it -> it just modifies some parts - it selects musl, not glibc - it selects busybox init There's some more tweaks around, but I think those are the major ones. Just read the .conf for more details. Greetz ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] tiny-linux distribution with raspberrypi error
On Fri, Nov 17, 2017 at 07:27:27AM +0100, Zoran Stojsavljevic wrote: > > DISTRO = "poky-tiny" and i get the following > > What is the difference between core-image-minimal and poky-tiny? core-image-minimal is a IMAGE poky-tiny is a DISTRO Its just different things. ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2] devtool: add clean command
Add an idiomatic way to devtool to clean a recipe. When using devtool
in the context of an eSDK there is no direct access to bitbake.
This command exposes the bitbake clean facility through devtool,
keeping the idiomatic interface and configurability.
Signed-off-by: Josef Holzmayr <holzm...@rsi-elektrotechnik.de>
---
scripts/lib/devtool/clean.py | 48
1 file changed, 48 insertions(+)
create mode 100644 scripts/lib/devtool/clean.py
diff --git a/scripts/lib/devtool/clean.py b/scripts/lib/devtool/clean.py
new file mode 100644
index 00..473c30f366
--- /dev/null
+++ b/scripts/lib/devtool/clean.py
@@ -0,0 +1,48 @@
+# Development tool - clean command plugin
+#
+# Copyright (C) 2014-2015 Intel Corporation
+# 2017 R-S-I Elektrotechnik GmbH & Co. KG
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+"""Devtool clean plugin"""
+
+import bb
+from devtool import exec_build_env_command, check_workspace_recipe
+
+def _get_clean_tasks(config):
+tasks = config.get('Clean', 'clean_task', 'clean').split(',')
+return ['do_%s' % task.strip() for task in tasks]
+
+def clean(args, config, basepath, workspace):
+"""Entry point for the devtool 'clean' subcommand"""
+
+build_tasks = _get_clean_tasks(config)
+try:
+bbargs = []
+for task in build_tasks:
+bbargs.append('%s:%s' % (args.recipename, task))
+exec_build_env_command(config.init_path, basepath, 'bitbake %s' % '
'.join(bbargs), watch=True)
+except bb.process.ExecutionError as e:
+# We've already seen the output since watch=True, so just ensure we
return something to the user
+return e.exitcode
+
+return 0
+
+def register_commands(subparsers, context):
+"""Register devtool subcommands from this plugin"""
+parser_build = subparsers.add_parser('clean', help='Clean a recipe',
+ description='Cleans the specified
recipe using bitbake',
+ group='working', order=50)
+parser_build.add_argument('recipename', help='Recipe to clean')
+parser_build.set_defaults(func=clean)
--
2.14.3
--
_
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] devtool: add clean command
Add an idiomatic way to devtool to clean a recipe.
Signed-off-by: Josef Holzmayr <holzm...@rsi-elektrotechnik.de>
---
scripts/lib/devtool/clean.py | 48
1 file changed, 48 insertions(+)
create mode 100644 scripts/lib/devtool/clean.py
diff --git a/scripts/lib/devtool/clean.py b/scripts/lib/devtool/clean.py
new file mode 100644
index 000..30f4044
--- /dev/null
+++ b/scripts/lib/devtool/clean.py
@@ -0,0 +1,48 @@
+# Development tool - clean command plugin
+#
+# Copyright (C) 2014-2015 Intel Corporation
+# 2017 R-S-I Elektrotechnik GmbH & Co. KG
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+"""Devtool clean plugin"""
+
+import bb
+from devtool import exec_build_env_command, check_workspace_recipe
+
+def _get_build_tasks(config):
+tasks = config.get('Clean', 'clean_task', 'clean').split(',')
+return ['do_%s' % task.strip() for task in tasks]
+
+def clean(args, config, basepath, workspace):
+"""Entry point for the devtool 'clean' subcommand"""
+
+build_tasks = _get_build_tasks(config)
+try:
+bbargs = []
+for task in build_tasks:
+bbargs.append('%s:%s' % (args.recipename, task))
+exec_build_env_command(config.init_path, basepath, 'bitbake %s' % '
'.join(bbargs), watch=True)
+except bb.process.ExecutionError as e:
+# We've already seen the output since watch=True, so just ensure we
return something to the user
+return e.exitcode
+
+return 0
+
+def register_commands(subparsers, context):
+"""Register devtool subcommands from this plugin"""
+parser_build = subparsers.add_parser('clean', help='Clean a recipe',
+ description='Cleans the specified
recipe using bitbake',
+ group='working', order=50)
+parser_build.add_argument('recipename', help='Recipe to clean')
+parser_build.set_defaults(func=clean)
--
2.7.4
--
_
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Image with custom directory layout
Hi On 12.10.2017 20:47, Ayoub Zaki wrote: Hi, On 12.10.2017 20:34, Josef Holzmayr wrote: Hi On 12.10.2017 19:07, Ayoub Zaki wrote: Hi, I would like to generate an image that contains a custom directories layout for expl: foo/ ├── bar1 │ └── bar2 │ ├── config │ └── data └── work └── var └── lib ├── config └── data It should contains only those directories an nothing else, is there anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND. Should be possible if your image installs only your specific recipes that populate those directories. Means: no packagegroup-core-boot, no base-passwd, no -> then nothing should bring along other directories. I tried that but it does pull other packages even if I set in my image: IMAGE_FEATURES = "" IMAGE_LINGUAS = "" PACKAGE_INSTALL = "my-layout-recipe" Regards Probably you're inheriting from some more complex image class that pulls in the undesired packages. Have you already checked bitbake -e to see how the variables get expanded? Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Image with custom directory layout
Hi On 12.10.2017 19:07, Ayoub Zaki wrote: Hi, I would like to generate an image that contains a custom directories layout for expl: foo/ ├── bar1 │ └── bar2 │ ├── config │ └── data └── work └── var └── lib ├── config └── data It should contains only those directories an nothing else, is there anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND. Should be possible if your image installs only your specific recipes that populate those directories. Means: no packagegroup-core-boot, no base-passwd, no -> then nothing should bring along other directories. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding support for yum in a yocto image
Hi! On 05.10.2017 20:30, Mark Hieber wrote: I am building a yocto image to run on a network device, and I need to have yum installed in the image. Is this even possible? Technically, yes. But you'll have to create the support for yourself. The currently supported frontend for RPM is dnf (which has replaced smart) and probably will not change very soon. So the more practical answer is: no, not really. I would also like to have the epel-release repository available in my image. Uhm. Be aware that your custom built distribution is *not* some kind of Fedora-Light. Its an entirely different distribution, and mixing in repositories from somewhere is most certainly disastrous - or do you think using that OpenSuse repo plays along nicely with your CentOS install? :-) So if you want additional software that is not packaged yet as an OpenEmbedded recipe, the way to archieve that is writing the recipes. Plus, rolling your own package server if you want runtime package management, of course. But there already stuff prepared and should be easy to find in the docs. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)
I don't have the slightest clue why this message was delayed so much. As it might sound now like parodizing the ongoing efforts, please ignore/disregard. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)
Hi Bryan, On 26.09.2017 19:16, Bryan Evenson wrote: Due to what our IT department can support, I am issued a Windows laptop for development. In the past I have used VMWare to make a Linux virtual machine for my Yocto Project based image builds and application development. We are starting to get Windows 10 laptops so I am evaluating doing my builds using the Windows Subsystem for Linux (WSL) by building a poky/morty image. Overall it seems to be working. I've had an issue that I've worked through and other issues that I'm not quite sure what is going on. There's obviously a lot of stuff that the WSL does not support (yet) which is often filesystems or API limitations. I ran into a list of things that they officially marked as known good/bad, but I can't find it right now. If it shows up again, I'll forward it. For the time being, I think you might be better off looking at CROPS [1] which is the "offical" recommendation to buld on Windows/OSX, as far as I can see. Greetz [1] https://wiki.yoctoproject.org/wiki/TipsAndTricks/CropsCLIContainers -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to strip down my Yocto Linux?
Hi! At the moment it like this: On 02.08.2017 11:47, Bacheh Karaji wrote: > I bitbake the image "core-image-base"/. You start out with a already big image setup. IMAGE_INSTALL_append = " poco nginx canutils vsftpd curl fcgi spawn-fcgi net-snmp util-linux ubiattach-klibc ubimkvol-klibc ubiformat-klibc minicom net-tools zeroconf avahi-autoipd mtd-utils u-boot-fw-utils ethtool" And then you add even more stuff. After that, you want to remove lots of it again. While that maybe technically works, its pretty pointless. You first waste a lot of compilation time in generating stuff, which you then need additional time to remove again. The correct approach is to create an image recipe that exactly fits your needs. Usually one would start out with core-image-minimal.bb, copy that to your-cool-image.bb, and then add the additionally wanted packages in there. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Icecc configuration on mpich ?
On 28.07.2017 08:30, Riko Ho wrote: but have no idea on how to use it yet ? This usually is helped by reading the manual. Or the links that I already provided. As a last hint for now, let me rephrase and simplify the short description from icecc itself: icecc is a daemon that can accept compile jobs over the network. That should tell you that you probably don't use it directly, right? -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Icecc configuration on mpich ?
On 28.07.2017 08:17, Riko Ho wrote: icecc.bbclass on Yocto manual, but I'm not sure on how to use it yet ? to me, the description in https://stackoverflow.com/questions/14472175/distributed-compile-with-bitbake looks pretty good - for the bitbake side of things. Setting up icecc, again, is distribution specific (according to themselves, see https://github.com/icecc/icecream/blob/master/README.md#installation). -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Icecc configuration on mpich ?
On 28.07.2017 07:56, Riko Ho wrote: How can I port it to MPICH ? Easy, just do a complete rewrite of the compiler infrastructure :-) Or did you actually mean "how can I install" instead of "how can I port"? In that case, the answer is "Not at all." Seriously, icecc/distcc have absolutely nothing to do with mpich(or any other comparable mpi/hpc framework). You are mixing up an awful lot of buzzwords, what is running where and doing what. If you want to speed up bitbake by using multiple boxes, icecc is your choice. Follow its own installation procedures for getting started. mpich seems to be a framwork/infrastructure for hpc applications, which is something completely different. And generally, all this shbang is not worth the effort. Are you really running multiple hours of builds per day? Would shaving off a couple of percent from the compilation provide any gain? Mind, its only the compilation that can be distributed. Not the whole rest that actually makes up the magic of a bitbake build. -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Crosscompile packages (ipk) based on SDK
On 27.07.2017 18:55, Manuel Geeler wrote: I only got the standard SDK. Are the information I need for building my own yocto installation matching the target somewhere hidden in the SDK? Nope, the standard SDK is actually only little more than a compiler toolchain plus sysroot. You have to ask whomever supplied the hardware to you for proper build instructions respectively sources. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Mpich and yocto ?
Hi On 26.07.2017 05:12, Riko Ho wrote: Does anyone know on how to run poky on mpich cluster ? As far as I can see, MPICH is a userland library, basically. So it would be the other way round, you could probably run a mpich application on a number of nodes that run some OE/Poky thing. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Install rootfs.tar.bz2 to ${D}/home/root/
On 11.04.2017 08:48, Maier, Chris wrote: > Hi, > The usual question > > Chris > *sigh* I've tried to get in touch via non-list email (as for overly aggressive mail servers), and even called the company but you didn't pick up the phone. So Chris - if you ever read this: I really tried. Obviously there's no other choice than bluntly ignoring this topic. Greetz, -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Install rootfs.tar.bz2 to ${D}/home/root/
On 06.04.2017 10:31, Maier, Chris wrote:
Hi,
I want to create a deployable SD card image. My board (beaglebone based)
boots from SD card and runs a script which copies the rootfs.tar.bz2 to
the flash memory.
So how can I deploy a copy of the whole rootfs to ${D}/home/root?
A rootfs in the rootfs, does that make sense?
Any help is appreciated.
Chris
*i.A. **Chris Maier *
*Software-Entwicklungsingenieur *
Phone: +49 7152 203 6741 | Fax: +49 7152 203 76741 | c.ma...@geze.com
GEZE GmbH, Reinhold-Vöster-Straße 21-29, 71229 Leonberg | www.geze.com
SAVE PAPER - THINK BEFORE YOU PRINT
YouTube <https://www.youtube.com/user/BewegungmitSystem> Facebook
<https://de-de.facebook.com/pages/GEZE-GmbH/733688069983321> LinkedIn
<https://www.linkedin.com/company/geze-gmbh> Twitter
<https://twitter.com/geze_gmbh> Xing
<https://www.xing.com/companies/gezegmbh> Geschäftsführung: Brigitte
Vöster-Alber (Vorsitzende), Andrea Alexandra Alber, Marc Alber, Florian
Birkenmayer
Vorsitzender des Aufsichtsrates: Prof. Dr. Dr. Ulli Arnold, Amtsgericht
Stuttgart HRB 250329, Tel: +49 7152 203 0
GEZE GmbH, Reinhold-Vöster-Straße 21-29, 71229 Leonberg, Germany
Why are you asking the exact same question the third time now?
--
Josef Holzmayr
Software Developer Embedded Systems
Tel: +49 8444 9204-48
Fax: +49 8444 9204-50
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Install rootfs.tar.bz2 to ${D}/home/root/
Hi,
On 06.04.2017 08:41, Maier, Chris wrote:
Hi,
I want to create a deployable SD card image. My board (beaglebone based)
boots from SD card and runs a script which copies the rootfs.tar.bz2 to
the flash memory.
So how can I deploy a copy of the whole rootfs to ${D}/home/root?
A rootfs in the rootfs, does that make sense?
Partially. Sounds like you want to invent your own update mechanism.
Have you had a look at the already existing ones, specifically swupdate?
Greetz
--
Josef Holzmayr
Software Developer Embedded Systems
Tel: +49 8444 9204-48
Fax: +49 8444 9204-50
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] should a BSP layer *really* ever need additional layers to be functional?
Hi, On 23.03.2017 11:35, Robert P. J. Day wrote: i always thought that using nothing more than a BSP layer (plus, of course, the underlying OE layers) should allow you to get to the command line. is that not true? I don't think that this generally holds true, as it would lead to significant duplication. Imagine a board based off something already in meta-ti or meta-intel. And maybe just needing a slightly modified bootloader. Greetz, -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Missing or unbuildable dependency chain
Hi. On 17.03.2017 13:10, ravikiran j wrote: for this error which layer i needs to be added ? As I already explicitly linked to the layerindex, here is another example of its usefulness: https://layers.openembedded.org/layerindex/recipe/47350/ Please understand that I probably won't respond another time to things that are trivially solvable through information that I already provided. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Sum up - Proposal: dealing with language-specific build tools/dependency management tools
I'll give it a shot and try to sum up the current state of affairs in this discussion. In accordance to the "Package managers all the way down"-presentation, I'm gonna use the term LPM (for language package manager) for now on. *Requirements* - repeatable and verifyable licensing of all dependencies that a LPM pulls in. - locking down specific versions of packages and their dependencies for reproductible builds. *Optionals* - strict separation of fetch, compile, install stages. If a specifc LPM requires it, those might be intermingled or left out [Mark] - opaque packaging: similar to static linking, we should at least have a way to bundle up a complete application into a single package. Maybe it might even be the default (like rust does it at the moment). - leverage as much as possible of the functionality the LPMs provide instead of reimplementing it. *Wish List* - separating out the LPM infrastructure into one or more distinct layers, not treating it as OE/bitbake core functionality. [Paul] - support for the use of multiple languages/LPMs inside a single recipe, hopefully even package. [myself] *Proposed Solutions* - having lockdown files shipped with the recipes (in whatever form to be defined) - leveraging the recipe system to resolve licensing. If we can boil things down to the common set that we all expect, it will in my opnion serve as a blueprint for the actual implementation to follow. Greetz, -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: core-image-minimal-xfce-1.0-r0 do_rootfs:
Again, please keep your responses on the list! On 16.03.2017 07:52, ravikiran j wrote: Suppose if i want to install some packages from debian or ubuntu repositories, how can i achieve that using rpm or ipk based distribution ? In short, not at all. This is not how things are meant to be. Just because something comes in a package of a specific format, it does not mean that you can use it everywhere the package management uses the same format. The correct way is to write recipes for the things that you want and properly package them up using bitbake. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: core-image-minimal-xfce-1.0-r0 do_rootfs:
Hi, On 16.03.2017 07:21, ravikiran j wrote: I am able to build the*core-image-minimal-xfce* image with *rpm *package management but , if i change the package-management from*rpm to deb* in local.conf file i am getting followling errors. the deb-based package manager sees little testing in general and is known to have some issues. Better just stick with rpm - or use ipk, if you want something that feels more debianoid. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] List of packages in image and their Licenses
Hi, On 15.03.2017 09:42, Keskinarkaus, Teemu wrote: I know that there is bitbake command/option to get list of all packages available, but how would I get a list of packages that goes to any specific image? And is there a way to get what Licenses those packages are using? look at tmp/deploy/licenses/$YOURSPECIFICBUILD_$TIMESTAMP/license.manifest (with $YOURSEPCIFICBUILD basically being imagename-machine) Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] core-image-minimal-xfce error
Keep things on the list, please. On 14.03.2017 10:49, ravikiran j wrote: The version of xfce-power-manager in the krogoth branch is 1.4.4, not 1.6.0. Probably you are mixing up the revisions. How You are telling that*The version of xfce-power-manager in the krogoth branch is 1.4.4 ? By looking at: http://git.openembedded.org/meta-openembedded/tree/meta-xfce/recipes-xfce/xfce4-power-manager?h=krogoth * Fixing a layer revision means i need to change the file xfce4-power-manager.1.6.0.bb <http://xfce4-power-manager.1.6.0.bb> extension from 1.6.0 to 1.4.4 ? * No, it means that the checkouts of all layers you use (which obviously is at least meta-openembedded) have to match the version of poky that you use. Have a look at the branches. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] core-image-minimal-xfce error
On 14.03.2017 10:20, ravikiran j wrote:
I am using ubuntu 14.04 build system and Yocto 2.1.
You probably mean poky/OE 2.1, which is krogoth
ERROR: ExpansionError during parsing
/home/mistral/yocto/poky/meta-openembedded/meta-xfce/recipes-xfce/xfce4-power-manager/xfce4-power-manager_1.6.0.bb
<http://xfce4-power-manager_1.6.0.bb>: Failure expanding variable
PACKAGECONFIG, expression was ${@bb.utils.filter('DISTRO_FEATURES',
'systemd', d)} which triggered exception AttributeError: 'module' object
has no attribute 'filter'
The version of xfce-power-manager in the krogoth branch is 1.4.4, not
1.6.0. Probably you are mixing up the revisions.
What is the problem and how to solve this problem ?
Version mismatch, fix your layer revisions.
Greetz
--
Josef Holzmayr
Software Developer Embedded Systems
Tel: +49 8444 9204-48
Fax: +49 8444 9204-50
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Proposal: dealing with language-specific build tools/dependency management tools
Hi Trevor, On 10.03.2017 21:49, Trevor Woerner wrote: Although the trend is to not care about licensing, I believe it is vitally important that we do our best to keep track of all the licensing from every package that is pulled into an image. If we're pulling in >1000 npm packages just for one node app, then that means we should have >1000 item list of each dependency and their respective licenses. Although it makes a recipe look ugly, I wouldn't want to drop this functionality due to aesthetic concerns. Maybe the license list could be moved to another file that is required by the "main" recipe file? Maybe the list could be moved to the bottom of the file? Boiling that down, it sounds to me like the approach is the following: 1) Let the sub-package manager do its work as its meant to be. 2) If the sub-package manager supports version lockdown/shrinkwrapping. it shall be used. 3) The OE build process is only meant to take care of licensing. (This could basically be seen as an additional Option 0 to the mail from yesterday: License-only recipes. [1]) Sounds like an interesting option indeed. Keeping it in the recipe means, in an abstract manner, that we need support for sub-licensing. Might be a viable route to go . In the case of node specifically, I don't think trying to create and maintain separate recipes for each and every dependency one might find in the npm registry would be a sane approach. Currently we embed the version info into the recipe filename. This will simply not scale to millions of npm packages, each with numerous versions. It will not scale for human inspection. For metadata that is algorithmically generated and used, I personally don't think the sheer number is a killer argument. I've been playing with node a fair amount lately as it relates to OE and I have to say I've been quite impressed! These aren't easy things and I think there's a lot of good work happening. Totally agreed. But implicitly, we tend to see npm as the reference for such sub-package managers. Is this a good way? Alexanders approach was to find a concept that fits all such constructions. Maybe its also worthwhile to think along the opposite lines: Treat each and every of those sub-package managers completely on its own, with all its specialities? (And hope that their number stays low) Other than these (short-term?) issues devtool seems to be on the right track (?) It does, for example, generate a lockdown.json file and an npm-shrinkwrap.json file automatically. All we need is the package.json from the app developer, and that can be auto-generated via npm. I think we have to accept that node developers are going to want to develop on the target device itself, and when they're done they can hand us the package.json file which we can run devtool on which will generate the recipe for us. I'm not too convinced that this is a good way. Especially when it comes to node modules that contain some native code, this becomes very ugly. My experience is that auto-processing that stuff adds megabytes of clutter, while all that matters in the end is a binary that is a couple if kilobytes. So how would one tackle that? Carve that out as a separate recipe again? As a short-term work-around, I've simply been creating an image with node+npm, running it on the device, copying over the package.json file, running npm install against it, then collecting up all the extra stuff that gets added to my image (as a result), and bundling all that into a platform-specific "bin_package" (bbclass). It works, but it's a multi-step process. If I could cut out some of those steps (once things from [1] are fixed), it would be an improvement. Yeah, thats an option. I am rather providing custom compile and install stages, as the applications I'm working on have similar requisites, but I didn't want to go multi-step/binary. Greetz PS: being tired of typing sub-package manager again and again, how shall we call this? SPM? Application Package Managers (APM)? [1] http://lists.openembedded.org/pipermail/openembedded-architecture/2017-March/000489.html -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Proposal: dealing with language-specific build tools/dependency management tools
Hi Alexander, thanks for kicking off the topic, sounds like its kinda overdue. While I have no really good solution (d'oh!), please find below thoughts and bits and pieces about some of the points. *Recipes* My gut feeling say auto-generation of the recipes is a good way to go. Yet I am uncertain which set of functionality such an auto-generated recipe would provide. The obvious possibilities: Option 1: Only dependency/license tracking. Pro: provides exactly what it says - known and proven means to keep track of the dependencies and licenses. Contra: this would mean that we have a recipes that only do housekeeping, while the actual workload is taken care of in the main recipe. This seperation sounds like a massive headache Option 2: Full recipes Pro: would fit into the OE workflow. Contra: requires the sub-package managers to at least "play along". Think two applications having the same dependency. It would get installed once (globally/system-wide), and both applications have to use it. My interpretation is that this just is not how it works (looking at npm) Coming from there, one can go further, resulting in Option 1.5: Provide recipes for common base functionality. Those would have the all-in-one-locked-down approach, but are meant to be used as global dependencies. Example: the MEAN stack. Like its name says, it consist of 4 main pieces (-> possible recipes) which are needed by the application. Pro: reduces recipe number/bloat and makes dependencies readable. The mindset fits the classis 'library' thinking. Contra: the depending application would have to be packaged with the infrastructure in mind. So while the library recipes could rely on the locked down sub-package manager, the application would have to intently skip it and provide a custom installation. Which is an annyonce if you are application dev and packager in union - and a major pain point if you want to package some upstream application. *Lockdown* To me the approach sounds interesting, yet it comes with a couple of points to think about. - Feature set: having such a lockdown system implies/requires all sub-package managers to provide (at least) the functionality to fullfill the needs of the lockdown process/recreation. Is that something we can take for granted? - Multilanguage: imagine a package for example having some native go code, then nodejs bindings and then a npdejs application on top. How would that look like? Multiple lockdown files? What are the implications? *Sub-Package managers in general* We've seen the first (perl, php, python...) and second (npm, go, rust...) wave of those by now. A third one certainly will come one day. Taking a step back for a larger perspective, it sounds like what we actually need is some form of nested dependencies. Or scoped dependencies. Whatever we want to call it, because to me thats what it actually is. The dependencies we have now are always global. But especially the second wave things think different. Those sub-package managers do not care about the whole system. They care about their small part of it. So my interpretation is that we need to take that paradigm shift, and decide upon the actual implementation details afterwards. *Conclusion* Guess I raised more questions than I offered answers for. Sorry :-( Greetz (and try to enjoy the weekend) -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to setup apt-get to work togehter with the packages build with yocto?
Howdy! On 02.02.2017 09:26, s.jar...@esa-grimma.de wrote: > Hej > > I like to setup a central host for the packages build with yocto. The > goal is, that everyone can download the "new" packages from a server in > the local network. I am looking for a description how to archive that or > some tips to start from. Basically, you want to create a package feed. The mega manual contains a lot of bits and pieces (start here: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#building-images-for-more-than-one-machine). AFAICS the most common (and therefore best tested) packaging mechanisms are rpm and ipk, so maybe start with those. Also on a second note, you can look at what Angstrom does for example: it mainly is exactly what you want, an OE-based package feed. > This e-mail may contain confidential and/or privileged information. If > you are > not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and destroy this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this e-mail is > strictly > forbidden. I hereby inform you that I will not destroy the email, and that I will copy, distribute and/or disclose any information that I have received just as I wish. Greetz! -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
Hello Juro, first off, thanks for taking the kick, whatever its count is. On 12.12.2016 23:15, Bystricky, Juro wrote: Building of Zephyr images in Yocto can now be done fairly unobtrusively via a new layer "meta-zephyr" and specifying a new distro in local.conf: DISTRO="zephyr" Leaving out the poky/non-poky discussion, zephyr.conf currently contains an include for tune-cortexm3.conf which certainly should not be there, as it is machine specific. My local fix here is to create a warped version of qemuarm.conf named qemuarmm3.conf which fixes that. The repository for the meta-zephyr is here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta-zephyr. The new meta-zephyr layer contains several recipes to build (and run in QEMUs) various Zephyr tests. There is also a sample recipe to build Zephyr sample "philosophers" with instructions how to run it in QEMU. The instructions seem to be missing that poky-contrib/meta is also needed in the bblayers for the tune-cortexm3 include. The new meta-zephyr is work based on previous original work by Randy Witt and Richard Purdie, so it is actually a second kick at the can. Thanks to those too, of course. This is a work in progress, any feedback is appreciated. Feedback was above - do you also want patches? ;-) Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Libgfortran 6.2 doesn't compile
Hello David, Von: <yocto-boun...@yoctoproject.org> im Auftrag von david bensoussan <minip...@gmail.com> Datum: Samstag, 26. November 2016 um 14:32 An: "yocto@yoctoproject.org" <yocto@yoctoproject.org> Betreff: [yocto] Libgfortran 6.2 doesn't compile Hello, I am trying to compile libgfortran 6.2 on Yocto (Morty version) but can't. DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 'common-linux', 'common-glibc', 'i586-linux', 'common'] DEBUG: Executing shell function do_compile NOTE: make -j 8 MULTIBUILDTOP=/var/www/toaster/openembedded-core/build-toaster-2/tmp-glibc/work/i586-oe-linux/libgf$ /bin/bash ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgfortran/mk-sik-inc.sh 'i586-oe-linux-gfort$ /bin/bash ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgfortran/mk-srk-inc.sh 'i586-oe-linux-gfort$ /bin/bash ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgfortran/mk-kinds-h.sh 'i586-oe-linux-gfort$ grep '^#' < ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgfortran/c99_protos.h > c99_protos.inc cp ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgfortran/config/fpu-387.h fpu-target.h grep '^#define GFC_FPE_' < ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgfortran/../gcc/fortran/li$ grep '^#define GFC_FPE_' < ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgfortran/libgfortran.h >> $ grep '^#' < kinds.h > kinds.inc make all-am make[1]: Entering directory `/var/www/toaster/openembedded-core/build-toaster-2/tmp-glibc/work/i586-oe-linux/libgfo$ /bin/bash ./libtool --tag=CC --mode=compile i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/opene$ /bin/bash ./libtool --tag=CC --mode=compile i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/opene$ /bin/bash ./libtool --tag=CC --mode=compile i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/opene$ /bin/bash ./libtool --tag=CC --mode=compile i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/opene$ /bin/bash ./libtool --tag=CC --mode=compile i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/opene$ /bin/bash ./libtool --tag=CC --mode=compile i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/opene$ /bin/bash ./libtool --tag=CC --mode=compile i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/opene$ /bin/bash ./libtool --tag=CC --mode=compile i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/opene$ libtool: compile: i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/openembedded-core/build-toaster-2/$ libtool: compile: i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/openembedded-core/build-toaster-2/$ libtool: compile: i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/openembedded-core/build-toaster-2/$ libtool: compile: i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/openembedded-core/build-toaster-2/$ libtool: compile: i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/openembedded-core/build-toaster-2/$ libtool: compile: i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/openembedded-core/build-toaster-2/$ libtool: compile: i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/openembedded-core/build-toaster-2/$ libtool: compile: i586-oe-linux-gcc -m32 -march=i586 --sysroot=/var/www/toaster/openembedded-core/build-toaster-2/$ ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgfortran/runtime/backtrace.c:37:33: fatal error: back$ #include "backtrace-supported.h" ^ compilation terminated. make[1]: *** [backtrace.lo] Error 1 make[1]: *** Waiting for unfinished jobs Yes, lately libfortran has changed their own backtrace implementation for the generic one. I have default yocto configuration, I simply added: FORTRAN_forcevariable = ",fortran" to enable it. Am I doing something wrong or is it unstable? You are not doing wrong, the recipe is just broken at the moment. Unfortunately, the fix seems to be non-trivial and nobody has gotten round to do it yet. Basically the libgcc-recipe infrastructure has to be made libbacktrace-aware. The only workaround that I know of at the moment is to stick with a libgfortran version before the libbacktrace change, which should be anything from the 5.X gcc family. Greetz -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen w
[yocto] [RFC] Blubber, a tool to set up yocto/poky projects easily
Howdy! After looking more and more into yocto, one of the main issues for me is the process to set up a project properly, including all layers and conf options. Especially those which would be needed to set exactly the same way again and again every time somebody needs to reproduce a build. So I've come up with an idea: a small tool that can handle these things for me. And here it is for your enjoyment/use/abuse/comments: https://github.com/LetoThe2nd/blubber Short excerpt from the README: But be warned first. Blubber is still in pre-pre-pre-alpha stage (more like a proof of concept), and has the following defects/bugs/non-features: - Horribly bad python code (Yes, its really that bad. Blame me, its my first attempt to use that language) - No error checking whatsoever - Largely incomplete feature set - Did I already mention the utterly bad code? - Only supports git sources so far. Despite that, it can already do some magic: - Getting poky and layers from git, and checking out branches/tags/commits if needed - Accordingly setting up build/conf/bblayers.conf - Setting up build/conf/local.conf with a set of predefined options - Running arbitrary commands with proper shell setup (source-ed poky/oe-init-build-env) for the configured project. If anybody has feedback, just scream loudly. Or if anybody knows of a better solution making it all obsolete, please also scream. Thanks! Leto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFC] Blubber, a tool to set up yocto/poky projects easily
Hello Vali, Vali Cobelea valentin.cobe...@enea.com hat am 10. März 2014 um 12:05 geschrieben: Looks ok at a first look, but my first suggestion would be to start using the is operator instead of == when it comes to comparing strings. Otherwise using your way with == will crash if any of the variables (those sys.argv[]) are None (void). Thanks for the quick input! However, this is one of the very rare points I intently did that way, because of the difference in meaning from == to is (see http://stackoverflow.com/questions/1504717/why-does-comparing-strings-in-python-using-either-or-is-sometimes-produce). But I'm curious, how would one then properly compare the content of two strings? Checking both types first? Best regards, Vali Greetz Josef/Leto On 03/10/2014 12:59 PM, Josef Holzmayr wrote: Howdy! After looking more and more into yocto, one of the main issues for me is the process to set up a project properly, including all layers and conf options. Especially those which would be needed to set exactly the same way again and again every time somebody needs to reproduce a build. So I've come up with an idea: a small tool that can handle these things for me. And here it is for your enjoyment/use/abuse/comments: https://github.com/LetoThe2nd/blubber Short excerpt from the README: But be warned first. Blubber is still in pre-pre-pre-alpha stage (more like a proof of concept), and has the following defects/bugs/non-features: - Horribly bad python code (Yes, its really that bad. Blame me, its my first attempt to use that language) - No error checking whatsoever - Largely incomplete feature set - Did I already mention the utterly bad code? - Only supports git sources so far. Despite that, it can already do some magic: - Getting poky and layers from git, and checking out branches/tags/commits if needed - Accordingly setting up build/conf/bblayers.conf - Setting up build/conf/local.conf with a set of predefined options - Running arbitrary commands with proper shell setup (source-ed poky/oe-init-build-env) for the configured project. If anybody has feedback, just scream loudly. Or if anybody knows of a better solution making it all obsolete, please also scream. Thanks! Leto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFC] Blubber, a tool to set up yocto/poky projects easily
Hello Vali, Vali Cobelea valentin.cobe...@enea.com hat am 10. März 2014 um 12:20 geschrieben: The idea behind 'is' would be to have more safety and less crashes when one of the arguments, in your case, is empty (eg None). Well there are cases where I needed to compare strings that have been read in and then modified from two different sources (e.g., files). Hence in my understanding, they have the same content, but not the same id. So if I want to match their content only, I'd have to use == because is would give me false even if the content matches. This discussion can go over and over, is more a flavor thing: being pythonian or not. Agreed, with the exception of the above said. But you're right, I'll look into the topic and see if it can bring improvements. Thanks again for your input. Best regards, Vali Greetz Josef /Leto On 03/10/2014 01:11 PM, Josef Holzmayr wrote: Hello Vali, Vali Cobelea valentin.cobe...@enea.com hat am 10. März 2014 um 12:05 geschrieben: Looks ok at a first look, but my first suggestion would be to start using the is operator instead of == when it comes to comparing strings. Otherwise using your way with == will crash if any of the variables (those sys.argv[]) are None (void). Thanks for the quick input! However, this is one of the very rare points I intently did that way, because of the difference in meaning from == to is (see http://stackoverflow.com/questions/1504717/why-does-comparing-strings-in-python-using-either-or-is-sometimes-produce). But I'm curious, how would one then properly compare the content of two strings? Checking both types first? Best regards, Vali Greetz Josef/Leto On 03/10/2014 12:59 PM, Josef Holzmayr wrote: Howdy! After looking more and more into yocto, one of the main issues for me is the process to set up a project properly, including all layers and conf options. Especially those which would be needed to set exactly the same way again and again every time somebody needs to reproduce a build. So I've come up with an idea: a small tool that can handle these things for me. And here it is for your enjoyment/use/abuse/comments: https://github.com/LetoThe2nd/blubber Short excerpt from the README: But be warned first. Blubber is still in pre-pre-pre-alpha stage (more like a proof of concept), and has the following defects/bugs/non-features: - Horribly bad python code (Yes, its really that bad. Blame me, its my first attempt to use that language) - No error checking whatsoever - Largely incomplete feature set - Did I already mention the utterly bad code? - Only supports git sources so far. Despite that, it can already do some magic: - Getting poky and layers from git, and checking out branches/tags/commits if needed - Accordingly setting up build/conf/bblayers.conf - Setting up build/conf/local.conf with a set of predefined options - Running arbitrary commands with proper shell setup (source-ed poky/oe-init-build-env) for the configured project. If anybody has feedback, just scream loudly. Or if anybody knows of a better solution making it all obsolete, please also scream. Thanks! Leto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFC] Blubber, a tool to set up yocto/poky projects easily
Hello Alex, Alex J Lennon ajlen...@dynamicdevices.co.uk hat am 10. März 2014 um 12:43 geschrieben: fwiw I'd have thought myself that string comparison should be string comparison (==) as if you use an object identity comparison as a string comparison (is), you potentially introduce opaque problems when the strings are the same - i.e. same bytes of data - but the objects are not the same for whatever reason. I've interpreted it roughly the same so far, but they ValueError point seems to valid to me too (gah, I really know why I usually avoid dynamically typed languages!). But the solution for me in this context seems to be then to use something like: DUMMYSTRING = foobar def safestringcompare(stra, strb): return type(DUMMYSTRING) == type(stra) and type(stra) == type(strb) and stra == strb Cheers, Alex Greetz Josef/Leto This discussion can go over and over, is more a flavor thing: being pythonian or not. Agreed, with the exception of the above said. But you're right, I'll look into the topic and see if it can bring improvements. Thanks again for your input. Best regards, Vali Greetz Josef /Leto On 03/10/2014 01:11 PM, Josef Holzmayr wrote: Hello Vali, Vali Cobelea valentin.cobe...@enea.com hat am 10. März 2014 um 12:05 geschrieben: Looks ok at a first look, but my first suggestion would be to start using the is operator instead of == when it comes to comparing strings. Otherwise using your way with == will crash if any of the variables (those sys.argv[]) are None (void). Thanks for the quick input! However, this is one of the very rare points I intently did that way, because of the difference in meaning from == to is (see http://stackoverflow.com/questions/1504717/why-does-comparing-strings-in-python-using-either-or-is-sometimes-produce). But I'm curious, how would one then properly compare the content of two strings? Checking both types first? Best regards, Vali Greetz Josef/Leto On 03/10/2014 12:59 PM, Josef Holzmayr wrote: Howdy! After looking more and more into yocto, one of the main issues for me is the process to set up a project properly, including all layers and conf options. Especially those which would be needed to set exactly the same way again and again every time somebody needs to reproduce a build. So I've come up with an idea: a small tool that can handle these things for me. And here it is for your enjoyment/use/abuse/comments: https://github.com/LetoThe2nd/blubber Short excerpt from the README: But be warned first. Blubber is still in pre-pre-pre-alpha stage (more like a proof of concept), and has the following defects/bugs/non-features: - Horribly bad python code (Yes, its really that bad. Blame me, its my first attempt to use that language) - No error checking whatsoever - Largely incomplete feature set - Did I already mention the utterly bad code? - Only supports git sources so far. Despite that, it can already do some magic: - Getting poky and layers from git, and checking out branches/tags/commits if needed - Accordingly setting up build/conf/bblayers.conf - Setting up build/conf/local.conf with a set of predefined options - Running arbitrary commands with proper shell setup (source-ed poky/oe-init-build-env) for the configured project. If anybody has feedback, just scream loudly. Or if anybody knows of a better solution making it all obsolete, please also scream. Thanks! Leto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFC] Blubber, a tool to set up yocto/poky projects easily
Hello Chris Chris Larson clar...@kergoth.com hat am 10. März 2014 um 15:40 geschrieben: On Mon, Mar 10, 2014 at 5:02 AM, Josef Holzmayr jholzm...@the-exact-steps.net wrote: Hello Alex, Alex J Lennon ajlen...@dynamicdevices.co.uk hat am 10. März 2014 um 12:43 geschrieben: fwiw I'd have thought myself that string comparison should be string comparison (==) as if you use an object identity comparison as a string comparison (is), you potentially introduce opaque problems when the strings are the same - i.e. same bytes of data - but the objects are not the same for whatever reason. I've interpreted it roughly the same so far, but they ValueError point seems to valid to me too (gah, I really know why I usually avoid dynamically typed languages!). But the solution for me in this context seems to be then to use something like: DUMMYSTRING = foobar def safestringcompare(stra, strb): return type(DUMMYSTRING) == type(stra) and type(stra) == type(strb) and stra == strb Strings should be compared with ==, not is. And there's nothing that will explode if you compare against None with ==. Try it yourself. foo == None False Yes. You're right. Makes me feel even worse about my python knowledge, but at least it seems the topic is clarified now. Thanks for that! Greetz Josef/Leto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFC] Blubber, a tool to set up yocto/poky projects easily
Hello Marc, Marc Ferland ferla...@sonatest.com hat am 10. März 2014 um 16:52 geschrieben: On Mon, Mar 10, 2014 at 11:59:08AM +0100, Josef Holzmayr wrote: Howdy! After looking more and more into yocto, one of the main issues for me is the process to set up a project properly, including all layers and conf options. Especially those which would be needed to set exactly the same way again and again every time somebody needs to reproduce a build. So I've come up with an idea: a small tool that can handle these things for me. And here it is for your enjoyment/use/abuse/comments: You should have a look at the 'repo' tool from the android community. I think it already does part of what you're trying to do here. The freescale yocto bsp already uses repo: https://github.com/Freescale/fsl-community-bsp-platform Yes indeed, it is quite a nice tool for doing the first part of the job. Thanks for pointing out, will look into it more really soon. Cheers! Marc Greetz Josef/Leto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
