| *** lfa <lfa!~lfa@213-47-163-50.cable.dynamic.surfer.at> has quit IRC | 00:15 | |
| *** lfa <lfa!~lfa@213-47-163-50.cable.dynamic.surfer.at> has joined #yocto | 00:15 | |
| *** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto | 00:44 | |
| *** nighty- <nighty-!~nighty@kyotolabs.asahinet.com> has joined #yocto | 00:46 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 01:05 | |
| *** Willy-- <Willy--!~william@156.34.251.99> has quit IRC | 01:29 | |
| *** Cbast <Cbast!~sfrigon@107.190.38.187> has quit IRC | 01:37 | |
| *** jesseg <jesseg!~jesseg@64.146.180.159> has left #yocto | 01:37 | |
| *** Cbast <Cbast!~sfrigon@107.190.38.187> has joined #yocto | 01:37 | |
| *** Cbast <Cbast!~sfrigon@107.190.38.187> has quit IRC | 01:55 | |
| *** Cbast <Cbast!~sfrigon@107.190.38.187> has joined #yocto | 01:58 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 02:16 | |
| *** kaspter <kaspter!~Instantbi@115.194.184.253> has quit IRC | 02:23 | |
| *** kaspter <kaspter!~Instantbi@115.194.184.253> has joined #yocto | 02:25 | |
| *** dv_ <dv_!~dv@62.178.50.190> has joined #yocto | 02:29 | |
| *** Cbast <Cbast!~sfrigon@107.190.38.187> has quit IRC | 02:40 | |
| *** rubdos <rubdos!~rubdos@ptr-1uzevqefjgxdm5wv65h.18120a2.ip6.access.telenet.be> has quit IRC | 02:53 | |
| *** rubdos <rubdos!~rubdos@ptr-1uzevqefjgxdm5wv65h.18120a2.ip6.access.telenet.be> has joined #yocto | 03:35 | |
| *** lfa <lfa!~lfa@213-47-163-50.cable.dynamic.surfer.at> has quit IRC | 04:16 | |
| *** lfa <lfa!~lfa@213-47-163-50.cable.dynamic.surfer.at> has joined #yocto | 04:16 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 04:20 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:26 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:28 | |
| *** lpotter <lpotter!~quassel@2001:8003:e172:cb00:ba27:ebff:febb:59b> has joined #yocto | 04:35 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:38 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:40 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 04:55 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 04:55 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 04:58 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 05:05 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 05:07 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 05:08 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 05:09 | |
| *** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto | 05:11 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto | 05:12 | |
| *** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has quit IRC | 05:19 | |
| *** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto | 05:20 | |
| *** pohly <pohly!~pohly@p54BD55A3.dip0.t-ipconnect.de> has joined #yocto | 05:39 | |
| *** agust <agust!~agust@p508DEB69.dip0.t-ipconnect.de> has joined #yocto | 05:42 | |
| *** lpotter <lpotter!~quassel@2001:8003:e172:cb00:ba27:ebff:febb:59b> has joined #yocto | 06:12 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto | 06:15 | |
| *** anujm <anujm!anujm@nat/intel/x-zdummmybfwjferme> has joined #yocto | 06:24 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 06:24 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 06:28 | |
| *** lfa <lfa!~lfa@213-47-163-50.cable.dynamic.surfer.at> has quit IRC | 06:31 | |
| *** morphis <morphis!~morphis@p5DCC3338.dip0.t-ipconnect.de> has joined #yocto | 06:48 | |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 07:00 | |
| *** tprrt <tprrt!~tprrt@217.114.201.133> has joined #yocto | 07:08 | |
| *** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC | 07:10 | |
| *** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto | 07:11 | |
| *** fl0v0 <fl0v0!~fvo@mue-88-130-100-110.dsl.tropolys.de> has joined #yocto | 07:14 | |
| RP | morning | 07:17 |
|---|---|---|
| LetoThe2nd | RP: i can confirm that. | 07:19 |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 07:23 | |
| *** zagor <zagor!~zagor@rockbox/developer/Zagor> has joined #yocto | 07:38 | |
| *** Jay7 <Jay7!~quassel@111.65.46.105> has joined #yocto | 07:45 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:51 | |
| *** ak77 <ak77!c12e4b03@gateway/web/freenode/ip.193.46.75.3> has joined #yocto | 07:52 | |
| *** sstiller <sstiller!~sstiller@b2b-94-79-174-114.unitymedia.biz> has joined #yocto | 07:52 | |
| ak77 | Hello! what should I clean after adding `inherit allarch` ? image making (do_rootfs) still wants arch specific ipk altough -all.ipk has been created | 07:53 |
| ak77 | I did image-name -c cleanall but that's not it | 08:00 |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 08:23 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 08:24 | |
| *** micka <micka!~micka@reverse-75.fdn.fr> has quit IRC | 08:25 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 08:25 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has quit IRC | 08:26 | |
| *** User__ <User__!~learningc@mti-37-145.tm.net.my> has joined #yocto | 08:26 | |
| *** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto | 08:28 | |
| *** frsc_ <frsc_!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto | 08:31 | |
| *** frsc_ <frsc_!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC | 08:31 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:32 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC | 08:32 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:36 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:39 | |
| *** anujm <anujm!anujm@nat/intel/x-zdummmybfwjferme> has quit IRC | 08:41 | |
| *** lusus <lusus!~lusus@62.91.23.180> has joined #yocto | 08:47 | |
| ak77 | ak77: false alarm, i had two inherit lines.. it works with single one | 08:53 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-jsfrnpmxizpdihzv> has joined #yocto | 08:53 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:56 | |
| *** AndersD_ <AndersD_!~AndersD@194.237.220.218> has joined #yocto | 09:05 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:07 | |
| *** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has quit IRC | 09:08 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 09:19 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 09:34 | |
| *** Jay7 <Jay7!~quassel@111.65.46.105> has quit IRC | 09:40 | |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-091-089-212-176.hsi2.kabel-badenwuerttemberg.de> has quit IRC | 09:43 | |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-091-089-212-176.hsi2.kabel-badenwuerttemberg.de> has joined #yocto | 09:49 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:51 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-ccwfivynghbnfbnm> has joined #yocto | 09:56 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:58 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 09:59 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 10:02 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:06 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 10:09 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto | 10:10 | |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-091-089-212-176.hsi2.kabel-badenwuerttemberg.de> has quit IRC | 10:11 | |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-091-089-212-176.hsi2.kabel-badenwuerttemberg.de> has joined #yocto | 10:12 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 10:17 | |
| *** ejoerns <ejoerns!~ejo@2001:67c:670:100:76d4:35ff:fee8:98b3> has joined #yocto | 10:18 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 10:25 | |
| learningc | What can I do with rpm files? | 10:25 |
| LetoThe2nd | learningc: Revolute them Per Minute. | 10:27 |
| learningc | Ok, what else? | 10:28 |
| LetoThe2nd | learningc: possibly also use them as the defined format for the RedhatPackageManager | 10:28 |
| jofr | learningc: It's a package format. You can use it to manage (install, uninstall, update, etc.) software packages. It also contains meta-data, such as dependencies and all sorts of wonderful things. | 10:31 |
| learningc | Ah I see. Thanks jofr. (sorry I'm new to what package was in yocto, but now I know) | 10:33 |
| jofr | RPM is just one package format out of many. And Yocto can generate a few different formats. | 10:34 |
| learningc | How do I install a package? | 10:34 |
| learningc | "I have rpm format currently" | 10:34 |
| learningc | Is there a command to issue like "apt install" as in ubuntu? | 10:35 |
| LetoThe2nd | learningc: manually installing packages should totally be the last resort. just use IMAGE_INSTALL, and have everything done automatically. | 10:35 |
| jofr | Yes. It's "rpm". But like LetoThe2nd says, if you're doing a Yocto-build it probably want to have the build-system install the package into your image. | 10:36 |
| learningc | LetoThe2nd, But with IMAGE_INSTALL, the package will be in my rootfs? | 10:36 |
| LetoThe2nd | learningc: under the hood, IMAGE_INSTALL does exactly that, it installs the package into the image. but without the hassles of finding and copying, and leftovers from the package manager | 10:37 |
| learningc | The problem is, I made a lot of changes on my board in my current root fs, so I don't want to rewrite a new rootfs onto my board right now... | 10:38 |
| jofr | learningc: But I think perhaps you should take a step back, and explain what it is you're trying to do. | 10:38 |
| LetoThe2nd | learningc: better walk through the changes and document them. | 10:38 |
| LetoThe2nd | e.g. make proper recipes. | 10:38 |
| learningc | Ya, that's what I should do in the later stages, but now I just want to test with the current rootfs without destroying all the changes and somehow I need to install a new application. How should I do it? | 10:40 |
| LetoThe2nd | learningc: well if you do not have package management already enabled in the image, then: not at all, because the tools will not be there. | 10:40 |
| learningc | How do I verify if I have a package management enabled on my board? | 10:41 |
| jofr | Try to write: rpm | 10:41 |
| learningc | ok | 10:41 |
| jofr | "rpm" is the tool for.... | 10:42 |
| jofr | it's THE rpm.. | 10:42 |
| learningc | I typed in rpm, but nothing happens | 10:42 |
| LetoThe2nd | see, no package management. also known as, the default situation. | 10:42 |
| learningc | But I did not get any "command not found" | 10:42 |
| learningc | rpm: --hash (-h) may only be specified during package installation <- I get this when I type rpm -h | 10:43 |
| learningc | So it's there? | 10:43 |
| LetoThe2nd | lucky you, it is enabled then. | 10:43 |
| learningc | But how do I install a package with it? | 10:44 |
| jofr | Then refer to the documentation and see if you can install some packages. :-) https://linux.die.net/man/8/rpm | 10:44 |
| LetoThe2nd | you build the package, copy it over, then install it. | 10:44 |
| learningc | Any quick command snippet to install foo.rpm? | 10:45 |
| LetoThe2nd | no | 10:45 |
| LetoThe2nd | it does not work like that. | 10:45 |
| LetoThe2nd | there is no upstream repository server from which you could get all that stuff automatically. | 10:45 |
| learningc | I see. | 10:45 |
| jofr | learningc: Are you trying to make your build-system install an RPM package or are you trying to manually install a package you have into your system? | 10:46 |
| learningc | jofr, I'm trying to install manually my own package I built previously, to add it into the current rootfs | 10:47 |
| learningc | I have copied my rpm file onto my board already | 10:47 |
| jofr | On a rootfs on a running system (like on a board that's sitting on your desk), or are you trying to create a rootfs image with your package? | 10:47 |
| learningc | jofr, rootfs on a running system | 10:48 |
| jofr | So if you're just trying to install an RPM onto a single board, then you do (as the manual says) rpm -i packagename.rpm | 10:48 |
| learningc | ok | 10:48 |
| jofr | But keep in mind, what you're doing is just gaining more and more software-debt. You will have to write all of this into recipes eventually if you intend to do this for another board. | 10:49 |
| learningc | Ok, I did. But it's weird. I issued the command and it returns right away to the command line. I don't see any messages on screen. Is that normal? | 10:50 |
| jofr | I have no idea. Haven't used rpm for more than a decade. | 10:51 |
| jofr | My guess is that if it didn't report any errors, it worked. | 10:52 |
| jofr | Think of the tool "rpm" in the same way as "dpkg" on Debian-based systems. Apt is a system on top of dpkg, just as there do exist systems on top of "rpm", such as Yum and DNF. | 10:53 |
| learningc | hmm, looks like it works, but I'm not sure | 10:53 |
| learningc | when I do rpm -i mpackage.rpm a second time, it reports my package is already installed | 10:54 |
| jofr | Ok | 10:54 |
| jofr | Is the stuff you meant to install there? | 10:54 |
| jofr | Normally, when one requires a package to be installed, one tends to know what problem that package is supposed to solve. Is you problem solved? | 10:57 |
| learningc | Yep, looks like it's all there. I guess it's a success :) Thanks jofr | 10:58 |
| *** tgoodwin <tgoodwin!~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net> has joined #yocto | 10:58 | |
| learningc | In my case, I only need to add in a new application | 10:59 |
| *** jofr <jofr!~jofr@193.182.166.3> has left #yocto | 11:00 | |
| *** jofr <jofr!~jofr@193.182.166.3> has joined #yocto | 11:00 | |
| jofr | learningc: Great! :-) But I would suggest you become more familiar to working with a Linux-system, it's internals, the command-line, management and get to know where to find documentation. Because there does exist vast amounts of documentation for all of this. :-) | 11:02 |
| *** sagner <sagner!~ags@46.140.72.82> has joined #yocto | 11:03 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 11:07 | |
| *** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has joined #yocto | 11:09 | |
| *** cquast <cquast!~cquast@90.85.130.193> has joined #yocto | 11:10 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 11:19 | |
| yocti | New news from stackoverflow: How to setup SPI Driver for Yocto <https://stackoverflow.com/questions/52815596/how-to-setup-spi-driver-for-yocto> | 11:28 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 11:35 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 11:43 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 11:46 | |
| *** Crofton <Crofton!~balister@c-73-152-143-112.hsd1.va.comcast.net> has quit IRC | 11:49 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 11:53 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 11:57 | |
| *** Crofton <Crofton!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto | 11:58 | |
| *** AndersD_ <AndersD_!~AndersD@194.237.220.218> has quit IRC | 12:02 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 12:04 | |
| *** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto | 12:05 | |
| tgoodwin | Has anyone run into an issue where CMake 'find_program' cannot locate a -native package (like sed)? | 12:08 |
| LetoThe2nd | tgoodwin: most trivial reason would be that you do not explicitly DEPEND on it, and therefore it does not show up in the recipe specific sysroot | 12:11 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 12:17 | |
| *** geissonator <geissonator!~geissonat@cpe-24-198-214-139.maine.res.rr.com> has joined #yocto | 12:22 | |
| *** no_such_user <no_such_user!~pev@fpc125996-trow7-2-0-cust59.18-1.static.cable.virginm.net> has joined #yocto | 12:27 | |
| no_such_user | Ello... Something interesting just happened to me. I'm on an Ubuntu 16.04 build machine (updated to today) and doing some benchmark builds using a clean clone yocto 2.5.1. (Im trying to look at the impact of disk performance on build time planning a new build machine). Ive done two test builds of core-image-sato, one on a NVMe drive and one on a 2.5" samsung ssd. Both completed OK. I'm now building on a old 2.5" | 12:32 |
| no_such_user | SSHD (hybrid) and about 2/3rd of the way through it causes X/unity to crash and burn...! Has anyone experienced anything similar before? I thought it was a really odd thing to happen so Ive replicated the build a couple of times and it's consistent... | 12:32 |
| LetoThe2nd | no_such_user: only thing that comes to mind is OOM kicking in | 12:36 |
| no_such_user | LetoThe2nd: I don't see the OOM Killer logging anything in syslog... | 12:37 |
| LetoThe2nd | no_such_user: ok | 12:38 |
| no_such_user | first thing in syslog is : | 12:38 |
| no_such_user | org.a11y.atspi.Registry[2904]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" | 12:38 |
| no_such_user | org.a11y.atspi.Registry[2904]: after 16853 requests (16853 known processed) with 0 events remaining. | 12:38 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-jsfrnpmxizpdihzv> has quit IRC | 12:43 | |
| *** zeddii <zeddii!~bruce@128.224.252.2> has joined #yocto | 12:43 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 12:45 | |
| *** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto | 12:46 | |
| *** rburton <rburton!~textual@35.106.2.81.in-addr.arpa> has joined #yocto | 12:47 | |
| *** marka <marka!~masselst@184.175.21.100> has joined #yocto | 12:54 | |
| tgoodwin | LetoThe2nd: it's in my recipe's DEPENDS, but I just realized hasn't been getting installed into the recipe-sysroot-native. | 12:54 |
| tgoodwin | (since it's part of ASSUME_PROVIDED) | 12:55 |
| tgoodwin | LetoThe2nd: patching the line to set the variable to simply "sed" works, but it left me wondering if maybe there was a better solution. | 12:56 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 13:01 | |
| lpapp | hi, I type bitbake u-boot, but the binary is not getting generated, why is that? | 13:02 |
| lpapp | I was expecting it appearing in tmp/deploy/images/$foo | 13:02 |
| *** sagner <sagner!~ags@46.140.72.82> has quit IRC | 13:03 | |
| rburton | images is for images, u-boot doesn't build an image but packages | 13:04 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 13:04 | |
| tgoodwin | lpapp: expanding on rburton's answer, your packages get built in tmp/work (WORKDIR) depending on architecture, etc. | 13:05 |
| tgoodwin | (sorry, WORKDIR for clarity includes your package so tmp/work/arch/package/version) | 13:05 |
| lpapp | is this true | 13:05 |
| lpapp | I used to have u-boot*.bin generated there long time ago... have any recent yocto releases changed this operation | 13:06 |
| tgoodwin | It's likely off in your work directory. | 13:06 |
| lpapp | u-boot is definitely not a package | 13:06 |
| lpapp | you flash the binary over tftp, or whatever | 13:06 |
| tgoodwin | Once you bitbake an image recipe, it'll get staged to your image. | 13:06 |
| lpapp | serial flasher, etc | 13:07 |
| lpapp | it has nothing to do with ipk or any kind of packages | 13:07 |
| lpapp | u-boot is a bootloader | 13:07 |
| lpapp | it has no concept of package at that low level at all | 13:07 |
| lpapp | for a package, you need to have an OS that understand packages, but a bootloader comes before any such OS | 13:08 |
| *** ntl <ntl!~nathanl@nat-wv.mentorg.com> has joined #yocto | 13:11 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 13:11 | |
| tgoodwin | "Package" perhaps is a bit overloaded. I get what you're trying to say, but what we're getting at is still the same. You're basically doing "bitbake <recipe name>" and typically the name of the recipe is also the package name. PN | 13:12 |
| tgoodwin | https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#var-PN | 13:12 |
| tgoodwin | So in that definition, U-boot is a package. | 13:12 |
| lpapp | I do not follow | 13:12 |
| lpapp | I used to get the u-boot binary in the aforementioned location after building the image | 13:12 |
| tgoodwin | Correct, _after_ building an image. | 13:13 |
| lpapp | why am I not getting it now? Has this logic changed with any recent Yocto release? | 13:13 |
| tgoodwin | You stated you were running "bitbake u-boot" -- u-boot is not an image definition. | 13:13 |
| lpapp | I have built an image | 13:13 |
| lpapp | no | 13:13 |
| lpapp | I have also built foo-core-image | 13:13 |
| lpapp | which builds my rootfs | 13:13 |
| tgoodwin | Is your MACHINE set? Does your machine have IMAGE_BOOT_FILES set with u-boot.bin? https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#var-IMAGE_BOOT_FILES | 13:14 |
| lpapp | has this logic changed recently | 13:14 |
| lpapp | recently, as in last five years | 13:14 |
| lpapp | we were stuck with daisy before now going to m... | 13:14 |
| LetoThe2nd | lpapp: it changed in k or m, as people tended to abuse/misinterpret the deploy dir :-) | 13:15 |
| LetoThe2nd | it got bitten by it too, but hey. another thing learnt | 13:16 |
| lpapp | ok, so let me check that machine thing | 13:16 |
| lpapp | MACHINE is not set | 13:17 |
| lpapp | MACHINE_ARCH is | 13:17 |
| tgoodwin | Chances are not having MACHINE set is part of the key since that's going to globally define what all gets setup for the boot files vs. the root file system. | 13:17 |
| lpapp | output of bitbake -e foo-core-image | grep ^MACHINE: https://paste.kde.org/pcm9vwnxj/cpsduo/raw | 13:17 |
| LetoThe2nd | heh yeah, it was DEPLOY_DIR versus IMGDEPLOYDIR | 13:18 |
| lpapp | sorry, MACHINE is set via ./conf/local.conf.sample | 13:20 |
| lpapp | MACHINE ?= ... | 13:20 |
| lpapp | but bitbake -e would not see it? | 13:20 |
| tgoodwin | That would only set it if it was the template for your actual build/conf/local.conf | 13:21 |
| lpapp | yes, it is | 13:21 |
| lpapp | my build/conf/local.conf gets that | 13:21 |
| lpapp | bitbake -e foo-core-image | grep ^IMAGE_BOOT_FILES -> returns empty | 13:23 |
| lpapp | is that the issue | 13:23 |
| lpapp | I actually do not believe that u-boot is a boot file for the image | 13:24 |
| lpapp | it sounds more like uImage or zImage, etc, that would be a boot file for the image to be honest | 13:25 |
| lpapp | I am very very confused why u-boot*.bin is not getting generated as it used to | 13:25 |
| lpapp | please help | 13:25 |
| *** morphis <morphis!~morphis@p5DCC3338.dip0.t-ipconnect.de> has quit IRC | 13:25 | |
| tgoodwin | Well there's a few things. IMAGE_BOOT_FILES only indicates what is expected to be pulled together from the images directory to make your boot partition | 13:26 |
| tgoodwin | The EXTRA_IMAGEDEPENDS is what I tend to use (and see used) as a way to indicate what packages get built for a given machine. | 13:26 |
| tgoodwin | (i.e., I usually see it set in the machine def'n, and those recipes end up having to explicitly install thing into the image staging directory) | 13:26 |
| lpapp | yes, I have u-boot | 13:26 |
| lpapp | EXTRA_IMAGEDEPENDS += "u-boot" | 13:27 |
| lpapp | so what is the problem, why is the bootloader image not getting generated? | 13:27 |
| lpapp | I get this WARNING: /home/lpapp/Projects/polatis/nicbuild/poky/../meta-polatis/recipes-bsp/u-boot/u-boot_2017.01.bb.do_install is tainted from a forced run | 13:28 |
| lpapp | I wonder whether that could be a contributing factor for it not getting generated | 13:28 |
| lpapp | and if so, how could I avoid that, clean build only? | 13:29 |
| tgoodwin | Well, if you ran bitbake with the force flag, you'll get that. | 13:29 |
| lpapp | yes, but is that the reason for this not getting generated in the right place? | 13:30 |
| tgoodwin | As long as your image has IMAGE_FSTYPES set, you should end up with a tarball, or whatever you've specified, over in that images tmp/deploy/images/machine path. | 13:30 |
| lpapp | machine? | 13:30 |
| lpapp | no | 13:30 |
| lpapp | not tarball, I used to get a .bin file | 13:30 |
| lpapp | I do get the rootfs image there, but not the bootloader image | 13:31 |
| lpapp | what is going on | 13:31 |
| tgoodwin | The bootloader image, like u-boot.bin, is going to be in the recipe's work directory until you bake an image and machine combination that requires pulling those files together into the images directory. | 13:32 |
| lpapp | ok, so the question is the same: why is the u-boot*.bin file not getting into ./tmp/deploy/images/machine after building the image while the image is? | 13:33 |
| lpapp | I guess I will have to try a brand new clean build if no idea... | 13:34 |
| lpapp | in which case I will only see the result in about an hour | 13:35 |
| tgoodwin | The u-boot.bin should get pulled into the image directory as long as the machine depends on it. | 13:35 |
| tgoodwin | You've shown that MACHINE is not defined, so that seems to be the top-level issue. | 13:36 |
| tgoodwin | "as long as the machine depends on it" -- what I mean is that EXTRA_IMAGEDEPENDS variable being set, really, somewhere to include that file. | 13:36 |
| lpapp | MACHINE ?= is in my ./build/conf/local.conf | 13:37 |
| lpapp | so why would it not be defined | 13:37 |
| tgoodwin | If it's actually defined, even weak like that globally, it should have come out when you ran "bitbake -e" against any recipe, since it would have been globally set. | 13:38 |
| *** morphis <morphis!~morphis@pD9E2FD78.dip0.t-ipconnect.de> has joined #yocto | 13:38 | |
| lpapp | ok, so what is the next step to do? | 13:39 |
| tgoodwin | It sounds like the problem is environmental. If I'm off the rails a bit, I'm sure one of these more proficient folks will jump in, but that's the dots you're trying to connect. Typically, I define my machine (hard set, MACHINE=) in my local conf, or export the variable. That definition then has EXTRA_IMAGEDEPENDS against a recipe (or virtual name), and I identify an output file in IMAGE_BOOT_FILES. Since you' | 13:43 |
| tgoodwin | re using u-boot (assuming standard recipe), it should handle staging files, I would think. I mean, there are a few other U-boot environment variables defining things like what boot loader to use from U-boot, but that's going to depend again on your particular configuration. | 13:43 |
| tgoodwin | If your'e not using a standard machine, maybe compare notes against an existing one from meta-intel or meta-yocto-bsp? | 13:44 |
| tgoodwin | *you're | 13:44 |
| lpapp | not sure standard u-boot, as we need to adopt it for our own board | 13:44 |
| lpapp | but it is two patches off of 2017.01, I believe | 13:44 |
| lpapp | but it used to work ok | 13:44 |
| tgoodwin | "standard" I mean one of the recipes-bsp/u-boot/u-boot_???.bb recipe from meta, for example. | 13:46 |
| lpapp | oh, no, nah | 13:46 |
| lpapp | we have to grab it from our source url, etc. | 13:46 |
| *** no_such_user <no_such_user!~pev@fpc125996-trow7-2-0-cust59.18-1.static.cable.virginm.net> has quit IRC | 13:47 | |
| jofr | lpapp: IMO, in most cases you shouldn't have to be doing any extreme changes to your u-boot, so having your image depend on u-boot, and creating a .bbappend with your patches should suffice..? Maintaining a whole fork of something like u-boot probably ends up being more painful. | 13:51 |
| jofr | s/image depend on u-boot/machine depend on u-boot/ | 13:52 |
| lpapp | no, we do not want to use .bbappend for patches as that is a mess | 13:52 |
| lpapp | when I need to adjust u-boot for further hardware changes, I want to have a version controlled checkout of u-boot myself, and not inside some buildsystem, but cleanly. | 13:53 |
| jofr | I'm arguing that what you're doing is an even bigger mess. But that's fine. :-) Just my opinion. :-) | 13:53 |
| lpapp | there is not much painful about a dedicated topic branch for our board at all | 13:53 |
| lpapp | pain* | 13:53 |
| lpapp | what would be painful about it really? | 13:53 |
| jofr | Ok :) | 13:53 |
| lpapp | If anything, it is less painful because I can check out master or any release branches right away there easily | 13:54 |
| lpapp | I can merge changed from master and release branches to my board branch, etc. | 13:54 |
| lpapp | my development workflow should not depend on a specific arm buildsystem workflow | 13:54 |
| lpapp | my buildsystem workflow for a particular board ought to depend on my development workflow | 13:55 |
| lpapp | buildsystem is subordinate or downstream to the actual source, which is considered upstream | 13:55 |
| lpapp | also, if we switch away from Yocto, the thing should still contain everything we need, so the extra stuff is not Yocto specific | 13:55 |
| rburton | lpapp: painful because if you can just bbappend the oe-core recipe with your small patch (which is being upstreamed anyway, right?) then you get all the behaviour the rest of the image classes expect. if you have your own recipe then you have to maintain the integration: either ensuring the image<->bootloader glue is correct for your recipe, or ensuring your recipe matches the core u-boot recipe's behaviour | 13:56 |
| lpapp | it is not small patch in the first place | 13:57 |
| rburton | of course you can package a fork but building the code is a tiny piece of the problem | 13:57 |
| lpapp | and even if it was, the above principles would rightfully justify what I am doing | 13:57 |
| lpapp | not upstream, not right, wrong | 13:57 |
| lpapp | these are very specific vendor changes, not really useful for upstream, so it will not be upstreamed | 13:57 |
| lpapp | the image-bootloader glue has been working for five years, really | 13:58 |
| lpapp | and the fact that where I am pulling the source from should not make a different in terms of whether the image is generated or not | 13:58 |
| lpapp | surely | 13:58 |
| jofr | Sure. That's one way of doing it. Please feel free to continue to do so. :-) It was just meant as a suggestion and didn't really have anything to do with your problem. :-) | 14:00 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 14:00 | |
| *** AndersD <AndersD!~AndersD@194-237-220-218.customer.telia.com> has quit IRC | 14:02 | |
| jofr | Normally the machine definition includes those dependencies, as not all machines depend on u-boot (qemu for example). So if you make sure your machine EXTRA_IMAGEDEPENDS has a reference to your u-boot recipe, you should be good. But that means you have to build for a specific machine by defining the MACHINE variable, either in your local.conf or as an environment variable. | 14:03 |
| lpapp | all done | 14:08 |
| jofr | And your u-boot recipe inherits deploy and has deploy-steps? Then you should get your files after you bitbake your recipe - or an image for your machine. | 14:10 |
| lpapp | u-boot.inc inherits deploy | 14:14 |
| lpapp | and it has do_deploy, yes, it is basically the standard file | 14:14 |
| jofr | Do you have your own? Or are you using the one from poky? | 14:14 |
| lpapp | no and no | 14:15 |
| lpapp | I copy it from poky to my layer, I think | 14:15 |
| jofr | Ok | 14:15 |
| jofr | Side note: It might be less work if you don't duplicate the recipes, but rather create a .bbappend that overrides the SRC_URI and SRCREV with your ownþ | 14:18 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 14:18 | |
| jofr | In any case. Did you work? | 14:18 |
| jofr | s/you/it/ | 14:19 |
| *** AndersD <AndersD!~AndersD@host-90-232-144-19.mobileonline.telia.com> has joined #yocto | 14:21 | |
| lpapp | jofr: yes, we could possibly do that, maybe. | 14:21 |
| *** AndersD_ <AndersD_!~AndersD@94.234.182.90> has joined #yocto | 14:21 | |
| *** AndersD <AndersD!~AndersD@host-90-232-144-19.mobileonline.telia.com> has quit IRC | 14:22 | |
| *** AndersD_ <AndersD_!~AndersD@94.234.182.90> has quit IRC | 14:23 | |
| *** AndersD__ <AndersD__!~AndersD@host-90-232-144-19.mobileonline.telia.com> has joined #yocto | 14:24 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 14:28 | |
| *** AndersD__ <AndersD__!~AndersD@host-90-232-144-19.mobileonline.telia.com> has quit IRC | 14:28 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 14:30 | |
| zagor | what is usually the problem when recipes install files with the uid of the user running bitbake? | 14:34 |
| zagor | I get it on fairly basic stuff, like util-linux. building rocko. | 14:35 |
| *** Crofton_ <Crofton_!~Crofton@2601:5c0:c100:b84:b0ae:1370:5cc6:5864> has quit IRC | 14:42 | |
| tgoodwin | zagor: If I remember right, I see this if I'm not building under my home directory and/or not prefixing new tasks with fakeroot. But that's for things I'm modifying/creating, not existing things. | 14:50 |
| tgoodwin | zagor: so for example, if I add a new task to follow after install with more installation, I define the task: "fakeroot do_something_else() { ... }" | 14:51 |
| zagor | yeah these are all stock recipes, just my own distro and image. I'm puzzled. and it seems to happen more when I enable systemd. | 14:51 |
| tgoodwin | zagor: don't get me started on systemd ;-). Spent the better part of a week and a half just trying to get it to work in an initrd. | 14:52 |
| tgoodwin | It goes straight to the multi-user rather than switch-root target no matter what I do. | 14:53 |
| tgoodwin | (rocko) | 14:53 |
| zagor | hehe. I got it working fine after manually patching the uids, but I'm not sure I'm going to go that route anyway. | 14:53 |
| zagor | hmm, on my tiny sysvinit build I only get the uid leak on /etc/ssl/openssl.cnf. | 14:56 |
| zagor | cleaning openssl didn't help and, interestingly, didn't warn either. is that file owned by some other recipe? | 14:58 |
| zagor | can I somehow do the equivalent of "dpkg -S /etc/ssl/openssl.cnf" ? | 15:00 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:01 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 15:03 | |
| *** learningc <learningc!~learningc@210.195.56.210> has joined #yocto | 15:05 | |
| *** sstiller <sstiller!~sstiller@b2b-94-79-174-114.unitymedia.biz> has quit IRC | 15:07 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 15:10 | |
| lpapp | u-boot*.bin was generated properly after a clean build | 15:13 |
| *** yann <yann!~yann@LFbn-1-12686-123.w90-90.abo.wanadoo.fr> has joined #yocto | 15:21 | |
| yann | isn't there an easy way to set a recipe's PV from git-describe ? there's a kind of chicken-egg problem somewhere :} | 15:24 |
| JaMa | yann: not PV, but there is bbclass for setting PKGV | 15:28 |
| tgoodwin | zagor: I would love to hear how the UIDs helped with systemd initramfs. I had to patch in /etc/initramfs-release in order for systemd to acknowledge/announce in the log that it was in an initramfs. Even then, changing the link for the default target (even up in /etc/...) didn't cause it to behave according to the docs. | 15:28 |
| tgoodwin | zagor: As for the other question, have you tried oe-pkgdata-util find-path? | 15:28 |
| tgoodwin | (to look up if that file is provided by something else) | 15:28 |
| JaMa | yann: see gitpkgv.bbclass gitver.bbclass in meta-oe layer | 15:28 |
| *** matman1 <matman1!~mprokos@ANKI.bar1.SanFrancisco1.Level3.net> has joined #yocto | 15:32 | |
| yann | thx JaMa | 15:32 |
| *** tprrt <tprrt!~tprrt@217.114.201.133> has quit IRC | 15:39 | |
| *** stephano <stephano!~stephano@134.134.139.72> has joined #yocto | 15:43 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 15:45 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 15:46 | |
| *** albeus <albeus!~alberto@host195-177-dynamic.53-82-r.retail.telecomitalia.it> has joined #yocto | 15:49 | |
| albeus | Hello, I need to cross compile python2 packages using openembedded sdk. The sdk resulting package contains only python 3.5.3 (in older version it contains also python 2.7.3). Is there a way to add also this native python version to my sdk? | 15:55 |
| *** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto | 15:57 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 15:58 | |
| *** learningc <learningc!~learningc@210.195.56.210> has quit IRC | 15:58 | |
| *** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC | 15:58 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 15:58 | |
| *** learningc <learningc!~learningc@210.195.56.210> has joined #yocto | 15:59 | |
| *** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto | 15:59 | |
| *** User_ <User_!~learningc@210.195.56.210> has joined #yocto | 16:02 | |
| *** learningc <learningc!~learningc@210.195.56.210> has quit IRC | 16:04 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 16:06 | |
| *** fl0v0 <fl0v0!~fvo@mue-88-130-100-110.dsl.tropolys.de> has quit IRC | 16:07 | |
| moto-timo | can we claim Fedora-28 as a sanity tested distro for 2.6 release? | 16:20 |
| *** User_ <User_!~learningc@210.195.56.210> has quit IRC | 16:22 | |
| *** cquast <cquast!~cquast@90.85.130.193> has quit IRC | 16:24 | |
| armpit | I see we have been building on it for releases.. seems reasonable to update it | 16:26 |
| *** yann <yann!~yann@LFbn-1-12686-123.w90-90.abo.wanadoo.fr> has quit IRC | 16:29 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-ccwfivynghbnfbnm> has quit IRC | 16:36 | |
| *** xtungvu90 <xtungvu90!uid313450@gateway/web/irccloud.com/x-yhzqmlmihwyoqsdj> has joined #yocto | 16:37 | |
| *** albeus <albeus!~alberto@host195-177-dynamic.53-82-r.retail.telecomitalia.it> has quit IRC | 16:52 | |
| *** berton[m] <berton[m]!fabioberto@gateway/shell/matrix.org/x-kbrewhbbuatbcxbb> has joined #yocto | 16:53 | |
| *** lusus <lusus!~lusus@62.91.23.180> has quit IRC | 16:56 | |
| *** bb88 <bb88!605580ea@gateway/web/freenode/ip.96.85.128.234> has quit IRC | 17:01 | |
| *** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto | 17:17 | |
| *** tprrt <tprrt!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has joined #yocto | 17:18 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 17:18 | |
| *** tprrt <tprrt!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has quit IRC | 17:32 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 17:39 | |
| *** JaMa <JaMa!~martin@217.30.68.212> has quit IRC | 17:53 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 18:11 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 18:15 | |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC | 18:17 | |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto | 18:19 | |
| *** xtron <xtron!~mentor@110.93.212.98> has joined #yocto | 18:29 | |
| *** gabrbedd <gabrbedd!~beddingfi@li680-65.members.linode.com> has quit IRC | 18:30 | |
| *** gabrbedd <gabrbedd!~beddingfi@li680-65.members.linode.com> has joined #yocto | 18:32 | |
| *** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto | 18:36 | |
| xtron | moved DL_DIR to a directory contains already downloaded packages, but I can't fetch some repos, "cleansstate or cleanall" doesn't work either, moving back or creating a fresh DL_DIR works fine, anybody have idea? | 18:41 |
| *** xtungvu90 <xtungvu90!uid313450@gateway/web/irccloud.com/x-yhzqmlmihwyoqsdj> has quit IRC | 18:47 | |
| rburton | xtron: bit hard to help with just "can't fetch". what's the actual error? | 18:53 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 18:53 | |
| *** morphis <morphis!~morphis@pD9E2FD78.dip0.t-ipconnect.de> has quit IRC | 18:57 | |
| xtron | rburton: do_fetch fails, "can't fetch from any source" https://pastebin.com/MWmvyjhC | 19:03 |
| *** yann <yann!~yann@LFbn-1-515-227.w86-245.abo.wanadoo.fr> has joined #yocto | 19:09 | |
| *** Crofton_ <Crofton_!~Crofton@206.121.56.38> has joined #yocto | 19:11 | |
| rburton | fatal: remote origin already exists. | 19:14 |
| rburton | bug in the fetcher | 19:14 |
| rburton | go and delete the linux-mel.git folder from downloads/ | 19:15 |
| rburton | presumably the fetcher crashed and left the dldir in a bad state | 19:15 |
| rburton | filing a bug with that log would be useful | 19:15 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:27 | |
| xtron | rburton: even that didn't help, error is persistent with these changes, | 19:56 |
| rburton | xtron: you probab;y failed to delete the right folder. did you look in DL_DIR/git2/? | 19:57 |
| xtron | rburton: yes it delete the relevant remote there too, | 19:58 |
| xtron | rburton: finally working, there was a directory left, in git2/<git.remote>, thanks | 20:03 |
| rburton | a bug would be useful, it shouldn't be so fragile obviously | 20:05 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 20:22 | |
| *** stephano <stephano!~stephano@134.134.139.72> has quit IRC | 20:46 | |
| *** simple_crafter <simple_crafter!~kjivan@50.234.203.130> has joined #yocto | 20:57 | |
| *** anubani <anubani!~quassel@ISA.asaltech.com> has quit IRC | 20:58 | |
| *** anubani <anubani!~quassel@ISA.asaltech.com> has joined #yocto | 20:59 | |
| *** Crofton_ <Crofton_!~Crofton@206.121.56.38> has quit IRC | 21:07 | |
| *** simple_crafter <simple_crafter!~kjivan@50.234.203.130> has quit IRC | 21:11 | |
| *** marka <marka!~masselst@184.175.21.100> has quit IRC | 21:12 | |
| *** pohly <pohly!~pohly@p54BD55A3.dip0.t-ipconnect.de> has quit IRC | 21:16 | |
| tlwoerner | using the esdk, is there a convenient way to create+add a layer? (a la "bitbake-layers create-layer ..." "bitbake-layers add-layer ...") | 21:29 |
| *** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has quit IRC | 21:34 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 22:05 | |
| *** geissonator <geissonator!~geissonat@cpe-24-198-214-139.maine.res.rr.com> has quit IRC | 22:12 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 22:17 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 22:23 | |
| alimon | RP: i'm playing with the new AB, what is the right way to set SSTATE_DIR, i tried to modify ~/yocto-autobuilder-helper/config.json but looks like the worker is cloning the upstream git repo | 22:25 |
| jdel | has anyone here used the se-linux layer? The wrappers it creates for busybox break login shell activation | 22:27 |
| jdel | specifically something like exec("/bin/sh", "-sh") is supposed to be equivalent to exec("/bin/sh", "sh", "-l") | 22:28 |
| jdel | and typically busybox installs as soft-links to the /bin/busybox executable | 22:28 |
| jdel | eg /bin/sh -> /bin/busybox | 22:28 |
| jdel | but se-linux has a bbappend for busybox which replaces those links with links to shell script wrappers | 22:28 |
| jdel | so arg[0] doesn't make it to the invocation of busybox properly | 22:29 |
| armpit | alimon, where every you want | 22:30 |
| armpit | somewhere common if you have more than one worker | 22:30 |
| alimon | armpit: yes i modifed to set a home folder atm | 22:34 |
| alimon | i have the worker and controller in the same machine so np | 22:34 |
| *** geissonator <geissonator!~geissonat@cpe-24-198-214-139.maine.res.rr.com> has joined #yocto | 22:44 | |
| *** peniwize <peniwize!~peniwize@63.140.26.14> has joined #yocto | 22:57 | |
| peniwize | I'm building a poky based OS image that targets a standard PC and uses the meta-intel layer. I used devtool to create a Linux kernel patch, which added recipes-kernel/linux/linux-intel_4.14.bbappend to my layer, however it appears that the Linux kernel patch is not being applied when I clean and rebuild my primary recipe or when I explicitly rebuild "linux-intel". What might I be doing wrong? | 23:01 |
| peniwize | Never mind. It seems that I had to manually delete "tmp/work-shared/intel-corei7-64/kernel-*". Apparently bitbake -c cleanall linux-intel didn't delete everything. | 23:13 |
| *** Cbast <Cbast!~sfrigon@107.190.38.187> has joined #yocto | 23:26 | |
| *** geissonator <geissonator!~geissonat@cpe-24-198-214-139.maine.res.rr.com> has quit IRC | 23:33 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 23:36 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 23:39 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has joined #yocto | 23:43 | |
| *** NU-Slacker <NU-Slacker!~NU-Slacke@24.13.72.71> has quit IRC | 23:45 | |
| *** oorezz <oorezz!~zzeroo@p50999e88.dip0.t-ipconnect.de> has joined #yocto | 23:53 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!