Monday, 2018-10-15

*** lfa <lfa!> has quit IRC00:15
*** lfa <lfa!> has joined #yocto00:15
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto00:44
*** nighty- <nighty-!> has joined #yocto00:46
*** learningc <learningc!> has joined #yocto01:05
*** Willy-- <Willy--!~william@> has quit IRC01:29
*** Cbast <Cbast!~sfrigon@> has quit IRC01:37
*** jesseg <jesseg!~jesseg@> has left #yocto01:37
*** Cbast <Cbast!~sfrigon@> has joined #yocto01:37
*** Cbast <Cbast!~sfrigon@> has quit IRC01:55
*** Cbast <Cbast!~sfrigon@> has joined #yocto01:58
*** dv_ <dv_!> has quit IRC02:16
*** kaspter <kaspter!~Instantbi@> has quit IRC02:23
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:25
*** dv_ <dv_!~dv@> has joined #yocto02:29
*** Cbast <Cbast!~sfrigon@> has quit IRC02:40
*** rubdos <rubdos!> has quit IRC02:53
*** rubdos <rubdos!> has joined #yocto03:35
*** lfa <lfa!> has quit IRC04:16
*** lfa <lfa!> has joined #yocto04:16
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto04:20
*** User__ <User__!> has joined #yocto04:26
*** learningc <learningc!> has quit IRC04:28
*** lpotter <lpotter!~quassel@2001:8003:e172:cb00:ba27:ebff:febb:59b> has joined #yocto04:35
*** learningc <learningc!> has joined #yocto04:38
*** User__ <User__!> has quit IRC04:40
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC04:55
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto04:55
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC04:58
*** User__ <User__!> has joined #yocto05:05
*** User__ <User__!> has quit IRC05:07
*** User__ <User__!> has joined #yocto05:08
*** learningc <learningc!> has quit IRC05:09
*** AndersD <AndersD!> has joined #yocto05:11
*** OnkelUlla <OnkelUlla!> has joined #yocto05:12
*** AndersD <AndersD!> has quit IRC05:19
*** AndersD <AndersD!> has joined #yocto05:20
*** pohly <pohly!> has joined #yocto05:39
*** agust <agust!> has joined #yocto05:42
*** lpotter <lpotter!~quassel@2001:8003:e172:cb00:ba27:ebff:febb:59b> has joined #yocto06:12
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto06:15
*** anujm <anujm!anujm@nat/intel/x-zdummmybfwjferme> has joined #yocto06:24
*** Bunio_FH <Bunio_FH!> has joined #yocto06:24
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC06:28
*** lfa <lfa!> has quit IRC06:31
*** morphis <morphis!> has joined #yocto06:48
*** lfa <lfa!~lfa@> has joined #yocto07:00
*** tprrt <tprrt!~tprrt@> has joined #yocto07:08
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC07:10
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto07:11
*** fl0v0 <fl0v0!> has joined #yocto07:14
LetoThe2ndRP: i can confirm that.07:19
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto07:23
*** zagor <zagor!~zagor@rockbox/developer/Zagor> has joined #yocto07:38
*** Jay7 <Jay7!~quassel@> has joined #yocto07:45
*** TobSnyder <TobSnyder!> has joined #yocto07:51
*** ak77 <ak77!c12e4b03@gateway/web/freenode/ip.> has joined #yocto07:52
*** sstiller <sstiller!> has joined #yocto07:52
ak77Hello! what should I clean after adding `inherit allarch` ? image making (do_rootfs) still wants arch specific ipk altough -all.ipk has been created07:53
ak77I did image-name -c cleanall but that's not it08:00
*** User__ <User__!> has quit IRC08:23
*** User__ <User__!> has joined #yocto08:24
*** micka <micka!> has quit IRC08:25
*** User__ <User__!> has joined #yocto08:25
*** User__ <User__!> has quit IRC08:26
*** User__ <User__!> has joined #yocto08:26
*** micka <micka!> has joined #yocto08:28
*** frsc_ <frsc_!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto08:31
*** frsc_ <frsc_!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC08:31
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:32
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC08:32
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:36
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:39
*** anujm <anujm!anujm@nat/intel/x-zdummmybfwjferme> has quit IRC08:41
*** lusus <lusus!~lusus@> has joined #yocto08:47
ak77ak77: false alarm, i had two inherit lines.. it works with single one08:53
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto08:53
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:56
*** AndersD_ <AndersD_!~AndersD@> has joined #yocto09:05
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:07
*** AndersD <AndersD!> has quit IRC09:08
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC09:19
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto09:34
*** Jay7 <Jay7!~quassel@> has quit IRC09:40
*** mrpelotazo <mrpelotazo!> has quit IRC09:43
*** mrpelotazo <mrpelotazo!> has joined #yocto09:49
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:51
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:56
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:58
*** learningc <learningc!> has joined #yocto09:59
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto10:02
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:06
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto10:09
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto10:10
*** mrpelotazo <mrpelotazo!> has quit IRC10:11
*** mrpelotazo <mrpelotazo!> has joined #yocto10:12
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto10:17
*** ejoerns <ejoerns!~ejo@2001:67c:670:100:76d4:35ff:fee8:98b3> has joined #yocto10:18
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC10:25
learningcWhat can I do with rpm files?10:25
LetoThe2ndlearningc: Revolute them Per Minute.10:27
learningcOk, what else?10:28
LetoThe2ndlearningc: possibly also use them as the defined format for the RedhatPackageManager10:28
jofrlearningc: 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
learningcAh I see. Thanks jofr. (sorry I'm new to what package was in yocto, but now I know)10:33
jofrRPM is just one package format out of many. And Yocto can generate a few different formats.10:34
learningcHow do I install a package?10:34
learningc"I have rpm format currently"10:34
learningcIs there a command to issue like "apt install" as in ubuntu?10:35
LetoThe2ndlearningc: manually installing packages should totally be the last resort. just use IMAGE_INSTALL, and have everything done automatically.10:35
jofrYes. 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
learningcLetoThe2nd, But with IMAGE_INSTALL, the package will be in my rootfs?10:36
LetoThe2ndlearningc: 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 manager10:37
learningcThe 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
jofrlearningc: But I think perhaps you should take a step back, and explain what it is you're trying to do.10:38
LetoThe2ndlearningc: better walk through the changes and document them.10:38
LetoThe2nde.g. make proper recipes.10:38
learningcYa, 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
LetoThe2ndlearningc: 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
learningcHow do I verify if I have a package management enabled on my board?10:41
jofrTry to write: rpm10:41
jofr"rpm" is the tool for....10:42
jofrit's THE rpm..10:42
learningcI typed in rpm, but nothing happens10:42
LetoThe2ndsee, no package management. also known as, the default situation.10:42
learningcBut I did not get any "command not found"10:42
learningcrpm: --hash (-h) may only be specified during package installation  <- I get this when I type rpm -h10:43
learningcSo it's there?10:43
LetoThe2ndlucky you, it is enabled then.10:43
learningcBut how do I install a package with it?10:44
jofrThen refer to the documentation and see if you can install some packages.  :-)
LetoThe2ndyou build the package, copy it over, then install it.10:44
learningcAny quick command snippet to install foo.rpm?10:45
LetoThe2ndit does not work like that.10:45
LetoThe2ndthere is no upstream repository server from which you could get all that stuff automatically.10:45
learningcI see.10:45
jofrlearningc: 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
learningcjofr, I'm trying to install manually my own package I built previously, to add it into the current rootfs10:47
learningcI have copied my rpm file onto my board already10:47
jofrOn 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
learningcjofr, rootfs on a running system10:48
jofrSo if you're just trying to install an RPM onto a single board, then you do (as the manual says) rpm -i packagename.rpm10:48
jofrBut 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
learningcOk, 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
jofrI have no idea. Haven't used rpm for more than a decade.10:51
jofrMy guess is that if it didn't report any errors, it worked.10:52
jofrThink 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
learningchmm, looks like it works, but I'm not sure10:53
learningcwhen I do rpm -i mpackage.rpm a second time, it reports my package is already installed10:54
jofrIs the stuff you meant to install there?10:54
jofrNormally, 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
learningcYep, looks like it's all there. I guess it's a success :) Thanks jofr10:58
*** tgoodwin <tgoodwin!> has joined #yocto10:58
learningcIn my case, I only need to add in a new application10:59
*** jofr <jofr!~jofr@> has left #yocto11:00
*** jofr <jofr!~jofr@> has joined #yocto11:00
jofrlearningc: 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@> has joined #yocto11:03
*** learningc <learningc!> has quit IRC11:07
*** csanchezdll <csanchezdll!> has joined #yocto11:09
*** cquast <cquast!~cquast@> has joined #yocto11:10
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto11:19
yoctiNew news from stackoverflow: How to setup SPI Driver for Yocto <>11:28
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC11:35
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC11:43
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto11:46
*** Crofton <Crofton!> has quit IRC11:49
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto11:53
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC11:57
*** Crofton <Crofton!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto11:58
*** AndersD_ <AndersD_!~AndersD@> has quit IRC12:02
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:04
*** AndersD <AndersD!> has joined #yocto12:05
tgoodwinHas anyone run into an issue where CMake 'find_program' cannot locate a -native package (like sed)?12:08
LetoThe2ndtgoodwin: most trivial reason would be that you do not explicitly DEPEND on it, and therefore it does not show up in the recipe specific sysroot12:11
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto12:17
*** geissonator <geissonator!> has joined #yocto12:22
*** no_such_user <no_such_user!> has joined #yocto12:27
no_such_userEllo... 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_userSSHD (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
LetoThe2ndno_such_user: only thing that comes to mind is OOM kicking in12:36
no_such_userLetoThe2nd: I don't see the OOM Killer logging anything in syslog...12:37
LetoThe2ndno_such_user: ok12:38
no_such_userfirst thing in syslog is :12:38
no_such_userorg.a11y.atspi.Registry[2904]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"12:38
no_such_userorg.a11y.atspi.Registry[2904]:       after 16853 requests (16853 known processed) with 0 events remaining.12:38
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC12:43
*** zeddii <zeddii!~bruce@> has joined #yocto12:43
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC12:45
*** vmeson <vmeson!> has joined #yocto12:46
*** rburton <rburton!> has joined #yocto12:47
*** marka <marka!~masselst@> has joined #yocto12:54
tgoodwinLetoThe2nd: 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
tgoodwinLetoThe2nd: 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 #yocto13:01
lpapphi, I type bitbake u-boot, but the binary is not getting generated, why is that?13:02
lpappI was expecting it appearing in tmp/deploy/images/$foo13:02
*** sagner <sagner!~ags@> has quit IRC13:03
rburtonimages is for images, u-boot doesn't build an image but packages13:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto13:04
tgoodwinlpapp: 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
lpappis this true13:05
lpappI used to have u-boot*.bin generated there long time ago... have any recent yocto releases changed this operation13:06
tgoodwinIt's likely off in your work directory.13:06
lpappu-boot is definitely not a package13:06
lpappyou flash the binary over tftp, or whatever13:06
tgoodwinOnce you bitbake an image recipe, it'll get staged to your image.13:06
lpappserial flasher, etc13:07
lpappit has nothing to do with ipk or any kind of packages13:07
lpappu-boot is a bootloader13:07
lpappit has no concept of package at that low level at all13:07
lpappfor a package, you need to have an OS that understand packages, but a bootloader comes before any such OS13:08
*** ntl <ntl!> has joined #yocto13:11
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC13: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. PN13:12
tgoodwinSo in that definition, U-boot is a package.13:12
lpappI do not follow13:12
lpappI used to get the u-boot binary in the aforementioned location after building the image13:12
tgoodwinCorrect, _after_ building an image.13:13
lpappwhy am I not getting it now? Has this logic changed with any recent Yocto release?13:13
tgoodwinYou stated you were running "bitbake u-boot" -- u-boot is not an image definition.13:13
lpappI have built an image13:13
lpappI have also built foo-core-image13:13
lpappwhich builds my rootfs13:13
tgoodwinIs your MACHINE set?  Does your machine have IMAGE_BOOT_FILES set with u-boot.bin?
lpapphas this logic changed recently13:14
lpapprecently, as in last five years13:14
lpappwe were stuck with daisy before now going to m...13:14
LetoThe2ndlpapp: it changed in k or m, as people tended to abuse/misinterpret the deploy dir :-)13:15
LetoThe2ndit got bitten by it too, but hey. another thing learnt13:16
lpappok, so let me check that machine thing13:16
lpappMACHINE is not set13:17
lpappMACHINE_ARCH is13:17
tgoodwinChances 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
lpappoutput of bitbake -e foo-core-image | grep ^MACHINE:
LetoThe2ndheh yeah, it was DEPLOY_DIR versus IMGDEPLOYDIR13:18
lpappsorry, MACHINE is set via ./conf/local.conf.sample13:20
lpappMACHINE ?= ...13:20
lpappbut bitbake -e would not see it?13:20
tgoodwinThat would only set it if it was the template for your actual build/conf/local.conf13:21
lpappyes, it is13:21
lpappmy build/conf/local.conf gets that13:21
lpappbitbake -e foo-core-image | grep ^IMAGE_BOOT_FILES -> returns empty13:23
lpappis that the issue13:23
lpappI actually do not believe that u-boot is a boot file for the image13:24
lpappit sounds more like uImage or zImage, etc, that would be a boot file for the image to be honest13:25
lpappI am very very confused why u-boot*.bin is not getting generated as it used to13:25
lpappplease help13:25
*** morphis <morphis!> has quit IRC13:25
tgoodwinWell 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 partition13:26
tgoodwinThe 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
lpappyes, I have u-boot13:26
lpappEXTRA_IMAGEDEPENDS += "u-boot"13:27
lpappso what is the problem, why is the bootloader image not getting generated?13:27
lpappI get this WARNING: /home/lpapp/Projects/polatis/nicbuild/poky/../meta-polatis/recipes-bsp/u-boot/ is tainted from a forced run13:28
lpappI wonder whether that could be a contributing factor for it not getting generated13:28
lpappand if so, how could I avoid that, clean build only?13:29
tgoodwinWell, if you ran bitbake with the force flag, you'll get that.13:29
lpappyes, but is that the reason for this not getting generated in the right place?13:30
tgoodwinAs 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
lpappnot tarball, I used to get a .bin file13:30
lpappI do get the rootfs image there, but not the bootloader image13:31
lpappwhat is going on13:31
tgoodwinThe 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
lpappok, 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
lpappI guess I will have to try a brand new clean build if no idea...13:34
lpappin which case I will only see the result in about an hour13:35
tgoodwinThe u-boot.bin should get pulled into the image directory as long as the machine depends on it.13:35
tgoodwinYou'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
lpappMACHINE ?= is in my ./build/conf/local.conf13:37
lpappso why would it not be defined13:37
tgoodwinIf 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!> has joined #yocto13:38
lpappok, so what is the next step to do?13:39
tgoodwinIt 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
tgoodwinre 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
tgoodwinIf your'e not using a standard machine, maybe compare notes against an existing one from meta-intel or meta-yocto-bsp?13:44
lpappnot sure standard u-boot, as we need to adopt it for our own board13:44
lpappbut it is two patches off of 2017.01, I believe13:44
lpappbut it used to work ok13:44
tgoodwin"standard" I mean one of the recipes-bsp/u-boot/u-boot_???.bb recipe from meta, for example.13:46
lpappoh, no, nah13:46
lpappwe have to grab it from our source url, etc.13:46
*** no_such_user <no_such_user!> has quit IRC13:47
jofrlpapp: 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
jofrs/image depend on u-boot/machine depend on u-boot/13:52
lpappno, we do not want to use .bbappend for patches as that is a mess13:52
lpappwhen 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
jofrI'm arguing that what you're doing is an even bigger mess. But that's fine.  :-)  Just my opinion.  :-)13:53
lpappthere is not much painful about a dedicated topic branch for our board at all13:53
lpappwhat would be painful about it really?13:53
jofrOk  :)13:53
lpappIf anything, it is less painful because I can check out master or any release branches right away there easily13:54
lpappI can merge changed from master and release branches to my board branch, etc.13:54
lpappmy development workflow should not depend on a specific arm buildsystem workflow13:54
lpappmy buildsystem workflow for a particular board ought to depend on my development workflow13:55
lpappbuildsystem is subordinate or downstream to the actual source, which is considered upstream13:55
lpappalso, if we switch away from Yocto, the thing should still contain everything we need, so the extra stuff is not Yocto specific13:55
rburtonlpapp: 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 behaviour13:56
lpappit is not small patch in the first place13:57
rburtonof course you can package a fork but building the code is a tiny piece of the problem13:57
lpappand even if it was, the above principles would rightfully justify what I am doing13:57
lpappnot upstream, not right, wrong13:57
lpappthese are very specific vendor changes, not really useful for upstream, so it will not be upstreamed13:57
lpappthe image-bootloader glue has been working for five years, really13:58
lpappand the fact that where I am pulling the source from should not make a different in terms of whether the image is generated or not13:58
jofrSure. 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!> has joined #yocto14:00
*** AndersD <AndersD!> has quit IRC14:02
jofrNormally 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
lpappall done14:08
jofrAnd 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 inherits deploy14:14
lpappand it has do_deploy, yes, it is basically the standard file14:14
jofrDo you have your own? Or are you using the one from poky?14:14
lpappno and no14:15
lpappI copy it from poky to my layer, I think14:15
jofrSide 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 IRC14:18
jofrIn any case. Did you work?14:18
*** AndersD <AndersD!> has joined #yocto14:21
lpappjofr: yes, we could possibly do that, maybe.14:21
*** AndersD_ <AndersD_!~AndersD@> has joined #yocto14:21
*** AndersD <AndersD!> has quit IRC14:22
*** AndersD_ <AndersD_!~AndersD@> has quit IRC14:23
*** AndersD__ <AndersD__!> has joined #yocto14:24
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto14:28
*** AndersD__ <AndersD__!> has quit IRC14:28
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC14:30
zagorwhat is usually the problem when recipes install files with the uid of the user running bitbake?14:34
zagorI 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 IRC14:42
tgoodwinzagor: 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
tgoodwinzagor: 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
zagoryeah 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
tgoodwinzagor: 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
tgoodwinIt goes straight to the multi-user rather than switch-root target no matter what I do.14:53
zagorhehe. 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
zagorhmm, on my tiny sysvinit build I only get the uid leak on /etc/ssl/openssl.cnf.14:56
zagorcleaning openssl didn't help and, interestingly, didn't warn either. is that file owned by some other recipe?14:58
zagorcan I somehow do the equivalent of "dpkg -S /etc/ssl/openssl.cnf" ?15:00
*** TobSnyder <TobSnyder!> has quit IRC15:01
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto15:03
*** learningc <learningc!~learningc@> has joined #yocto15:05
*** sstiller <sstiller!> has quit IRC15:07
*** Bunio_FH <Bunio_FH!> has quit IRC15:10
lpappu-boot*.bin was generated properly after a clean build15:13
*** yann <yann!> has joined #yocto15:21
yannisn'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
JaMayann: not PV, but there is bbclass for setting PKGV15:28
tgoodwinzagor: 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
tgoodwinzagor: 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
JaMayann: see gitpkgv.bbclass            gitver.bbclass in meta-oe layer15:28
*** matman1 <matman1!> has joined #yocto15:32
yannthx JaMa15:32
*** tprrt <tprrt!~tprrt@> has quit IRC15:39
*** stephano <stephano!~stephano@> has joined #yocto15:43
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto15:45
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC15:46
*** albeus <albeus!> has joined #yocto15:49
albeusHello, 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 #yocto15:57
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:58
*** learningc <learningc!~learningc@> has quit IRC15:58
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC15:58
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC15:58
*** learningc <learningc!~learningc@> has joined #yocto15:59
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto15:59
*** User_ <User_!~learningc@> has joined #yocto16:02
*** learningc <learningc!~learningc@> has quit IRC16:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto16:06
*** fl0v0 <fl0v0!> has quit IRC16:07
moto-timocan we claim Fedora-28 as a sanity tested distro for 2.6 release?16:20
*** User_ <User_!~learningc@> has quit IRC16:22
*** cquast <cquast!~cquast@> has quit IRC16:24
armpitI see we have been building on it for releases.. seems reasonable to update it16:26
*** yann <yann!> has quit IRC16:29
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC16:36
*** xtungvu90 <xtungvu90!uid313450@gateway/web/> has joined #yocto16:37
*** albeus <albeus!> has quit IRC16:52
*** berton[m] <berton[m]!fabioberto@gateway/shell/> has joined #yocto16:53
*** lusus <lusus!~lusus@> has quit IRC16:56
*** bb88 <bb88!605580ea@gateway/web/freenode/ip.> has quit IRC17:01
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto17:17
*** tprrt <tprrt!> has joined #yocto17:18
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto17:18
*** tprrt <tprrt!> has quit IRC17:32
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:39
*** JaMa <JaMa!~martin@> has quit IRC17:53
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC18:11
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto18:15
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC18:17
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto18:19
*** xtron <xtron!~mentor@> has joined #yocto18:29
*** gabrbedd <gabrbedd!> has quit IRC18:30
*** gabrbedd <gabrbedd!> has joined #yocto18:32
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto18:36
xtronmoved 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/> has quit IRC18:47
rburtonxtron: bit hard to help with just "can't fetch".  what's the actual error?18:53
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto18:53
*** morphis <morphis!> has quit IRC18:57
xtronrburton: do_fetch fails, "can't fetch from any source"
*** yann <yann!> has joined #yocto19:09
*** Crofton_ <Crofton_!~Crofton@> has joined #yocto19:11
rburtonfatal: remote origin already exists.19:14
rburtonbug in the fetcher19:14
rburtongo and delete the linux-mel.git folder from downloads/19:15
rburtonpresumably the fetcher crashed and left the dldir in a bad state19:15
rburtonfiling a bug with that log would be useful19:15
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:27
xtronrburton: even that didn't help, error is persistent with these changes,19:56
rburtonxtron: you probab;y failed to delete the right folder. did you look in DL_DIR/git2/?19:57
xtronrburton: yes it delete the relevant remote there too,19:58
xtronrburton: finally working, there was a directory left, in git2/<git.remote>, thanks20:03
rburtona bug would be useful, it shouldn't be so fragile obviously20:05
*** WillMiles <WillMiles!> has quit IRC20:22
*** stephano <stephano!~stephano@> has quit IRC20:46
*** simple_crafter <simple_crafter!~kjivan@> has joined #yocto20:57
*** anubani <anubani!> has quit IRC20:58
*** anubani <anubani!> has joined #yocto20:59
*** Crofton_ <Crofton_!~Crofton@> has quit IRC21:07
*** simple_crafter <simple_crafter!~kjivan@> has quit IRC21:11
*** marka <marka!~masselst@> has quit IRC21:12
*** pohly <pohly!> has quit IRC21:16
tlwoernerusing 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 IRC21:34
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC22:05
*** geissonator <geissonator!> has quit IRC22:12
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto22:17
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:23
alimonRP: 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 repo22:25
jdelhas anyone here used the se-linux layer?  The wrappers it creates for busybox break login shell activation22:27
jdelspecifically something like exec("/bin/sh", "-sh") is supposed to be equivalent to exec("/bin/sh", "sh", "-l")22:28
jdeland typically busybox installs as soft-links to the /bin/busybox executable22:28
jdeleg /bin/sh -> /bin/busybox22:28
jdelbut se-linux has a bbappend for busybox which replaces those links with links to shell script wrappers22:28
jdelso arg[0] doesn't make it to the invocation of busybox properly22:29
armpitalimon, where every you want22:30
armpitsomewhere common if you have more than one worker22:30
alimonarmpit: yes i modifed to set a home folder atm22:34
alimoni have the worker and controller in the same machine so np22:34
*** geissonator <geissonator!> has joined #yocto22:44
*** peniwize <peniwize!~peniwize@> has joined #yocto22:57
peniwizeI'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
peniwizeNever 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@> has joined #yocto23:26
*** geissonator <geissonator!> has quit IRC23:33
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto23:36
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC23:39
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto23:43
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC23:45
*** oorezz <oorezz!> has joined #yocto23:53

Generated by 2.11.0 by Marius Gedminas - find it at!