Re: [yocto] Yocto newbie: Need help with recipe
bug/qtlissajous/git-r0/git/main.cpp >>> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/phaselabel.cpp >>> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/phaselabel.h >>> ./qtlissajous-tools/usr/bin/lissajous_explorer >>> ./qtlissajous/usr/bin/.debug/lissajous_explorer >>> ./qtlissajous-tools.shlibdeps >>> >>> My qtlissajous_git.gg file is: >>> >>> --- >>> DESCRIPTION = "Explore Lissajous figures for Raspberry Pi" >>> SECTION = "games" >>> DEPENDS += "qtbase" >>> >>> PACKAGES = "${PN}" >>> >>> LICENSE = "MIT" >>> LIC_FILES_CHKSUM = >>> "file://LICENSE;md5=7e26fc87b2c255632232dc535ed2700b;sha256=c8ea5a5ce0ef734ec1d0be3e214bed71673f1ffc628fe86bbd055d61abd52cc8" >>> >>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" >>> >>> SRCREV = "${AUTOREV}" >>> SRC_URI = "git://gitlab.com/bhoel/qlissajousexplorer.git;protocol=https" >>> >>> S = "${WORKDIR}/git" >>> >>> require recipes-qt/qt5/qt5.inc >>> >>> FILES_${PN} = "${bindir}" >>> FILES_${PN}-dbg += "${bindir}/.debug" >>> >>> do_install() { >>> install -d ${D}/usr/bin >>> install -m 0755 lissajous_explorer ${D}/usr/bin >>> } >>> >>> RDEPENDS_${PN} = "qtbase-plugins" >>> --- >>> >>> Why is the release executable ending up in the tools tree? >>> Why is the debug executable ending up in the release tree? >>> Is this the right place to ask this kind of questions? >>> >>> Thank you >>> Berthold >>> -- >>> ___ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >>> >>> -- Rudolf J Streif CEO/CTO ibeeto 1.855.442.3386 x700 signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Downloading Git Archives
On 9/27/19 2:27 AM, Ross Burton wrote: > On 27/09/2019 05:33, Chuck Wolber wrote: >> I was hoping that there was an equally simple way of grabbing git >> repository packages from an Internet connected host without having a >> bitbake build cache them for me. > > The easy way is to get bitbake to do it for you. A git mirror tarball > is just a clone with a specific name and path, but the easy solution > is definitely to run bitbake --c fetchall on a machine with > connectivity and expose the DL_DIR to the builders. > > This is what the yocto autobuilder does, by the way. The workers > don't have connectivity to the outside internet, so the master does a > fetchall with the proxies configured to populate DL_DIR before the > workers do the actual build. > Same thing here. I run a build system instance that simply downloads all the sources and places them on a local mirror. The only thing to think about is that if you have different targets they might require different source packages albeit there is always a larger overlap of packages that are always required. However, it's not too big of a problem launching the 'fetcher' instance repeatedly with different target since only what's missing will of course be downloaded. Another layer of complexity is of course added if you work with different versions of YP and OE layers. I solve this with Gitlab and submodules. A target project is a repo in Gitlab and the YP/OE layers are submodules. Gitlab handles that quite nicely. :rjs - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700 signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Downloading Git Archives
Chuck, Unless I am missing something (which I cannot entirely rule out), the default PREMIRRORS should actually do what you want. For the poky distro configuration has this: PREMIRRORS ??= "\ bzr://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \ cvs://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \ git://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \ gitsm://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \ hg://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \ osc://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \ p4://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \ svn://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n" This causes the fetcher to intercept and translate all the SCM protocols into http downloads from the YP mirror. Since you are saying wget works for you this should actually automatically work for you. If you build system can at least download using http then bitbake --runall=fetch should download all the sources for you. Then you can disconnect the box from the Internet and start the build offline. :rjs On 9/26/19 8:06 PM, Chuck Wolber wrote: > Hi All, > > Our build environment is stuck behind a firewall with no access to the > Internet. When a Yocto build requires a new package, we normally > extract the URL from the failed build log and "wget" the package from > the upstream source, do our due diligence (checksums, etc), and then > add it to the server pointed to by ${LOCAL_MIRROR}. > > Obviously that procedure does not work so well when a git repository > needs to be fetched. We have tried various methods, but nothing seems > to work reliably. Our current method is an annoying hack involving a > virtual machine clone of the build server. > > I have searched far and wide, and cannot find any sort of procedure. > Can someone point me at a procedure for translating something like > git://git.yoctoproject.org/pseudo <http://git.yoctoproject.org/pseudo> > into a file we can store in our ${LOCAL_MIRROR}? > > Thank you, > > ..Ch:W.. > -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700 signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel modul install
Michael, You might want to share your recipe. Since do_install works on a private sysroot for your recipe it is unlikely that your module conflicts with a module with the same name from another recipe. You might install the module twice or you might have some leftovers from your development process. You might want to start with a clean environment: bitbake -c cleanall . :rjs On 8/26/19 7:15 AM, Michael Eichhorn wrote: > Dear all, > > i am new to yocto and i created a recipe for a kernel modul for my bt > and wifi chip. > it seems that everthing works, but in my do_install i receive an error: > ...is trying to install files into a shared area when those files > already exist... > My receipe is somehow producing an bluetooth.ko which is already > existing because > of my linux-mainline recipe. > What can i do? the relevant one is the one from my chip recipe. > > Best regards, > Michael > -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700 signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Make the service the last run in boot
Adding After=multi-user.target to the [Unit] section in your systemd service file should do what you want. :rjs On 8/1/19 4:08 AM, JH wrote: > The application requires network connection to communicate services > via Internet, it could only work if the network connection is ready, > so I really want to know which system servuce run at last I could put > it in the After statement. > > On 8/1/19, ChenQi wrote: >> On 08/01/2019 03:37 PM, JH wrote: >>> Hi, >>> >>> How can I find the systemd last run service I can put it in my network >>> application After=? >>> >>> I need my network application service to be run at last in boot, I >>> made After=connman and Requires=connman.service that did not work, >>> always failed in boot, I have to manually restart the network >>> application service which won't work in field operation. >> I'd suggest you find out what you network service actually require. >> >>> Searched from Internet, there is a blog Systemd: Run it last to create >>> a custom.target After=multi-user.target, and put my network >>> application service WantedBy=custom.target, that works well, but it is >>> a little bit cumbersome to configure customer.target in Yocto bb file, >>> enabling the customer.target is called systemctl isolate >>> custom.target, the /etc/systemd/system/default.target link needs be >>> changed to from multi-user.target to custom.target. I am not sure how >>> it could be done in do_install, appreciate your tips. >>> >>> Thank you. >>> >>> Kind regards, >>> >>> - JH >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto build failed to include service file in /deplogy/images/image.wic.gz
JH, To enable systemd service for your application your recipe needs to inherit the systemd class and install the service file in the proper directory. Here is what it should look like: inherit systemd SYSTEMD_SERVICE_${PN} = "my-app.service" SYSTEMD_AUTO_ENABLE = "enable" do_install_append () { install -d ${D}${systemd_system_unitdir} install -m 0644 ${S}/my-app.service ${D}${systemd_system_unitdir} } SYSTEMD_AUTO_ENABLE = "enable" is not strictly required as it is the default. If you don't want to enable your service by default set the variable to "disable". :rjs On 7/31/19 4:04 PM, JH wrote: > HI, > > I have been struggling to find a fix for missing service file, I found > another solution posted from the Internet to use FILES_${PN} += > "${systemd_system_unitdir}/dl-mgr.service" at the end of the bb file: > > install -d ${D}${systemd_system_unitdir} > install -m 0644 ${WORKDIR}/dl-mgr.service ${D}${systemd_system_unitdir} > > As well as this to the end of the .bb file > > FILES_${PN} += "${libexecdir}/dl-mgr.sh" > FILES_${PN} += "${systemd_system_unitdir}/dl-mgr.service" > > But I could not build it "unprased line FILES_${PN} += > "${systemd_system_unitdir}/dl-mgr.service", could anyone help please? > > Thank you. > > Kind regards, > > - JH -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta-raspberrypi
Hi Shravan, You need to checkout warrior from your meta-raspberrypi repo that you cloned. It looks as it is on the latest master. :rjs On 7/22/19 3:07 PM, Shravan Singh wrote: > Hello All, > > I am trying to create a base image for raspberry-pi cm3(compute module 3) > > I am using warrior-21.0.1 > I downloaded meta-raspberry-pi from > https://git.yoctoproject.org/git/meta-raspberrypi > I added the layer in bblayer.conf and I have changed the machine > variable in local.conf > to *raspberrypi-cm3* > I am using oe-init-build script to generate the base files > > Now when I run the command > bitbake core-image-base > > I get the below mentioned error > Error: No recipes available for: > /home/blue/yacto/meta-raspberrypi/recipes-bsp/u-boot/u-boot_2019.07.bbappend > /home/blue/yacto/meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.16%.bbappend > > > Any help with this? > > > Regards, > Shravan Singh > (239) 243-0838 > > Blue Sparq, Inc. > 928 NE 24th Lane unit 4 and 5. > Cape Coral, FL 33993 > > IMPORTANT: The contents of this email and any attachments are > confidential. They are intended for the named recipient(s) only. If > you have received this email by mistake, please notify the sender > immediately and do not disclose the contents to anyone or make copies > thereof. > -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PREMIRROR
You are very welcome. Enjoy working with YP. :rjs On 7/25/19 4:48 PM, Russell Peterson wrote: > Just tried the externalsrc feature. Works perfectly. Exactly what I > was looking for. Thanks so much, Rudolf! > > --Russ > > > On Thu, Jul 25, 2019 at 4:59 PM Rudolf J Streif > mailto:rudolf.str...@ibeeto.com>> wrote: > > Inlining below. > > On 7/25/19 8:14 AM, Russell Peterson wrote: >> I think I have a somewhat better understanding of what is going on. >> >> First off, I was confused by the fact that the original error >> message I saw from do_unpack referenced the file (URL) at >> DL_DIR/git2/original_github_url. What I didn't understand at the >> time was that while that file existed,/it was actually a link/ to >> DL_DIR/git2/local_url. So, do_unpack wasn't looking at the wrong >> bare repository as I thought. It was unhappy because it didn't >> see the git commit in the local repo that it was looking for. I >> use AUTOREV for SRCREV. Apparently, even with PREMIRROR set and >> matched, bitbake will still fetch the git HEAD commit hash from >> the original URL in the recipe. The local git repo doesn't >> contain that commit. When I sync the local git repo to the >> github repo things work as expected. > Correct. If the source repo or the correct commit cannot be found > from the PREMIRROR, bitbake will use SRC_URI from the recipe. You > can block that behavior by setting BB_NO_NETWORK = "1" in which > case bitbake will not be able to connect to any remote server. > However, that does not help if your PREMIRROR is a network server. > In this case use BB_ALLOWED_HOSTS to allow access to only the > servers you want. >> >> Here is my problem. What I am ultimately trying to do here is >> have 2 git repos. 1 public, 1 private. For internal development >> we use the private git repo (a local gerrit server). Just before >> we ship we update the public github repo. The recipe always >> points to the github (public) repo so we don't need to mess with >> that before a release. This way we can do nightly builds (I'm >> just talking nightly builds done by Jenkins... not developers >> using eSDK and devtool) and test. Customers using yocto will be >> given a recipe that points to github and, importantly, those >> customers that do NOT use yocto simply fetch the project from >> github and manually build it in their own environment with their >> own tools. >> > That is a common problem. I do this all the time. To do this add > to your conf/local.conf file: > > INHERIT += "externalsrc" > EXTERNALSRC_pn-myrecipe = "/path/to/source/tree" > > Alternatively, you could use a bbappend file for you recipe in a > development layer, myrecipe.bbappend: > > inherit externalsrc > EXTERNALSRC = "/path/to/source/tree" > > Now, that is exactly what devtool does for you but you can of > course do it manually. > > :rjs > > > >> I can't be the only one doing this. Is there a best practices >> here (private vs. public repo)? >> >> --Russ >> >> >> On Wed, Jul 24, 2019 at 3:55 PM Rudolf J Streif >> mailto:rudolf.str...@ibeeto.com>> wrote: >> >> Russell, >> >> That is exactly what devtool and the externalsrc class do. >> PREMIRROR is the wrong approach for that. >> >> :rjs >> >> On 7/24/19 12:53 PM, Russell Peterson wrote: >>> Hi, Rudolf. >>> >>> I apologize for not being clear. The idea here is that my >>> recipe points to github while, for my local development >>> environment, I set a premirror to match a specific github >>> repository and translate it to a local directory. That >>> works. The fetch matches the PREMIRROR and places a copy of >>> the LOCAL git repo in my DL_DIR. The problem is, the >>> do_unpack task is looking for the git repo in the DL_DIR >>> (git2/etc...)... but it's looking for the git repo from >>> github, not my local repo that the fetch task just put in >>> DL_DIR. >>> >>> There are numerous reasons I'm doing this including the fact >>> that I cannot put a reference to my local repo in the bb >>> file since I ship that recipe to my custo
Re: [yocto] PREMIRROR
Inlining below. On 7/25/19 8:14 AM, Russell Peterson wrote: > I think I have a somewhat better understanding of what is going on. > > First off, I was confused by the fact that the original error message > I saw from do_unpack referenced the file (URL) at > DL_DIR/git2/original_github_url. What I didn't understand at the time > was that while that file existed,/it was actually a link/ to > DL_DIR/git2/local_url. So, do_unpack wasn't looking at the wrong bare > repository as I thought. It was unhappy because it didn't see the git > commit in the local repo that it was looking for. I use AUTOREV for > SRCREV. Apparently, even with PREMIRROR set and matched, bitbake will > still fetch the git HEAD commit hash from the original URL in the > recipe. The local git repo doesn't contain that commit. When I sync > the local git repo to the github repo things work as expected. Correct. If the source repo or the correct commit cannot be found from the PREMIRROR, bitbake will use SRC_URI from the recipe. You can block that behavior by setting BB_NO_NETWORK = "1" in which case bitbake will not be able to connect to any remote server. However, that does not help if your PREMIRROR is a network server. In this case use BB_ALLOWED_HOSTS to allow access to only the servers you want. > > Here is my problem. What I am ultimately trying to do here is have 2 > git repos. 1 public, 1 private. For internal development we use the > private git repo (a local gerrit server). Just before we ship we > update the public github repo. The recipe always points to the github > (public) repo so we don't need to mess with that before a release. > This way we can do nightly builds (I'm just talking nightly builds > done by Jenkins... not developers using eSDK and devtool) and test. > Customers using yocto will be given a recipe that points to github > and, importantly, those customers that do NOT use yocto simply fetch > the project from github and manually build it in their own environment > with their own tools. > That is a common problem. I do this all the time. To do this add to your conf/local.conf file: INHERIT += "externalsrc" EXTERNALSRC_pn-myrecipe = "/path/to/source/tree" Alternatively, you could use a bbappend file for you recipe in a development layer, myrecipe.bbappend: inherit externalsrc EXTERNALSRC = "/path/to/source/tree" Now, that is exactly what devtool does for you but you can of course do it manually. :rjs > I can't be the only one doing this. Is there a best practices here > (private vs. public repo)? > > --Russ > > > On Wed, Jul 24, 2019 at 3:55 PM Rudolf J Streif > mailto:rudolf.str...@ibeeto.com>> wrote: > > Russell, > > That is exactly what devtool and the externalsrc class do. > PREMIRROR is the wrong approach for that. > > :rjs > > On 7/24/19 12:53 PM, Russell Peterson wrote: >> Hi, Rudolf. >> >> I apologize for not being clear. The idea here is that my recipe >> points to github while, for my local development environment, I >> set a premirror to match a specific github repository and >> translate it to a local directory. That works. The fetch >> matches the PREMIRROR and places a copy of the LOCAL git repo in >> my DL_DIR. The problem is, the do_unpack task is looking for the >> git repo in the DL_DIR (git2/etc...)... but it's looking for the >> git repo from github, not my local repo that the fetch task just >> put in DL_DIR. >> >> There are numerous reasons I'm doing this including the fact that >> I cannot put a reference to my local repo in the bb file since I >> ship that recipe to my customers and a local pathname is >> meaningless to them. I prefer to simply modify my local.conf >> with a PREMIRROR value that has a specific regular expression >> that matches this particular github repo (and hence does NOT >> effect all recipes). This is why I wanted to use the PREMIRROR >> function. Unfortunately, it does not appear to work or at least >> not work as I expected. >> >> --Russ >> >> >> >> >> On Wed, Jul 24, 2019 at 2:57 PM Rudolf J Streif >> mailto:rudolf.str...@ibeeto.com>> wrote: >> >> Hi Russell, >> >> devtool and eSDK are different things. The purpose of >> PREMIRRORS is to set a mirror for all recipes. It's a way for >> organizations to control where their YP builds download >> sources from. It's not intended to be used for a single >> recipe. There is no need for th
Re: [yocto] PREMIRROR
Russell, That is exactly what devtool and the externalsrc class do. PREMIRROR is the wrong approach for that. :rjs On 7/24/19 12:53 PM, Russell Peterson wrote: > Hi, Rudolf. > > I apologize for not being clear. The idea here is that my recipe > points to github while, for my local development environment, I set a > premirror to match a specific github repository and translate it to a > local directory. That works. The fetch matches the PREMIRROR and > places a copy of the LOCAL git repo in my DL_DIR. The problem is, the > do_unpack task is looking for the git repo in the DL_DIR > (git2/etc...)... but it's looking for the git repo from github, not my > local repo that the fetch task just put in DL_DIR. > > There are numerous reasons I'm doing this including the fact that I > cannot put a reference to my local repo in the bb file since I ship > that recipe to my customers and a local pathname is meaningless to > them. I prefer to simply modify my local.conf with a PREMIRROR value > that has a specific regular expression that matches this particular > github repo (and hence does NOT effect all recipes). This is why I > wanted to use the PREMIRROR function. Unfortunately, it does not > appear to work or at least not work as I expected. > > --Russ > > > > > On Wed, Jul 24, 2019 at 2:57 PM Rudolf J Streif > mailto:rudolf.str...@ibeeto.com>> wrote: > > Hi Russell, > > devtool and eSDK are different things. The purpose of PREMIRRORS > is to set a mirror for all recipes. It's a way for organizations > to control where their YP builds download sources from. It's not > intended to be used for a single recipe. There is no need for > that. You simply set SRC_URI in your recipe to your local git > repo. That is what devtool does after downloading the sources from > a remote repo. If you already have the remote repo cloned locally > you can just point devtool to it. > > You can do it manually by creating your recipe and setting SRC_URI > like this: > > SRC_URI = "git:///local/path/${PN};protocol=file" > > SRCREV = "${AUTOREV}" > > S = "${WORKDIR}/git" > > PREMIRRORS is only relevant for do_fetch not for do_unpack. > > :rjs > > > On 7/24/19 11:28 AM, Russell Peterson wrote: >> Hi, Rudolf. >> >> Thanks for the reply. Yes, I am aware of the eSDK functionality, >> however, I have some unique requirements that I am trying to work >> around. Regardless... what I am doing should work, no? I simply >> want to use a local git repo (the directory itself hence >> protocol=file) instead of what the recipe specifies. Looks like >> the fetch is working but the do_unpack task is ignoring >> PREMIRRORS (or at least the localpath variable seems wrong). >> >> --Russ >> >> >> On Wed, Jul 24, 2019 at 12:19 PM Rudolf J Streif >> mailto:rudolf.str...@ibeeto.com>> wrote: >> >> Russell, >> >> You don't need PREMIRROR for this functionality. It's not >> exactly intended for that use. >> >> The simplest way to achieve what you are looking for is to >> use devtool. If I understand you correctly you are >> downloading sources from a remote repo on GitHub but want to >> have them locally to make modifications? If so use: >> >> devtool add myrecipe localsrc fetchuri >> >> from your build environment (you have to source >> oe-init-build-env first). devtool then fetches the source >> from fetchuri into a directory localsrc as a git repo and >> automatically creates the recipe for it. >> >> :rjs >> >> >> On 7/23/19 1:49 PM, Russell Peterson wrote: >>> Hello, >>> >>> I am looking to have bitbake pick up files for a particular >>> recipe from a local git repository using the PREMIRROR >>> functionality. >>> >>> Basically, the recipe (bb file) points to github but in my >>> local build I add PREMIRROR_prepend = "git://.*/.* >>> git:///local/path/BASENAME;protocol=file\n" >>> >>> I will probably make the git regular expression more exact >>> for my specific github repo but this works for now. >>> >>> This all works (as I deleted the github download from the >>> local download directory) because I can see in the do_fetch >>>
Re: [yocto] PREMIRROR
Hi Russell, devtool and eSDK are different things. The purpose of PREMIRRORS is to set a mirror for all recipes. It's a way for organizations to control where their YP builds download sources from. It's not intended to be used for a single recipe. There is no need for that. You simply set SRC_URI in your recipe to your local git repo. That is what devtool does after downloading the sources from a remote repo. If you already have the remote repo cloned locally you can just point devtool to it. You can do it manually by creating your recipe and setting SRC_URI like this: SRC_URI = "git:///local/path/${PN};protocol=file" SRCREV = "${AUTOREV}" S = "${WORKDIR}/git" PREMIRRORS is only relevant for do_fetch not for do_unpack. :rjs On 7/24/19 11:28 AM, Russell Peterson wrote: > Hi, Rudolf. > > Thanks for the reply. Yes, I am aware of the eSDK functionality, > however, I have some unique requirements that I am trying to work > around. Regardless... what I am doing should work, no? I simply want > to use a local git repo (the directory itself hence protocol=file) > instead of what the recipe specifies. Looks like the fetch is working > but the do_unpack task is ignoring PREMIRRORS (or at least the > localpath variable seems wrong). > > --Russ > > > On Wed, Jul 24, 2019 at 12:19 PM Rudolf J Streif > mailto:rudolf.str...@ibeeto.com>> wrote: > > Russell, > > You don't need PREMIRROR for this functionality. It's not exactly > intended for that use. > > The simplest way to achieve what you are looking for is to use > devtool. If I understand you correctly you are downloading sources > from a remote repo on GitHub but want to have them locally to make > modifications? If so use: > > devtool add myrecipe localsrc fetchuri > > from your build environment (you have to source oe-init-build-env > first). devtool then fetches the source from fetchuri into a > directory localsrc as a git repo and automatically creates the > recipe for it. > > :rjs > > > On 7/23/19 1:49 PM, Russell Peterson wrote: >> Hello, >> >> I am looking to have bitbake pick up files for a particular >> recipe from a local git repository using the PREMIRROR functionality. >> >> Basically, the recipe (bb file) points to github but in my local >> build I add PREMIRROR_prepend = "git://.*/.* >> git:///local/path/BASENAME;protocol=file\n" >> >> I will probably make the git regular expression more exact for my >> specific github repo but this works for now. >> >> This all works (as I deleted the github download from the local >> download directory) because I can see in the do_fetch log and the >> correct (local) repo was found and placed in the DL_DIR. >> >> Problem is, do_unpack fails because it appears to be looking for >> the original (github) SRC_URI. Then it complains about "no up to >> date source found: clone or directory not available or not up to >> date (shallow clone not enabled)" >> >> Any help on what I am missing would be appreciated. >> >> Regards, >> >> Russell >> >> >> > -- > - > Rudolf J Streif > CEO/CTO ibeeto > +1.855.442.3396 x700 > -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PREMIRROR
Russell, You don't need PREMIRROR for this functionality. It's not exactly intended for that use. The simplest way to achieve what you are looking for is to use devtool. If I understand you correctly you are downloading sources from a remote repo on GitHub but want to have them locally to make modifications? If so use: devtool add myrecipe localsrc fetchuri from your build environment (you have to source oe-init-build-env first). devtool then fetches the source from fetchuri into a directory localsrc as a git repo and automatically creates the recipe for it. :rjs On 7/23/19 1:49 PM, Russell Peterson wrote: > Hello, > > I am looking to have bitbake pick up files for a particular recipe > from a local git repository using the PREMIRROR functionality. > > Basically, the recipe (bb file) points to github but in my local build > I add PREMIRROR_prepend = "git://.*/.* > git:///local/path/BASENAME;protocol=file\n" > > I will probably make the git regular expression more exact for my > specific github repo but this works for now. > > This all works (as I deleted the github download from the local > download directory) because I can see in the do_fetch log and the > correct (local) repo was found and placed in the DL_DIR. > > Problem is, do_unpack fails because it appears to be looking for the > original (github) SRC_URI. Then it complains about "no up to date > source found: clone or directory not available or not up to date > (shallow clone not enabled)" > > Any help on what I am missing would be appreciated. > > Regards, > > Russell > > > -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Creating my own bsp
Larry, You would want to be more specific with your question and eventually post error messages you are encountering. It looks like you are hung up at the machine configuration file. You may want to post that. As far as BSP layers and machine configuration files are concerned, my advice is to start with an existing configuration that is close to your actual hardware. :rjs On 6/21/19 10:46 AM, Larry Brown wrote: > I've come across references to "yocto-bsp" script that should help > build a bsp. I'm starting from scratch with an arm 7M and trying to > use the raspberrypi bsp as a reference. There is so much complexity > I'm not sure where to start. > > After setting up the files for the Linux kernel I'm using already on > the board and the config, it first complained about TUNE_ARCH not > being present. This is not present in the meta-raspberrypi content > but based on something I came across this just wants arm. Then it > complains TUNE_PKGARCH is not set. I don't know what this is looking > for and I'm not getting effective hits searching for it. I'm guessing > there are going to be a lot more after these two complaints. It would > be nice to read what went into a simple bsp that worked under for an > arm board. > > PS I'm using the warrior release as it worked for bringing up the > raspberry pi. > > Any help would be greatly appreciated. > > -- > Larry Brown > > -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display
Khem, Yes, the 32-bit image (raspberrypi3 machine) works. :rjs On 5/19/19 9:11 AM, Khem Raj wrote: On Sat, May 18, 2019 at 11:02 PM Rudolf Streif mailto:rudolf.str...@ibeeto.com>> wrote: Thanks, Khem. 64 bit, raspberrypi3-64 machine with vc4graphics. Please try 32bit we only have hdmi tested in 64bit this far On Sat, May 18, 2019, 22:13 Khem Raj mailto:raj.k...@gmail.com>> wrote: On 5/16/19 9:01 AM, Andrei Gherzan wrote: > HI, > > On 16/05/2019 16.31, Rudolf J Streif wrote: >> I am trying to use the "official" RPi 7" touch display >> (https://www.raspberrypi.org/products/raspberry-pi-touch-display/) >> with meta-raspberrypi (most recent from master). However, I cannot get >> it to work. As a matter of fact the display does not even show the GPU >> rainbow screen making me think that the GPU firmware packaged with >> meta-raspberrypi does not support the DSI display. It works just fine >> with the latest Raspbian release (screen and touch). >> >> I searched the web up and down but could not find anything. Maybe >> somebody has an idea? Wrong firmware (maybe cannot be distributed >> because of licensing...)? > Sadly we don't actively test display and other related toys so they > might be broken. Even so, I would be surprised if the DSI port doesn't > work. What is you final config.txt (pastebin it please)? > are you building 64bit or 32bit images ? are you using vc4grpahics or userland graphics ? -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display
I tried to build for 32 bit with: Build Configuration: BB_VERSION = "1.43.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "raspberrypi3" DISTRO = "poky" DISTRO_VERSION = "2.7+snapshot-20190519" TUNE_FEATURES = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard" TARGET_FPU = "hard" meta meta-poky meta-yocto-bsp = "master:ff472ffbb0d143de8187d84dbbf18453318f303f" meta-raspberrypi = "master:7059c374512f1c1c0df9ecab0703d11438bdf78b" meta-oe meta-multimedia meta-networking meta-python = "master:1ecd8b43645883cd4fa652826e93137c942dd82c" However, mesa-gl; now fails compiling: ld: src/gbm/cd6bfad@@gbm@sha/main_backend.c.o: in function `_gbm_create_device': | /usr/src/debug/mesa-gl/2_19.0.3-r0/build/../mesa-19.0.3/src/gbm/main/backend.c:104: undefined reference to `gbm_dri_backend' I have not encountered that before when building for raspberrypi3 before. :rjs On 5/19/19 9:11 AM, Khem Raj wrote: On Sat, May 18, 2019 at 11:02 PM Rudolf Streif mailto:rudolf.str...@ibeeto.com>> wrote: Thanks, Khem. 64 bit, raspberrypi3-64 machine with vc4graphics. Please try 32bit we only have hdmi tested in 64bit this far On Sat, May 18, 2019, 22:13 Khem Raj mailto:raj.k...@gmail.com>> wrote: On 5/16/19 9:01 AM, Andrei Gherzan wrote: > HI, > > On 16/05/2019 16.31, Rudolf J Streif wrote: >> I am trying to use the "official" RPi 7" touch display >> (https://www.raspberrypi.org/products/raspberry-pi-touch-display/) >> with meta-raspberrypi (most recent from master). However, I cannot get >> it to work. As a matter of fact the display does not even show the GPU >> rainbow screen making me think that the GPU firmware packaged with >> meta-raspberrypi does not support the DSI display. It works just fine >> with the latest Raspbian release (screen and touch). >> >> I searched the web up and down but could not find anything. Maybe >> somebody has an idea? Wrong firmware (maybe cannot be distributed >> because of licensing...)? > Sadly we don't actively test display and other related toys so they > might be broken. Even so, I would be surprised if the DSI port doesn't > work. What is you final config.txt (pastebin it please)? > are you building 64bit or 32bit images ? are you using vc4grpahics or userland graphics ? -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display
No, unfortunately not. HDMI works just fine but no video on the touch display. On 5/16/19 9:46 AM, Andrei Gherzan wrote: Hi, On 16/05/2019 17.24, Rudolf J Streif wrote: Thank you, Paul. I did read Andrei's excellent documentation and enabled I2C and SPI etc. And it didn't work? -- ----- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display
Thank you, Paul. I did read Andrei's excellent documentation and enabled I2C and SPI etc. :rjs On 5/16/19 8:39 AM, Paul Barker wrote: On Thu, 16 May 2019, at 16:33, Rudolf J Streif wrote: I am trying to use the "official" RPi 7" touch display (https://www.raspberrypi.org/products/raspberry-pi-touch-display/) with meta-raspberrypi (most recent from master). However, I cannot get it to work. As a matter of fact the display does not even show the GPU rainbow screen making me think that the GPU firmware packaged with meta-raspberrypi does not support the DSI display. It works just fine with the latest Raspbian release (screen and touch). I searched the web up and down but could not find anything. Maybe somebody has an idea? Wrong firmware (maybe cannot be distributed because of licensing...)? I'd recommend looking at https://github.com/agherzan/meta-raspberrypi/blob/master/docs/extra-build-config.md to see if there's some extra option you need to enable. If there's nothing documented there then raise an issue on the GitHub repository. Cheers, -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display
Thank you, Andrei. Much appreciated. https://pastebin.com/bHUHaRkL It's the config.txt that is packaged with the image. :rjs On 5/16/19 9:01 AM, Andrei Gherzan wrote: HI, On 16/05/2019 16.31, Rudolf J Streif wrote: I am trying to use the "official" RPi 7" touch display (https://www.raspberrypi.org/products/raspberry-pi-touch-display/) with meta-raspberrypi (most recent from master). However, I cannot get it to work. As a matter of fact the display does not even show the GPU rainbow screen making me think that the GPU firmware packaged with meta-raspberrypi does not support the DSI display. It works just fine with the latest Raspbian release (screen and touch). I searched the web up and down but could not find anything. Maybe somebody has an idea? Wrong firmware (maybe cannot be distributed because of licensing...)? Sadly we don't actively test display and other related toys so they might be broken. Even so, I would be surprised if the DSI port doesn't work. What is you final config.txt (pastebin it please)? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] RPi 7" Touch Display
I am trying to use the "official" RPi 7" touch display (https://www.raspberrypi.org/products/raspberry-pi-touch-display/) with meta-raspberrypi (most recent from master). However, I cannot get it to work. As a matter of fact the display does not even show the GPU rainbow screen making me think that the GPU firmware packaged with meta-raspberrypi does not support the DSI display. It works just fine with the latest Raspbian release (screen and touch). I searched the web up and down but could not find anything. Maybe somebody has an idea? Wrong firmware (maybe cannot be distributed because of licensing...)? Thanks, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] problem adding a user
Instead of useradd -p `openssl passwd test` sakura which attempts to add the user and set the password which fails if the user already exists, use usermod -p `openssl passwd test` sakura which sets the user's password. :rjs On 5/15/19 1:18 PM, Greg Wilson-Lindberg wrote: Ok, I had been using the useradd class in a couple of other recipes to allow me to copy files to the sakura user directory and another location, but owned by sakura. That seems to have been what was causing the problem. I had been using the extrausers class in my top level image recipe. So now how do I get all of this to work together? Do I need to put everything that touches the sakura user in the same recipe? It seems that I need to use only one of the useradd or extrausers classes? Greg *From:* Rudolf J Streif *Sent:* Wednesday, May 15, 2019 12:31 PM *To:* Greg Wilson-Lindberg; Yocto list discussion *Subject:* Re: [yocto] problem adding a user The ! for the password in /etc/shadow indicates that the account is disabled: sakura:!:18031:0:9:7::: Either there is something wrong with the password generation or it gets disabled by something else. Maybe it's worth trying with a plain image without Boot2Qt or anything else. :rjs On 5/15/19 11:46 AM, Greg Wilson-Lindberg wrote: Hi Rudolf, 1st, yes I inherit extrausers. Attached are the passwd & shadow files. It shouldn't make any difference, but I'm building this for an RPi3 using the Qt Boot2Qt version of the Yocto environment, distro 2.5.3. Greg -------- *From:* Rudolf J Streif *Sent:* Wednesday, May 15, 2019 11:26 AM *To:* Greg Wilson-Lindberg; Yocto list discussion *Subject:* Re: [yocto] problem adding a user Hi Greg, > I've also tried both the back-quote and the single-quote, no difference. Help me to understand this. the back-quotes are the right ones. If you use the single ones your password in the /etc/shadow ends up being 'openssl passwd test' (without the quotes), unless the build fails because of a parsing error (I have not tried it). Silly question, you did inherit extrausers class? Can you post your /etc/passwd and /etc/shadow I am surprised that this does not work with your setup. I have been doing this a gazillion times always with success. :rjs On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote: Hi Rudolf, Thanks for the reply, and the information on how openssl works. I'm trying to create a user with the same group name so the code that I'm using reduces to: EXTRA_USERS_PARAMS = "\ useradd -p `openssl passwd test` sakura; \ usermod -a -G sudo ${SAKURA_USER}; \ " I also, as you can see, removed the macros to eliminate as much confusion as possible. I still can't login in using the password 'test'. I've also tried both the back-quote and the single-quote, no difference. Regards, Greg -------- *From:* Rudolf J Streif *Sent:* Wednesday, May 15, 2019 10:07:47 AM *To:* Greg Wilson-Lindberg; Yocto list discussion *Subject:* Re: [yocto] problem adding a user Hi Greg, Well, I suppose I wrote the book you are referring to... Using useradd -p PASSWORD USER takes the password hash for PASSWORD hence the use of openssl in: useadd -p `openssl passwd PASSWORD` USER openssl password creates the password hash using the original crypt hash algorithm if no other options are specified. e.g. $ openssl passwd hello 6hEsTksgRkeiI With this the first two characters of the output is the salt and the rest is the password hash. If you want openssl to create the same result again: $ openssl passwd -salt "6h" hello 6hEsTksgRkeiI You can use newer algorithms like MD5 based BSD password algorithm 1: $ openssl passwd -1 hello $1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1 $1 : password algorithm 1 $4Mu8Fcs. : salt $eIKgPP7RCYrb3lFZjhADA1 : password hash If you log into the system you have to use the clear password. The system reads the salt, creates the password hash and compares the results. :rjs On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote: > I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code: > > useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \ > > uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl > command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode > produces a different value? > > I am getting the user added to the system, the home directory shows up and the u
Re: [yocto] problem adding a user
The ! for the password in /etc/shadow indicates that the account is disabled: sakura:!:18031:0:9:7::: Either there is something wrong with the password generation or it gets disabled by something else. Maybe it's worth trying with a plain image without Boot2Qt or anything else. :rjs On 5/15/19 11:46 AM, Greg Wilson-Lindberg wrote: Hi Rudolf, 1st, yes I inherit extrausers. Attached are the passwd & shadow files. It shouldn't make any difference, but I'm building this for an RPi3 using the Qt Boot2Qt version of the Yocto environment, distro 2.5.3. Greg -------- *From:* Rudolf J Streif *Sent:* Wednesday, May 15, 2019 11:26 AM *To:* Greg Wilson-Lindberg; Yocto list discussion *Subject:* Re: [yocto] problem adding a user Hi Greg, > I've also tried both the back-quote and the single-quote, no difference. Help me to understand this. the back-quotes are the right ones. If you use the single ones your password in the /etc/shadow ends up being 'openssl passwd test' (without the quotes), unless the build fails because of a parsing error (I have not tried it). Silly question, you did inherit extrausers class? Can you post your /etc/passwd and /etc/shadow I am surprised that this does not work with your setup. I have been doing this a gazillion times always with success. :rjs On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote: Hi Rudolf, Thanks for the reply, and the information on how openssl works. I'm trying to create a user with the same group name so the code that I'm using reduces to: EXTRA_USERS_PARAMS = "\ useradd -p `openssl passwd test` sakura; \ usermod -a -G sudo ${SAKURA_USER}; \ " I also, as you can see, removed the macros to eliminate as much confusion as possible. I still can't login in using the password 'test'. I've also tried both the back-quote and the single-quote, no difference. Regards, Greg -------- *From:* Rudolf J Streif *Sent:* Wednesday, May 15, 2019 10:07:47 AM *To:* Greg Wilson-Lindberg; Yocto list discussion *Subject:* Re: [yocto] problem adding a user Hi Greg, Well, I suppose I wrote the book you are referring to... Using useradd -p PASSWORD USER takes the password hash for PASSWORD hence the use of openssl in: useadd -p `openssl passwd PASSWORD` USER openssl password creates the password hash using the original crypt hash algorithm if no other options are specified. e.g. $ openssl passwd hello 6hEsTksgRkeiI With this the first two characters of the output is the salt and the rest is the password hash. If you want openssl to create the same result again: $ openssl passwd -salt "6h" hello 6hEsTksgRkeiI You can use newer algorithms like MD5 based BSD password algorithm 1: $ openssl passwd -1 hello $1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1 $1 : password algorithm 1 $4Mu8Fcs. : salt $eIKgPP7RCYrb3lFZjhADA1 : password hash If you log into the system you have to use the clear password. The system reads the salt, creates the password hash and compares the results. :rjs On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote: > I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code: > > useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \ > > uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl > command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode > produces a different value? > > I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the > account. > > I've obviously got something confused, any help would be appreciated. > > Greg Wilson-Lindberg > -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] problem adding a user
Hi Greg, > I've also tried both the back-quote and the single-quote, no difference. Help me to understand this. the back-quotes are the right ones. If you use the single ones your password in the /etc/shadow ends up being 'openssl passwd test' (without the quotes), unless the build fails because of a parsing error (I have not tried it). Silly question, you did inherit extrausers class? Can you post your /etc/passwd and /etc/shadow I am surprised that this does not work with your setup. I have been doing this a gazillion times always with success. :rjs On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote: Hi Rudolf, Thanks for the reply, and the information on how openssl works. I'm trying to create a user with the same group name so the code that I'm using reduces to: EXTRA_USERS_PARAMS = "\ useradd -p `openssl passwd test` sakura; \ usermod -a -G sudo ${SAKURA_USER}; \ " I also, as you can see, removed the macros to eliminate as much confusion as possible. I still can't login in using the password 'test'. I've also tried both the back-quote and the single-quote, no difference. Regards, Greg ------------ *From:* Rudolf J Streif *Sent:* Wednesday, May 15, 2019 10:07:47 AM *To:* Greg Wilson-Lindberg; Yocto list discussion *Subject:* Re: [yocto] problem adding a user Hi Greg, Well, I suppose I wrote the book you are referring to... Using useradd -p PASSWORD USER takes the password hash for PASSWORD hence the use of openssl in: useadd -p `openssl passwd PASSWORD` USER openssl password creates the password hash using the original crypt hash algorithm if no other options are specified. e.g. $ openssl passwd hello 6hEsTksgRkeiI With this the first two characters of the output is the salt and the rest is the password hash. If you want openssl to create the same result again: $ openssl passwd -salt "6h" hello 6hEsTksgRkeiI You can use newer algorithms like MD5 based BSD password algorithm 1: $ openssl passwd -1 hello $1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1 $1 : password algorithm 1 $4Mu8Fcs. : salt $eIKgPP7RCYrb3lFZjhADA1 : password hash If you log into the system you have to use the clear password. The system reads the salt, creates the password hash and compares the results. :rjs On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote: > I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code: > > useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \ > > uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl > command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode > produces a different value? > > I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the > account. > > I've obviously got something confused, any help would be appreciated. > > Greg Wilson-Lindberg > -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] problem adding a user
Hi Greg, Well, I suppose I wrote the book you are referring to... Using useradd -p PASSWORD USER takes the password hash for PASSWORD hence the use of openssl in: useadd -p `openssl passwd PASSWORD` USER openssl password creates the password hash using the original crypt hash algorithm if no other options are specified. e.g. $ openssl passwd hello 6hEsTksgRkeiI With this the first two characters of the output is the salt and the rest is the password hash. If you want openssl to create the same result again: $ openssl passwd -salt "6h" hello 6hEsTksgRkeiI You can use newer algorithms like MD5 based BSD password algorithm 1: $ openssl passwd -1 hello $1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1 $1 : password algorithm 1 $4Mu8Fcs. : salt $eIKgPP7RCYrb3lFZjhADA1 : password hash If you log into the system you have to use the clear password. The system reads the salt, creates the password hash and compares the results. :rjs On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote: I'm trying to use the example in "Embedded Linux Systems with the Yocto Project" to add a user to my Yocto build. In the book the sample code: useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \ uses openssl to generate the encrypted password string to pass to useradd. I have never been able to get this to work. When I run the openssl command on the cmd line I get a different value every time, this seems wrong, How can the password code compare against it if every encode produces a different value? I am getting the user added to the system, the home directory shows up and the user is in the passwd and group files. I just can't login to the account. I've obviously got something confused, any help would be appreciated. Greg Wilson-Lindberg -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto-Advocacy] Yocto Project Upcoming Conferences and Developer Days
Chiming in here On 5/7/19 11:18 AM, Behan Webster wrote: On May 7, 2019, at 2:47 AM, Bas Mevissen <mailto:ab...@basmevissen.nl>> wrote: On 2019-05-07 07:20, Behan Webster wrote: > On May 6, 2019, at 8:36 AM, Bas Mevissen <mailto:b...@emcodev.nl>> wrote: > On 5/6/19 12:45 PM, Josef Holzmayr wrote: > I'd actually word it a little bit differently: > If there is only *ONE* attendee who did not properly do the homework, it > will have a massive impact an the rest of the group. And that somebody > will show up unpreparedly is absolutely certain in my opinion. > With sufficient trainers, one can continue for most and provide some assistance to the one falling behind. Usually more than one. And this is generally very disruptive to the class as a whole. There are always people who are prepared to the T and others who just casually stroll into the class. We all know that as we all went through various stages of schooling. :) No matter what you do, there always will be a glitch. I tried it all from course preparation instructions, shell scripts setting up systems, USB sticks and network drives with downloads and shared state cache, virtual machine images, build systems set up in the cloud, you name it. If it is not somebody who is unprepared it is a technical issue: lack of disk space, network connectivity, corporate computers that do not allow USB sticks,... Instructors just have to deal with it. >> As someone who actually got started through the YPDD beginner track (and >> also often recommends it to new beginners), my opinion is clearly that >> we either should have it, be it only for a handful of attendees, or >> offer a *real* replacement, with face to face training. My experience is >> that this personal thing in the very beginning is an absolutely >> essential part of many YP/OE careers. > > I agree. That is how I started, next to a compressed Linux Foundation Yocto training that was offered just before the event then. Yes. By me and my colleagues who train for the Linux Foundation. > So it might be wise to ask LF or get something organised. It would mostly require a room and a sponsor for some small devkit. We've run the beginner track for the last few years. The discussion is precisely that the YP event is proposing to not run the beginner track this year at all. But why? There appears to be a constant demand. An excellent question. I agree with you. I don’t have an answer however. Not my decision. I certainly would advocate to have the beginner track. It's a good way of getting people interested, and eventually excited, for the Yocto Project. Conferences and dev days are an opportunity to do advertising and to grow the community. We cannot do that just by catering to people who are already using YP. We need new folks as we are already running into issues where things have to be dropped because there is nobody who is maintaining it. We're happy to do it again if given the space. Yes, both for LF and YP it are off-the-shelf trainings that do not require much preperation. Speaking as a course maintainer for LF, keeping the YP course updated is actually a tremendous amount of work (I’m the co-maintainer for the LF YP course). However, the beginner slides tend not to need more than a few hours of updates every 6 months (which again is something I do). Either may appear off-the-shelf, but they aren’t from my perspective. ;) I can wholeheartedly second that. I developed the original YP class of the LF and taught it many times and have since developed my own class material teaching classes. While the basic concept of course remains the same it is the little details that change. With every new version of the YP a course maintainer has to go through every single exercise and example in the course material and try it out again to see if it still works. And quite frankly, sometimes it is rather silly things that have changed and break something. In particular for a beginner class lasting one day only, every single disruption sets the class back and there is no opportunity to recover from it. The day is already packed just to cover the core concepts. Cheers, Rudi Thanks, Behan -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project @ ELC NA 2019
Hi Andrea, Great. I can bring some wooden blocks to prop up the rear-end. People could sit in it and spin the wheels. :rjs On 5/2/19 2:39 PM, Volosincu, Andreea S wrote: Hi Rudi, That's awesome! I will check with LF events to see if there are any issues with showing that or restrictions with how people engage with it during the show. Definitely in favor of showing the whole gokart. Thanks! Andreea -Original Message- From: Rudolf J Streif [mailto:rudolf.str...@ibeeto.com] Sent: Thursday, May 2, 2019 2:36 PM To: Volosincu, Andreea S ; Nicolas Dechesne Cc: Yocto list discussion Subject: Re: [yocto] Yocto Project @ ELC NA 2019 Hi Andrea, I was intending to bring the whole gokart. It's more fun to see the speedometer go up when you push down on the pedal and the regen to kick in when letting go etc. Everybody has seen hundreds of instrument cluster demos (at least when you work for the automotive industry). It might be a crowd catcher too (at least that's what I figured when I was at CES this year; a booth with a vehicle had many spectators :). Please see early picture (without cluster) attached. :rjs On 5/2/19 2:17 PM, Volosincu, Andreea S wrote: Hi Rudi, That sounds super interesting. We do have a 6'x6' exhibit booth on the show floor, and a DevDay on Tuesday, August 20. Are you planning to show just the instrument cluster, or the whole gokart? If the gokart, I would just need to check with LF and see if we are allowed to have that on the show floor. It's certainly a new thing we haven't tried or had before. Thanks! Andreea -Original Message- From: Nicolas Dechesne [mailto:nicolas.deche...@linaro.org] Sent: Thursday, May 2, 2019 1:17 PM To: Rudolf J Streif ; Volosincu, Andreea S Cc: Yocto list discussion Subject: Re: [yocto] Yocto Project @ ELC NA 2019 hi Rudolf, +Andreea (Yocto Advocacy) we are definitely planning to be at ELC, with a similar setup as with past ELC : booth, demo, DevDay and BoF, well, at least ! cheers nico On Thu, May 2, 2019 at 9:31 PM Rudolf J Streif wrote: I apologize if I missed any communication on this mailing list but what are the plans for a presence of YP at ELC NA in August in San Diego this year? Unfortunately, I missed the deadline for submitting a speaking proposal ("Yocto Project DevOps with Gitlab, Docker and AWS") for ELC. However, if YP is planning on a presence at ELC I'd be happy to support it as I, conveniently, live in San Diego. If there is a YP exhibition I might be able to bring my little hobby project, an electric gokart with YP-based instrument cluster (it's a full-size kart with 13 kW AC motor and a LiFePo battery pack producing up to 25 kW peak power output going up to 45 mph (electronically limited)). Cheers, Rudi -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project @ ELC NA 2019
I apologize if I missed any communication on this mailing list but what are the plans for a presence of YP at ELC NA in August in San Diego this year? Unfortunately, I missed the deadline for submitting a speaking proposal ("Yocto Project DevOps with Gitlab, Docker and AWS") for ELC. However, if YP is planning on a presence at ELC I'd be happy to support it as I, conveniently, live in San Diego. If there is a YP exhibition I might be able to bring my little hobby project, an electric gokart with YP-based instrument cluster (it's a full-size kart with 13 kW AC motor and a LiFePo battery pack producing up to 25 kW peak power output going up to 45 mph (electronically limited)). Cheers, Rudi -- - Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] local.conf confusion
Greg, I am not entirely sure why you are including a machine configuration include file into your conf/local.conf file. However, the "include" directive is optional include and hence if the file is not found Bitbake will not raise an error and terminate. If you need that behavior use "require" instead. Machine configuration files do commonly use includes for shared configuration. You typically find them where the machine configuration files are: conf/machine or in a subdirectory there. The directory conf/machine is commonly found in BSP layers such as meta-raspberrypi which you are probably using as you are building for RPi. :rjs On 2/20/19 10:16 AM, Greg Wilson-Lindberg wrote: > Hello list, > > I've run into a confusion that should be simple. I've got a build based on > sumo, at the bottom of my local.conf file is the line: > > include conf/distro/include/${MACHINE}.pre.inc > > This should be straight forward, just find the conf/distro/include directory > and all of the *.pre.inc files should be there. I just searched all of the > sources directory for '*.pre.inc' and I get nothing. I'm building for a > raspberry pi3, so I would expect at least 'raspberry*.inc', still nothing. > I'm not getting an error for bitbake not being able to find the file. > > So where do I find the machine include files? > > Regards, > Greg Wilson-Lindberg > signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting up a password for the root user
Alberto, The quotes around `openssl passwd ${ROOT_PASSWORD}` have to be backticks (`) not single quotes ('). :rjs On 01/11/2019 07:41 AM, Alberto Spin wrote: > > Hello There, > > > > I’m trying to set a password for the root user of my distribution > (based rocko branch) > > > > I’ve added the following to my image recipe: > > > > inherit extrausers > > > > # set image root password > > ROOT_PASSWORD = "secret" > > > > EXTRA_USERS_PARAMS = "\ > > usermod -p 'openssl passwd ${ROOT_PASSWORD}' root; \ > > " > > > > Everything builds fine, but in my image I end up with a password in my > /etc/shadow file like this: > > > > openssl passwd secret > > > > so it seems like the openssl command has not been executed during the > build, but instead the literal command is now part of my password. > > > > Can anybody please explain what’s going on here, and how to fix this? > > > > Kind Regards, > > > > Alberto > > > > > > > > > signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to tell bitbake my prefered terminal in for devshell and access bitbake datastore?
You can use the variable OE_TERMINAL to choose your preferred terminal. By default it's set to auto and Bitbake figures out what terminal is available on your system. Please refer to the manual at: https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#var-OE_TERMINAL. > Also, is it possible to access bitbake datastore from inside the devshell(or devpyshell) ? You cannot access d if you mean that, however, all the variables are exported to the shell. :rjs On 07/23/2018 02:49 AM, MOHAMMAD RASIM wrote: > Hi, > > when running bitbake with a recipe and giving the devshell as a > command bitbake runs the devshell inside xterm, on my other machine it > runs tmux. > > looking at the openembedded source code here > https://github.com/openembedded/openembedded-core/blob/master/meta/lib/oe/terminal.py > > I can see there are multiple classes for terminals that bitbake loop > through, but how can I tell bitbake that I prefer a certain terminal? > > Also, is it possible to access bitbake datastore from inside the > devshell(or devpyshell) ? > > Regards > -- Rudolf J Streif signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Which bb is chosen when several versions are available
The one with the higher version number unless explicitly overridden with PREFERRED_VERSION_php. However, if there is also a recipe with _git.bb then that one will be chosen as git indicates the latest. :rjs On 07/11/2018 12:28 PM, Simon Chamlian wrote: > Hi, > > In the BSP yocto image, I have 2 recipes: > > /sources/meta-openembedded/meta-oe/recipes-devtools/php > > drwxrwxr-x 2 jay jay 4096 Jun 28 09:48 php > -rw-rw-r-- 1 jay jay 232 Jun 28 09:48 php_5.5.38.bb > <http://php_5.5.38.bb> > drwxrwxr-x 2 jay jay 4096 Jun 28 09:48 php-5.6.26 > -rw-rw-r-- 1 jay jay 291 Jun 28 09:48 php_5.6.26.bb > <http://php_5.6.26.bb> > -rw-rw-r-- 1 jay jay 11980 Jun 28 09:48 php.inc > > > If I add in my image recipe: > CORE_IMAGE_EXTRA_INSTALL += " \ > php \ > " > > which version will be included? > > Thanks, > S > > > -- Rudolf J Streif signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Keeping and modifying Source code in Yocto
Hi Simon, > Is there a way to keep the source code of a package to be able to modify it and then compile? Yes, there is. devtool greatly simplifies this type of workflow. Please refer to https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#using-devtool-in-your-sdk-workflow for details. :rjs On 07/06/2018 08:20 AM, Simon Chamlian wrote: > Hi, > > Is there a way to keep the source code of a package to be able to > modify it and then compile? > > For example, with LTIB ( Linux Target Image Builder ), it was possible > with a command to extract the source code from a package, make > modifications and then re-compile? > > Thanks, > S > > > > > > > -- Rudolf J Streif signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] porting gRPC into Yocto
Hi Simon, Thank you for using the Yocto Project and reaching out. For any open-source component that you would like to add to the Yocto Project I recommend that you first have a look at http://layers.openembedded.org/layerindex/branch/master/recipes/ and enter the name of the component. Chances are that somebody already did the work. This is indeed the case with gRPC: http://layers.openembedded.org/layerindex/recipe/72419/. If you cannot find a recipe for the component then you should look at how the component is built. Most C/C++ components use some sort of a build system such as GNU Autotools or CMake. The Yocto Project documentation has sections for the common build systems. I hope this answers your question. Rudi On 06/21/2018 11:15 AM, Simon Chamlian wrote: > Hi, > > I just started using Yocto. > > Is there a detailed procedure on how I can port gRPC (for C or C++) > into a Yocto project? > > Thanks, > > S > > > > > > > > -- Rudolf J Streif signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux][PATCH] libselinux: python-importlib is now part of python*-core
Thank you, Mark. Much appreciated and understood. Would you be open to tagging the layer for rocko to the right commit and applying the patches sent to the mailing list by Armin and Kai to master so that we have known points to move forward? Thank you, Rudi On 05/11/2018 10:45 AM, Mark Hatle wrote: > On 5/11/18 12:28 PM, Rudolf J Streif wrote: >> Echoing this: may I ask what the current maintenance status of >> meta-selinux is. It appears that no updates have been made for more than >> 9 months. This is of course not to blame anybody but out of concern that >> the layer is falling behind even more and to find a solution. > The answer is the current set of people are horribly overworked and busy, so > day-to-day updates have been 'sparse'. > > Usually we update meta-selinux about the time of a release, and thus are due. > > The last update of meta-selinux was about the time of the Rocko release, so > what > is in master is definitely current as of Rocko. (I did the last set of > updates > -- so I know it did work as of Rocko release.) The master needs to be > branched > as Rocko... master needs to be updated to be Sumo compatible. > > My assumption is that once Sumo is formally released (any minute now), we'll > collection all of the patches and get them into place and spend some time > cleaning them up... > > It looks like Joe is already working through this effort. > > (Only speaking for myself,) I don't have time to do day-to-day maintenance of > meta-selinux any longer -- nor do I have the indepth knowledge to understand > when not to do something. I filled this role purely out of necessity since > nobody else was doing it. > > So with that said, if anyone wants to help, we're all open for help here... I > doubt there would be any objection to adding or replacing existing maintainers > and/or giving more people push access. > >> In addition to Armin's patches there are two patches submitted by Kai >> Kang at Windriver: >> >> * https://lists.yoctoproject.org/pipermail/yocto/2018-February/039917.html >> * https://lists.yoctoproject.org/pipermail/yocto/2018-February/039918.html >> >> Curiously enough, the second patch has been applied to master but not >> the first one. >> >> >> There is also an issue with building SELinux with systemd. The layer >> enables auditing: >> >> meta-selinux/classes/enable-audit.bbclass:PACKAGECONFIG[audit] = >> "--enable-audit,--disable-audit,audit," >> meta-selinux/recipes-core/systemd/systemd_%.bbappend:inherit >> ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'enable-audit', '', d)} >> >> Apparently the --enable-audit switch is passed to meson when running the >> configure task, which meson does not appreciate. I am not that familiar >> with the audit feature nor with meson, so I currently have no idea on >> how to fix this the right way. > audit feature is useful outside of selinux, so my understand was that audit > itself was moving into core during the sumo time frame (if it hadn't already > been oved.) > > I don't know anything about meson, so I can't speak to that... > >> Further, refpolicy_git does not build anymore as the YP specific patches >> do not apply anymore since upstream changed. > The refpolicy is and has always been crap. I've been talking to a few people > on > IRC about working to replace the refpolicy with a policy that can be generated > dynamically based on the contents of the recipes. I don't know if that is > really going to happen, but I hate the way it's currently implemented. > > One of the key issues about the refpolicy is that you need to be an expert at > this (which I never claimed to be) in order to make any reasonable decision -- > add to that any specific policy needs to userstand overall system design, and > I > wouldn't trust any of the refpolicy items as they stand in meta-selinux. > > --Mark > >> Thanks, >> Rudi >> >> >> >> On 05/07/2018 10:20 AM, akuster808 wrote: >>> On 04/14/2018 07:08 PM, Armin Kuster wrote: >>>> Missing or unbuildable dependency chain was: ['meta-world-pkgdata', >>>> 'restorecond', 'libselinux', 'python-importlib'] >>>> >>>> Signed-off-by: Armin Kuster >>> ping >>>> --- >>>> recipes-security/selinux/libselinux.inc | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/recipes-security/selinux/libselinux.i
Re: [yocto] [meta-selinux][PATCH] libselinux: python-importlib is now part of python*-core
Echoing this: may I ask what the current maintenance status of meta-selinux is. It appears that no updates have been made for more than 9 months. This is of course not to blame anybody but out of concern that the layer is falling behind even more and to find a solution. In addition to Armin's patches there are two patches submitted by Kai Kang at Windriver: * https://lists.yoctoproject.org/pipermail/yocto/2018-February/039917.html * https://lists.yoctoproject.org/pipermail/yocto/2018-February/039918.html Curiously enough, the second patch has been applied to master but not the first one. There is also an issue with building SELinux with systemd. The layer enables auditing: meta-selinux/classes/enable-audit.bbclass:PACKAGECONFIG[audit] = "--enable-audit,--disable-audit,audit," meta-selinux/recipes-core/systemd/systemd_%.bbappend:inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'enable-audit', '', d)} Apparently the --enable-audit switch is passed to meson when running the configure task, which meson does not appreciate. I am not that familiar with the audit feature nor with meson, so I currently have no idea on how to fix this the right way. Further, refpolicy_git does not build anymore as the YP specific patches do not apply anymore since upstream changed. Thanks, Rudi On 05/07/2018 10:20 AM, akuster808 wrote: > > On 04/14/2018 07:08 PM, Armin Kuster wrote: >> Missing or unbuildable dependency chain was: ['meta-world-pkgdata', >> 'restorecond', 'libselinux', 'python-importlib'] >> >> Signed-off-by: Armin Kuster > ping >> --- >> recipes-security/selinux/libselinux.inc | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/recipes-security/selinux/libselinux.inc >> b/recipes-security/selinux/libselinux.inc >> index bd5ce8d..51d0875 100644 >> --- a/recipes-security/selinux/libselinux.inc >> +++ b/recipes-security/selinux/libselinux.inc >> @@ -8,7 +8,7 @@ LICENSE = "PD" >> inherit lib_package pythonnative >> >> DEPENDS += "libsepol python libpcre swig-native" >> -RDEPENDS_${PN}-python += "python-importlib" >> +RDEPENDS_${PN}-python += "python-core" >> >> PACKAGES += "${PN}-python" >> FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}/site-packages/*" -- Rudolf J Streif signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: libreoffice-5.0.5.2-r0 do_package
Ravikiran, > > > *ERROR: libreoffice-5.0.5.2-r0 do_package: QA Issue: File > '/usr/lib/libreoffice/share/extensions/mysql-connector-ooo/libmysqlclient_r. > so' from libreoffice was already stripped, this will prevent future > debugging! [already-stripped]* This error message is produced by the packaging QA. It means that the libreoffice's build system (make files) has already stripped the debug symbols from the library. There are two ways to fix this: The better way: Examine the make files to see where the debug symbols are being stripped. Create a patch so that they are not stripped during the regular build process. This will allow YP/OE to create the debug package with binaries that include the debug symbols and the regular package with the binaries without the debug symbols. The quick fix: Skip this QA check by adding INSANE_SKIP_libreoffice += "already-stripped" to the libreoffice recipe. :rjs > WARNING: libreoffice-5.0.5.2-r0 do_package: libreoffice language file > pattern not found: /usr/lib/libreoffice/share/template/%{1} > > > *ERROR: libreoffice-5.0.5.2-r0 do_package: Fatal QA errors found, failing > task.ERROR: libreoffice-5.0.5.2-r0 do_package: Function failed: > do_packageERROR: Logfile of failure stored in: > /home/kamama-yocto/yocto/poky/build/tmp/work/cortexa15hf-neon-poky-linux-gnu > eabi/libreoffice/5.0.5.2-r0/temp/log.do_package.23588* *ERROR: Task > (/home/kamama-yocto/yocto/poky/meta-packages/meta-office/recipes-libreoffice > /libreoffice/libreoffice.bb:do_package) failed with exit code '1'* > NOTE: Tasks Summary: Attempted 8443 tasks of which 8385 didn't need to be > rerun and 1 failed. > > Summary: 1 task failed: > > /home/kamama-yocto/yocto/poky/meta-packages/meta-office/recipes-libreoffice/ > libreoffice/libreoffice.bb: do_package > Summary: There were 2 WARNING messages shown. > Summary: There were 3 ERROR messages shown, returning a non-zero exit code. > > > what is the issue and how to solve this ? > > > Best Regards, > Ravikiran -- Rudolf J Streif signature.asc Description: This is a digitally signed message part. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What happened to 'depexp'?
On Friday, March 10, 2017 2:46:55 AM PST Burton, Ross wrote: > On 10 March 2017 at 10:45, Gary Thomas wrote: > > What happened to 'depexp'? Is 'taskexp' supposed to be the replacement? > > Yes. > > depexp was great at leaving things out, whereas taskexp shows everything. > > It's more, but it's not missing bits. While I can concur that it is good to have more functionality, why was it deemed necessary to entirely deprecate 'depexp'? I think now that the Yocto Project is maturing, it would be good to pay more attention to retaining backwards compatibility. I may have missed it, but was there a discussion on the mailing lists about deprecating and replacing 'depexp'? Cheers, -- Rudolf J Streif signature.asc Description: This is a digitally signed message part. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding to inittab based on image content
On Saturday, January 7, 2017 10:23:50 AM PST Mike Looijmans wrote: > On 06-01-17 18:17, Rudolf J Streif wrote: > > Hi Colin, > > > > The correct way of doing this is a package postinstallation script that is > > run by the package manager after the package containing your application > > is installed on the target system. > > > > You add to your recipe: > > > > pkg_postinst_${PN}() { > > #!/bin/sh > > echo "whateveryouneed" >> ${D}/etc/inittab > > } > > Problems are that if you upgrade the application on target, it'll be > included twice, and that when you remove the application, the inittab > entry remains. If inittab itsef gets upgraded, the entry will be gone. > For the former, you use your imagination and scripting skills to see if the entry is already there and remove it or you use pkg_preinst_${PN} to remove the entry before installing. For the latter pkg_prerm_${PN} and pkg_postrm_${PN} are at your disposition. The problem you stated is actually independent of the build system. It is part of the package management. For RPM, for example, the scripts get copied into the respective sections of the package manifest: pgk_preinst -> %pre pkg_post_inst -> %post pkg_prerm -> %preun pkg_postrm -> %postun Accordingly for the other package management systems. -- Rudolf J Streif signature.asc Description: This is a digitally signed message part. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding to inittab based on image content
Hi Colin, The correct way of doing this is a package postinstallation script that is run by the package manager after the package containing your application is installed on the target system. You add to your recipe: pkg_postinst_${PN}() { #!/bin/sh echo "whateveryouneed" >> ${D}/etc/inittab } The build system will include this as the post install script into the package in the correct form for the package manager you are using e.g. RPM, DEB, IPK. This will work when the build system installs your package into the system root or when executed on the target. You can also distinguish the two cases: pkg_postinst_${PN}() { #!/bin/sh if [ x"$D" = "x" ] ; then # shell commands for target execution else # shell commands for build system execution fi } In the case of target execution $D is not set. Best regards, Rudi On Friday, January 6, 2017 1:39:40 PM PST colin.helliw...@ln-systems.com wrote: > Hi, > > I have a custom recipe for an application, and the app also needs an entry > adding to inittab. I'd like to trigger this, obviously, only when the app is > included in the image. > > I came across some hints at how to do this - > http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-c > ore/sysvinit/sysvinit-inittab_2.88dsf.bbappend?h=dizzy - but the app isn't > in DISTRO_FEATURES. (Right or wrong.., I include it in the image with a > "CORE_IMAGE_EXTRA_INSTALL +=" in my image recipe). > > Any suggestions on how to make this inittab addition conditional? > > Thanks -- Rudolf J Streif signature.asc Description: This is a digitally signed message part. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Antwort: Re: Problems with do_rootfs when changing the user password
Hi, > > How are the steps to (re)set the root password? I am using something like this to set passwords: inherit extrausers # set image root password ROOT_PASSWORD = "secret" DEV_PASSWORD = "hackme" EXTRA_USERS_PARAMS = "\ groupadd developers; \ useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \ useradd -g developers developer; \ usermod -p `openssl passwd ${ROOT_PASSWORD}` root; \ " re, please excuse: I am explaining this and more in my book "Embedded Linux Systems with the Yocto Project". > The starting point is a own layer ("myLayer") and a password > ("myNewPassword1234"). > Using your own layer for your custom distro/image configuration is the way to go. Just put the code above into your image recipe like this: SUMMARY = "Custom image recipe from scratch" DESCRIPTION = "Directly assign IMAGE_INSTALL and IMAGE_FEATURES for \ for direct control over image contents." LICENSE = "MIT" # We are using the assignment operator (=) below to purposely overwrite # the default from the core-image class. IMAGE_INSTALL = "packagegroup-core-boot packagegroup-base-extended \ ${CORE_IMAGE_EXTRA_INSTALL}" inherit core-image inherit extrausers # set image root password ROOT_PASSWORD = "secret" DEV_PASSWORD = "hackme" EXTRA_USERS_PARAMS = "\ groupadd developers; \ useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \ useradd -g developers developer; \ usermod -p `openssl passwd ${ROOT_PASSWORD}` root; \ " Best regards, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any pointers to a yocto-based image to use as a live install utility?
> > hmm ... the client requirements are only that it use u-boot, > with the mender software integrated into u-boot. so if one can > configure and build that for powerpc, then install and boot u-boot on > the target board, why should it then be restricted to ARM? > > sure, their reference board is a BBB, but a quick glance at the docs > doesn't seem to say that it works *only* on ARM. must look closer ... > Correct. However, it currently assumes the specific BeagleB* partition layout for the SSD card. But that I would think could be adjusted for other other devices. They apparently also made some modifications to u-boot itself. I don't know what exactly those are though. :rjs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any pointers to a yocto-based image to use as a live install utility?
Hi Robert, On Wednesday, May 25, 2016 06:18:34 AM Robert P. J. Day wrote: > > specifically in the context of powerpc systems, are there any > suggestions for an image that could be used to boot an older powerpc > system, running completely out of ram, and using that as an install > utility which would then be responsible for detecting/formatting a > hard drive, creating/formatting filesystems, downloading/installing > the OS, post-install configuration and so on? > I am not entirely sure if I understand your requirements correctly but this https://github.com/mendersoftware/mender[1] could eventually be a starting point. The good news is that it already comes with YP/OE recipes and integration. However, it's currently only for ARM-based systems with u-boot. Another approach, though still in its infancy and a simple PoC, is the GENIVI Software Management (SWM). At the core, there are SqashFS images that may contain partition images, software packages, configuration files, etc. together with a manifest (JSON) that instructs the SWM what to do. (https://github.com/GENIVI/genivi_swm)[2] Cheers, :rjs [1] https://github.com/mendersoftware/mender [2] https://github.com/GENIVI/genivi_swm -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] OEDAM, April 8 in San Diego after ELC
Hello Everyone: If you attended OEDAM last Friday in San Diego, I very much hope that you enjoyed being here. The Catamaran Hotel, where we held the meeting, would very much appreciate your feedback: www.catamaranresort.com/trip I hope you all had a safe trip back home, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python do_install fails on QEMUX86-64 and corei7-64 under Debian 8.0.3 isolated station
Hi Ron, On Tuesday, April 05, 2016 10:37:07 AM Ronald Oakes wrote: > When I try to build either emulated or real 64 bit distributions on an > isolated system running Debian 8.0.3 (using BB_NO_NETWORK = "1"), > utilizing a downloads directory copied from a system running Centos > 7.2.1511, I get a failure in the do_install step for Python. > Could you please post the error message from the log file of the install task for Python? > I plan on recopying Python.tar.xz onto my isolated station and trying > again. But, if this doesn't resolve the problem are there any > suggestions? > Considering that according to your info above the failure occurs during the install task, the source package is most likely not the culprit. However, the source tarball should be named something like Python-2.7.11.tar.xz which includes the version number. > For what it is worth, we're probably going to be moving to newer, but > still isolated, build stations shortly. These new stations will be > running RedHat instead of Debian if that might make a difference. > > Thank You > Ron Oakes > Best regards, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: OEDAM: New Location - Catamaran resort
We need the final headcount by next Monday. Food, breakfast, lunch and refreshments, will be provided. If you have special dietary needs such as vegetarian, gluten-free etc. please indicate so behind you name. We'll do the best to accommodate them. Rudi On Tuesday, March 29, 2016 12:57:23 PM Philip Balister wrote: > OEDAM moved. Thanks Rudi and Jefro. > > Please add your name to the attendee list so Jefro can get the correct > amount of food and coffee. He needs the number "soon". > > Philip > > Forwarded Message > Subject: OEDAM: New Location - Catamaran resort > Date: Mon, 28 Mar 2016 13:36:41 -0700 > From: Jeff Osier-Mixon > Reply-To: openembedded-memb...@lists.openembedded.org > To: openembedded-memb...@lists.openembedded.org > > > The OpenEmbedded meeting on Friday April 8, which was previously > announced, has been moved to the Catamaran Resort & Hotel. > Transportation will be provided. The meeting is still 9am-5pm. > > 3999 Mission Boulevard > San Diego, CA 92109 > 858-539-8727 > > Again, OEDAM will be at the Catamaran, NOT at the Marriott. The wiki > page and this mailing list will be updated with transportation info. > > Thanks to Rudi Streif for finding us a great location! > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] OEDAM, April 8 in San Diego after ELC
Since I happen to live in San Diego, I have been asking around for a potential meeting room (unfortunately, I don't have an office with a meeting room myself). I am currently working with the University of San Diego and the Catamaran/Bahia Hotel. Can't promise anything yet. :rjs On Thursday, March 24, 2016 11:10:41 AM Philip Balister wrote: > We are up to fifteen now and as noted will have some off site attendees > and late sign ups. > > Philip > > On 03/23/2016 02:11 PM, Fred Ollinger wrote: > > I'm coming and I'm probably brining another person. > > > > I still have to make the wiki account which failed for some reason before. > > > > Frederick > > > > From: yocto-boun...@yoctoproject.org on > > behalf of Trevor Woerner > > Sent: Wednesday, March 23, 2016 2:08 PM > > To: akuster808; openembedded-de...@lists.openembedded.org; > > openembedded-core; Yocto Project; > > openembedded-memb...@lists.openembedded.org > > Subject: Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC > > > > On Wed 2016-03-23 @ 09:36:40 AM, akuster808 wrote: > >> There are only 10 people signed up. > >> Is that enough people to justify the expense room or even meet? > > > > I have no idea what the budget might be or what a room might cost. I'll > > leave > > it to those who do know to worry about the costs versus the benefits. > > > > In any case I certainly think it's still worth meeting. A smaller, more > > focused group can sometimes get more done than a larger group. Secondly, > > it's > > my experience that more people always show up than sign up. > > > > With a project like this there will always be things to discuss, and > > sometimes > > a discussion goes better in person rather than online. > > > > Best regards, > > Trevor > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems building live image
On Monday, March 14, 2016 04:38:35 PM K Richard Pixley wrote: > > What stops us from building different boot labels for different images? > That seems like the obvious choice. Or perhaps, using "boot" for all > syslinux images and adding "install" for "live" images. Fair question. Nothing really, I would think. The classes need to be adjusted to deal with different LABELS. :rjs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Building gdb-7.10 for arm with master
At least for arm (I have not tested other arch) building gdb-7.10 with Build Configuration: BB_VERSION= "1.29.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Fedora-22" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "beaglebone" DISTRO= "poky" DISTRO_VERSION= "2.0+snapshot-20160305" TUNE_FEATURES = "arm armv7a vfp neoncallconvention-hard cortexa8" TARGET_FPU= "hard" meta meta-poky meta-yocto-bsp= "master:5cd71fe432c9bdfd3ff519543e96e8caa2b7cf6c" meta-oe meta-python = "master:36aab3f797630e3de680a88523f40ead4ca95d28" meta-qt5 = "master:88a7f264ef5f64d73881c384d22bf883b2cbf72e" compile fails with the following error message: | make[2]: *** No rule to make target '../readline/libreadline.a', needed by 'gdb'. Stop. | make[2]: *** Waiting for unfinished jobs The reason seems to be a broken path to the built-in readline in the makefile as the default configuration is --without-system-readline. Enabling PACKAGECONFIG_append_pn-dbg = " readline" solves the problem. I wonder if anybody else has observed this problem? Cheers, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [wic] Creating sdimage-bootpart
Hi Ed, > > Interesting. I thought that this commit shoud fix the issue: > http://cgit.openembedded.org/openembedded-core/commit/?id=264c03e854f77c3b62acb710384f66716ccbf469 Thanks. I was not aware of that patch. > > Which branch do you use? > Jethro. Master seems to be broken right now. It does not compile gdb-7.10.1 (at least not for ARM), which is what I need. :rjs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [wic] Creating sdimage-bootpart
I tried creating an image with wic using sdimage-bootpart which produces this error message: - wic create sdimage-bootpart -e core-image-base -D Checking basic build environment... Done. Creating image(s)... File "/run/media/rstreif/YoctoDevelop/yocto/poky/scripts/lib/wic/imager/direct.py", line 67, in __init__ self.ptable_format = self.ks.bootloader.ptable AttributeError: 'NoneType' object has no attribute 'ptable' - The reason for this message is that sdimage-bootpart.wks does not have a bootloader entry and consequently self.ks.bootloader = None. As a workaround you can of course simply adding a bootloader entry to the wks even if it's not needed/used when creating an image for Beaglebone etc. The question is what the correct behavior should be: 1. bootloader entry in wks is mandatory, then the wks parser should flag it as an error if it's not present. 2. bootloader entry in wks is optional, then the DirectImageCreator class should be able to handle that correctly. I think the latter should be the correct behavior. However, the DirectImageCreator class has some troublesome reliance on that entry, in particular that the source plugin for the overall image creation seems to be, for convenience reasons supposedly, associated with it. Cheers, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW09
> > > > > > * We're about to try and transition meta-yocto within meta-yocto to > > > > > > meta-poky. The amount of pain this is causing is horrible :(. > > > > Thanks for doing this. Can you summarize the pain? Are there any > > important lessons here? > > The key lesson is our current "migration" code in OE-Core sucks and I > have some patches in progress which rewrite pieces of it in a way that > makes it more useful. I'm therefore trying to make some positives from > it. > > That said, I haven't found a way to make this work without leaving a > dummy layer.conf in the old location since a missing layer.conf file is > fatal to bitbake very early on before any migration code triggers. > > More should become clear when I post the patches, I've been holding off > that until I actually manage a patch set that works on the > autobuilder... > > Patches should be out over the weekend (in time for the freeze). Sounds like a lot of work and potential for breaking things with little added value other than a more consistent naming. What was the rationale for making the change, if I may ask? Thanks, :rjs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Package Level Dependencies
Hi Sebastian, > > Thnx for your input! I guess I can see your point. In particular I wasn't > thinking so much on using ".inc" files. Due to the fact that I will be > having like 10-20 different test123-config-xxx packages managing this using > "RCONFLICTS" might be tedious. I guess this is what virtual packages (say > test123-config-xxx has something like PROVIDES=virtual/test123-config and > test123 has a RDEPENDS on virtual/test123-config) are for and I will try to > follow this path for now. > Well, that wouldn't solve the problem of having 10 to 20 different recipes either, since you would have to write a recipe for each config file with a specific PROVIDES in it. > For a couple of reasons, the configuration files are in the same git > repository as the source code of "test123". Is there a way of sharing > working directories between (at least all config-package recipes, such as I > don't net to checkout the whole git repository for each of my 10-20 config > packages? > I suppose you are talking about a remote Git repository. The do_fetch task will first check it out locally to DL_DIR. If all of your config recipes use the same URL for the source BitBake would only check it out once locally to DL_DIR. That automatically saves the download step. However, for each recipe the do_unpack task would copy the config sources from DL_DIR to ${S}. You could skip do_unpack and point ${S} to a different directory, but that is getting rather messy. I would not recommend it. Essentially, what approach to take comes actually down to what the criteria are to select one configuration file over the other. What is it dependent on that you select test123-config-XXX rather than test123-config-YYY? If it is a build-time dependency such as the MACHINE then you can do a conditional override, as Philipp Ballister suggested. If it is a build configuration dependency you could resolve it in the install task. Maybe you could define your own configuration variable that you set in local.conf (or in a disto configuration file): TEST123_CONFIG = "XXX" Recipe: do_install_append () { # install config file here install 544 test123-${TEST123_CONFIG}.conf ${D}/ } Cheers, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Package Level Dependencies
Hi Sebastian, > I have a recipe (say: "test123") that provides a complex piece of software > (cmake-based). The software needs some configuration file (say > "test123.conf"). There are multiple variants of the configuration file, > sharing the same name, i.e. "test123.conf" exists in different variants for > multiple hardware configurations. > > My aim would be to have multiple packages like "test123-config-XXX" and > "test123-config-YYY", that cannot be installed at the same time, while > having one of the packages is a dependency for the main package "test123". These are two conflicting packages. > > Is there a way to achieve this? From my current understanding, dependencies > are "per-recipe" and not "per-package". Is there any way to achieve package > level dependencies? I would like to avoid having multiple recipes as there > are many configuration file options which are currently located in the same > large source repository as the main software. Look at it from the perspective of conflicting packages. My approach to this would be the following: 1. Write an include file test123.inc that includes all of the guts of your recipe. 2. Write the two recipes test123-config-XXX_1.0.bb and test123-config- YYY_1.0.bb: test123-config-XXX_1.0.bb require test123.inc SRC_URI += "test123-XXX.conf" do_install_append() { # install config file here install 544 test123-XXX.conf ${D}/ } RCONFLICTS_${PN} = "test123-config-YYY" Analog for test123-config-YYY_1.0.bb You are essentially sharing all of the recipe through the test123.inc and only add the config file to the respective target recipe. The RCONFLICTS_${PN} directive will flag an error if both conflicting packages are attempted to be installed. BR, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Toaster] Production Instance Setup
Hi Everyone: I am trying to set up Toaster in a production environment with Apache etc. The web server setup is ok. It is running builds where I am currently stuck. I am using the Jethro branch from the git repo. According to step 7 in [1] one needs to start /var/www/toaster/poky/bitbake/lib/toaster/manage.py runbuilds to start the runner service to dispatch builds. If there are currently no pending builds (non yet created using the web UI) then running this command immediately returns. The command gets dispatched to poky/bitbake/lib/toaster/bldcontrol/management/commands/runbuilds.py In its command help it states: 14: help= "Schedules and executes build requests as possible. Does not return (interrupt with Ctrl-C)" However, that is apparently not the case because if there is not build request pending then 35:try: 36:# select the build environment and the request to build 37: br = self._selectBuildRequest() 38:except IndexError as e: 39:logger.debug("runbuilds: No build request") 40:return If you use the web UI and schedule (start) a build first and then execute runbuilds, then the command eventually fails with: 2016-01-14 21:37:54,086 DEBUG lbc_shellcmmd: () git remote -v Traceback (most recent call last): File "/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/management/commands/runbuilds.py", line 59, in schedule bec.triggerBuild(br.brbitbake_set.all(), br.brlayer_set.all(), br.brvariable_set.all(), br.brtarget_set.all()) File "/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py", line 365, in triggerBuild self.setLayers(bitbake, layers, targets) File "/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py", line 229, in setLayers for remotes in self._shellcmd("git remote -v", self.be.sourcedir).split("\n"): File "/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py", line 61, in _shellcmd p = subprocess.Popen(command, cwd = cwd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) File "/usr/lib64/python2.7/subprocess.py", line 710, in __init__ errread, errwrite) File "/usr/lib64/python2.7/subprocess.py", line 1335, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory: '' This is because the BuildEnvironment object in the database has empty fields for Sourcedir and Builddir. One can fix that by going into the Django admin interface and enter paths into these fields of the one BuildEnvironment object that is in the database. Once the paths are entered and the build is started again then it breaks where runbuilds apparently waits for the Bitbake server to be available: 2016-01-14 22:14:54,565 DEBUG lbc_shellcmmd: (/home/fedora/source) bash -c "source /home/fedora/source/_toaster_clones/_git___git.yoctoproject.org_poky_master/oe-init-build-env /home/fedora/build 2>&1 >toaster_server.log && bitbake --read /home/fedora/build/conf/toaster-pre.conf --postread /home/fedora/build/conf/toaster.conf --server-only -t xmlrpc -B 0.0.0.0:0 2>&1 >>toaster_server.log " 2016-01-14 22:14:55,540 DEBUG localhostbecontroller: shellcmd success 2016-01-14 22:14:55,540 DEBUG localhostbecontroller: Found bitbake server port 33438 2016-01-14 22:14:55,543 DEBUG localhostbecontroller: Waiting bitbake server to start ... repeated 50 times ... 2016-01-14 22:15:20,595 ERROR runbuilds: Error launching build localhostbecontroller: Bitbake server did not start in 25 seconds, aborting (Error: ' That is in the file /var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py at lines: 146 while not started and retries < 50: 147 started = _toaster_ui_started(toaster_ui_log_filepath, toaster_ui_log_filelength) 148 import time 149 logger.debug("localhostbecontroller: Waiting bitbake server to start") 150 time.sleep(0.5) 151 retries += 1 The function _toaster_ui_started() that checks if Bitbake is running is defined as: 133 def _toaster_ui_started(filepath, filepos = 0): 134 if not os.path.exists(filepath): 135 return False 136 with open(filepath, "r") as f: 137 f.seek(filepos) 138 for line in f: 139 if line.startswith("NOTE: ToasterUI waiting for events"): 140 return True 141 return False Apparently, it is looking for a line to start with the string "NOTE: ToasterUI waiting for events" in the file toaster_ui.log which is located inside the build environment that is initialized with oe-init-build-env. I grepped the Poky code base for that string and could not find any code module that ever writes that string into any file. What the file does contain though is a lin
Re: [yocto] Setting root password
Hi Andy, Daniel On Thursday, September 24, 2015 11:20:37 AM Daniel. wrote: > Still, I think is a good ideia to understand what is going wrong with > EXTRA_USERS_PARAMS, other users may having the same problem. EXTRA_USERS_PARAMS works for me all the time. The stanza is what I am using in my image recipes: EXTRA_USERS_PARAMS = "\groupadd developers; \useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \useradd -g developers developer; \ usermod -p `openssl passwd ${ROOT_PASSWORD}` root; \ " If this is an accurate copy of what you are using (from you first email) > EXTRA_USERS_PARAMS = "usermod -P root;" then the issue probably is the capital -P. It should be lowercase. Cheers, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gdb/gdbserver vs. eclipse
Hi Robert, > > Which Yocto version do you use? I use 1.8 I am using 1.8, too. Just sent another e-mail about the TCF agent. However, that's only in addition since TCF is not used for debugging with GDB. Eclipse wraps around GDB which then communicates directly with the GDB server on the target. > So let's try to summarize what seems to be necessary: > > 1) right .gdbinit on the right place ;) yeap > 2) Debug Configurations -> Debugger -> Main -> Use full file path to set > breakpoints (might not even be necessary) I don't need that. > 3) Debug Configurations -> Debugger -> Shared Libraries -> Load shared > library symbols automatically > yeap Cheers, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gdb/gdbserver vs. eclipse
Robert, What version of Poky/OpenEmbedded Core (meta) are you using? I found that including Fido (1.8) the tcf-agent built by meta was stuck at version 0.4.0. That causes issues with running on the target and getting the console output back to Eclipse. That's now updated to 1.3 in master for Eclipse Mars. I built 1.2 for Luna which works, but 1.3 works with Luna too. Cheers, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gdb/gdbserver vs. eclipse
> > I think I made some progress - see attached image. Good. > > As you can see I stepped into printf and friends. > > For this to work I needed a few more things: > > 1) directory needs the be the same on host and target > > the executable on the host: > > /home/student/BBBworkspace/HelloBBBAutotooled/src/HelloBBBAutotooled > > the executable on the target: > > /home/student/BBBWorkspace/HelloBBBAutotooled/src/HelloBBBAutotooled > I do not have to do that. As a matter of fact the executable on my target is copied to /usr/bin from the Eclipse workspace. See "Remote Absolute File Path" in the Debug Configuration. > 2) .gdbinit > > I copied my gdbinit on the host to > > /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit > Yes, that's where Eclipse's Debug Configuration expects it if you do not change the setting of "GDB Command File" in the Main subtab of the Debugger tab in the Debug configuration. > that's the .gdbinit > > # don't use default libs from x86/Ubuntu: > set sysroot /opt/adt-target-sysroot/beagle-bone-black-ml > set solib-absolute-prefix /opt/adt-target-sysroot/beagle-bone-black-ml > set solib-search-path /opt/adt-target-sysroot/beagle-bone-black-ml > # point to the libraries with debug info: > set debug-file-directory > /opt/adt-target-sysroot/beagle-bone-black-ml/usr/lib/debug > # point to the source code: > set substitute-path /usr/src/debug > /opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug > set substitute-path / > /opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug > Yes, looks like mine except that my target is a MinnowBoard Max and I installed my SDK in a different location. > 3) Once you enter the debug view you need to go to the gdb console and: > > source /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit > Strange. I don't have to do that if GDB command file is set to the path in the workspace. I would expect that Eclipse passes the .gdbinit from the workspace explicitly to GDB. However, I do have add-auto-load-safe-path . in my global .gdbinit (~/.gdbinit). Cheers, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Slashes in branch names
Michael, Could you please be more specific on what the issue is? The Yocto Project's kernel repos use slashes in branch names. :rjs On Monday, February 09, 2015 07:10:49 PM Harvey, Michael wrote: > Our git SCM infrastructure uses slashes in the branch names (android style) > for organization, and that breaks yocto. Is there any way to support this > in yocto? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto