Friday, 2018-11-16

*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto00:12
*** comptroller <comptroller!> has quit IRC00:18
*** comptroller <comptroller!> has joined #yocto00:26
*** pn <pn!~parthi@> has joined #yocto00:43
*** pn <pn!~parthi@> has quit IRC00:45
*** pn <pn!~parthi@> has joined #yocto00:46
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:50
*** learningc <learningc!> has joined #yocto01:16
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto01:26
*** JaMa <JaMa!~martin@> has joined #yocto01:29
*** nathani_ <nathani_!> has joined #yocto01:51
*** nathani__ <nathani__!> has quit IRC01:55
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC02:01
*** sgw1 <sgw1!~sgw@> has joined #yocto02:02
*** sgw <sgw!~sgw@> has quit IRC02:04
*** dreyna <dreyna!> has joined #yocto02:28
*** tgraydon <tgraydon!textual@nat/intel/x-nqzpnpnlrseigrlw> has quit IRC03:14
*** hamis <hamis!~irfan@> has joined #yocto03:18
*** comptroller <comptroller!> has quit IRC03:40
*** comptroller <comptroller!> has joined #yocto03:43
*** thaytan <thaytan!> has quit IRC03:48
*** dreyna <dreyna!> has quit IRC03:49
yoctiNew news from stackoverflow: how to simplify recipe-sysroot-native <>03:57
*** nathani__ <nathani__!> has joined #yocto04:45
*** nathani_ <nathani_!> has quit IRC04:47
*** armpit <armpit!~armpit@2601:202:4180:c33:7db3:34a2:3c95:1c57> has quit IRC05:57
*** armpit <armpit!~armpit@2601:202:4180:c33:f00c:90a9:e13c:6a53> has joined #yocto06:09
*** dreyna <dreyna!> has joined #yocto06:22
*** lfa <lfa!> has joined #yocto06:30
*** dmoseley <dmoseley!> has quit IRC06:40
*** dmoseley <dmoseley!> has joined #yocto06:42
*** dmoseley <dmoseley!> has quit IRC06:46
*** nathani__ <nathani__!> has quit IRC06:46
*** nathani__ <nathani__!> has joined #yocto06:47
*** dmoseley <dmoseley!> has joined #yocto06:50
*** sgw1 <sgw1!~sgw@> has quit IRC06:52
*** sgw <sgw!~sgw@> has joined #yocto06:55
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC07:02
*** mihais <mihais!~mihaiserb@> has joined #yocto07:12
*** Bunio_FH <Bunio_FH!> has joined #yocto07:17
*** dreyna <dreyna!> has quit IRC07:17
*** fatalhalt <fatalhalt!> has quit IRC07:19
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:23
*** sagner <sagner!~ags@2a02:169:3460::b6a> has quit IRC07:28
yoctiNew news from stackoverflow: CUPS web interface on YOCTO <>07:28
*** wooosaiiii <wooosaiiii!> has joined #yocto07:28
*** lusus <lusus!~lusus@> has joined #yocto07:32
*** varjag <varjag!> has joined #yocto07:39
*** TobSnyder <TobSnyder!~schneider@> has joined #yocto07:39
*** moemoe <moemoe!> has joined #yocto07:46
*** Bunio_FH <Bunio_FH!> has quit IRC07:49
*** Bunio_FH <Bunio_FH!> has joined #yocto07:50
*** fatalhalt <fatalhalt!> has joined #yocto07:50
moemoeHey, I'm trying to build my first yocto for raspberry pi, but getting problems with automake all the time: ERROR: Task (virtual:native:/home/mo/src/poky-sumo/meta/recipes-devtools/autoconf/ failed with exit code '1'07:50
moemoeconsole output is at, logfile at
moemoeautoconf on the host-system (debian stable) is installed as well: mo@rrpc0019:~/src/yocto-rpi/build$ autoconf --version07:52
moemoeautoconf (GNU Autoconf) 2.6907:52
moemoeany hints where to dig further?07:52
*** ak77 <ak77!c12e4b03@gateway/web/freenode/ip.> has quit IRC07:54
*** sagner <sagner!~ags@> has joined #yocto07:58
*** jostor <jostor!55a495f3@gateway/web/freenode/ip.> has joined #yocto08:01
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto08:05
eduardas_mhello, so Thud was released yesterday, but I see that thud-next branch is lagging behind the thud branch... I was kinda expecting it to be the other way around... can someone explain the difference and purposes of the two branches?08:08
eduardas_mthe yocto-2.6 tag is actually the latest one on the thud-next branch08:11
LetoThe2ndmoemoe: well its not about the autoconf on your host, ot is trying to build its own one. but it rings a bell, with the m4 message.08:16
jostorHi, I am trying to build zeromq.js for raspberrypi3. My recipe is found here:
jostorThe build fails with "configure: error: cannot run C compiled programs. | If you meant to cross compile, use `--host'."08:16
jostorSee complete log here:
jostorDoes anyone know how to solve this?08:17
LetoThe2ndmoemoe: actually no, sorry, i misremembered it08:19
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto08:21
*** prabhakarlad <prabhakarlad!~prabhakar@> has left #yocto08:21
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto08:21
LetoThe2ndjostor: find the already existing solutions as inspiration here:
*** jkliemann <jkliemann!~jk@> has joined #yocto08:23
LetoThe2ndjostor: and as you are basically trying to build the node bindings it seems, it obviously needs zeromq itself to be ready first. so you need to set a DEPENDS on it.08:24
jkliemannhi, is there any layer that provides libperl5.14 for yocto? perl itself is available but it doesn't have any modules available (and at least on Debian those are part of libperl)08:24
*** prabhakarlad <prabhakarlad!~prabhakar@> has quit IRC08:26
LetoThe2ndjkliemann: suggests that its there, and the package is called perl-lib08:27
moemoeLetoThe2nd: hm. thanks anyway. the strange thing is that autoconf and automake both have problems, with similar errors: "configure: error: The installed version of autoconf does not work" and "autom4te: need GNU m4 1.4 or later: m4", so at first it looks like there is some problem with my local tools.08:28
*** gunnarx <gunnarx!~gunnarx@unaffiliated/gan> has joined #yocto08:28
LetoThe2ndmoemoe: i'm not totally convinced there. you do have the prerequisites as mentioned in the quick start guide installed?08:29
jostorLetoThe2nd: Thanks! I have added DEPENDS += "zeromq" to my recipe, but I am still getting errors:
jkliemannLetoThe2nd: thanks, perl-lib was the information I needed08:35
*** pn <pn!~parthi@> has quit IRC08:36
moemoeLetoThe2nd: I installed the packages mentioned in
LetoThe2ndjostor: this might be related to non-crosscompile-issues in the node bindings, but i don't have the possibilities to dig into this at the moment. my suggestion would be to put it on the ML, and/or wait a couple of hours until the USians are wake.08:37
LetoThe2ndmoemoe: the essentials part, right?08:38
moemoeLetoThe2nd: right08:39
jostorLetoThe2nd: Ok, Thanks, I will do that08:40
LetoThe2ndmoemoe: ok, fine. and this is an otherwise completely untinkered debian as a build host? which poky revision plus layers are you using?08:41
jkliemannLetoThe2nd: it seems the perl standard lib is still not available (or complete), in my case I need File/ which isn't available under /usr/lib/perl08:41
LetoThe2ndjkliemann: you'll have to read the perl recipe then and find out if what you are missing is disbaled, or packaged otherwise, or...08:42
*** tristanram <tristanram!3e029902@gateway/web/freenode/ip.> has quit IRC08:42
*** tristanram <tristanram!3e029902@gateway/web/freenode/ip.> has joined #yocto08:43
moemoeLetoThe2nd: It's a host I use for development, but all packages installed should be plain debian stable. I'm using sumo, overlays are and the ones listed as dependencies below.08:44
LetoThe2ndmoemoe: could you give it a try in the vanilla rpi situation? e.g. poky + meta-openembedded + meta-raspberrypi, and from meta-openembedded you only need oe, python, networking, multimedia08:46
LetoThe2ndmoemoe: as documented here:
LetoThe2nd(feel free to read it as: i'm not convinced that the security and jumptek layers are ok)08:47
LetoThe2ndand the state i linked is pretty much known good, just built it myself a couple of days back.08:47
*** nathani_ <nathani_!> has joined #yocto08:47
moemoeLetoThe2nd: WIll do08:51
*** nathani__ <nathani__!> has quit IRC08:51
*** frsc <frsc!> has joined #yocto08:53
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto08:54
*** hamis <hamis!~irfan@> has quit IRC09:01
*** grma <grma!~gruberm@> has joined #yocto09:03
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC09:04
*** OpenSorceress <OpenSorceress!> has joined #yocto09:04
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto09:04
*** anujm <anujm!~anujm@> has joined #yocto09:07
*** mckoan|away is now known as mckoan09:15
*** ant_work <ant_work!~ant__@> has joined #yocto09:24
*** rburton <rburton!> has joined #yocto09:24
moemoeLetoThe2nd: Still the same problem:
moemoethe config is
jofrAnyone here experienced a bitbake devshell under tmux not going into the appropriate CWD? For me, it just stays in my build-root-directory where I issued the bitbake command..?09:27
jofrMy OE_TERMINAL is set to tmux-new-window09:27
jofrIf I use another terminal for OE_TERMINAL I get the correct behavior.09:28
yoctiNew news from stackoverflow: how to force order in DEPENDS while preparing recipe-sysroot? <>09:28
*** sgw <sgw!~sgw@> has quit IRC09:36
RPrburton: care to glance over -next?09:41
RPrburton: builds cleanly and I think this does fix the httpservice hang09:41
moemoeLetoThe2nd: switched to thud, no problems so far (but compile is still running).09:42
*** sgw <sgw!~sgw@> has joined #yocto09:42
moemoejust didn't wait long enough :/09:43
moemoe| ERROR: Function failed: do_compile (log file is located at /home/mo/src/yocto-rpi/plain-rpi-thud/tmp/work/x86_64-linux/autoconf-native/2.69-r11/temp/log.do_compile.21092)09:43
moemoeERROR: Task (virtual:native:/home/mo/src/poky-thud/meta/recipes-devtools/autoconf/ failed with exit code '1'09:43
*** rburton <rburton!> has quit IRC09:45
RPmoemoe: Some things to check a) did it build m4-native? b) is m4 in the recipe-sysroot-native for autoconf-native? c) is there anything interesting about the missing m4 in config.log ?09:45
*** OpenSorc_ <OpenSorc_!> has joined #yocto09:50
*** gunnarx__ <gunnarx__!> has joined #yocto09:50
*** dev1990 <dev1990!> has quit IRC09:52
*** eduardas_m <eduardas_m!~eduardas@> has quit IRC09:52
*** Bunio_FH <Bunio_FH!> has quit IRC09:52
*** dev1990 <dev1990!> has joined #yocto09:52
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto09:52
moemoeRP: a) according to tmp/log/cooker/raspberrypi-cm3/20181116093521.log "NOTE: recipe m4-native-1.4.18-r0: task do_populate_sysroot: Succeeded"09:53
moemoeb) mo@rrpc0019:~$ grep m4-native src/poky-thud/meta/recipes-devtools/autoconf/autoconf.inc09:53
moemoeDEPENDS += "m4-native"09:53
moemoeDEPENDS_class-native = "m4-native gnu-config-native"09:53
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC09:53
*** nighty- <nighty-!> has joined #yocto09:53
*** Bunio_FH <Bunio_FH!> has joined #yocto09:53
*** sgw <sgw!~sgw@> has quit IRC09:53
*** gunnarx <gunnarx!~gunnarx@unaffiliated/gan> has quit IRC09:53
*** rajm <rajm!~robertmar@> has quit IRC09:53
*** joeythesaint <joeythesaint!> has quit IRC09:53
*** joeythesaint <joeythesaint!~joe@2605:6400:2:fed5:22:41:45ec:bf91> has joined #yocto09:54
*** rajm <rajm!~robertmar@> has joined #yocto09:54
*** sgw <sgw!~sgw@> has joined #yocto09:54
RPmoemoe: no, for b), I mean to go into /home/mo/src/yocto-rpi/plain-rpi/tmp/work/x86_64-linux/autoconf-native/2.69-r11/recipe-sysroot-native and see if usr/bin/m4 exists09:54
moemoeRP: c) doesn't look strange:
RPmoemoe: can you share the whole config.log please?09:55
RPmoemoe: of course this is autoconf-native itself so its not a normal configure process :/09:56
moemoe this m4 binary looks strange to me09:57
RPmoemoe: something is definitely wrong there09:59
RPmoemoe: does /home/mo/src/yocto-rpi/plain-rpi-thud/tmp/sysroots-uninative/x86_64-linux/lib/ exist?09:59
moemoehere is the complete log file:
moemoemo@rrpc0019:~/src/yocto-rpi/plain-rpi-thud/tmp$ file /home/mo/src/yocto-rpi/plain-rpi-thud/tmp/sysroots-uninative/x86_64-linux/lib/
moemoe/home/mo/src/yocto-rpi/plain-rpi-thud/tmp/sysroots-uninative/x86_64-linux/lib/ symbolic link to ld-2.28.so10:00
moemoemo@rrpc0019:~/src/yocto-rpi/plain-rpi-thud/tmp$ file /home/mo/src/yocto-rpi/plain-rpi-thud/tmp/sysroots-uninative/x86_64-linux/lib/ld-2.28.so10:00
moemoe/home/mo/src/yocto-rpi/plain-rpi-thud/tmp/sysroots-uninative/x86_64-linux/lib/ ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=692dcab863f5451a27fa549f337f6ce1767f36fe, stripped10:00
RPmoemoe: are you building on a noexec filesystem or something odd like that? has any OE/Yocto build every worked?10:02
RPmoemoe: also, what is the host distro? The only difference in the file output between your build and mine is your kernel version is older (2.6.32 for you, 3.2.0 for me)10:03
RPmoemoe: I suspect something in the uninative code is break things but I don't know how/why :/10:04
LetoThe2ndhum, he said "debian stable"... but 2.6.32 indicates debian squeeze, which is certainly far beyond stable, with LTS having ended in 201610:08
RPLetoThe2nd: remember this is a minimum version, not the actual kernel version10:09
*** jlanda23 <jlanda23!~jlanda@> has joined #yocto10:09
LetoThe2ndRP: i remember nothing, as usual. ;-)10:09
RPso its certainly using a generation older ABI than my binaries but doesn't mean its that old10:09
*** frsc <frsc!> has quit IRC10:10
*** mihais <mihais!~mihaiserb@> has left #yocto10:11
moemoeIt's a Debian running in WSL, I just ordererd a regular Debian VM to try over there.10:11
moemoeWill be ready in some minutes :)10:11
*** ak77__ <ak77__!~ak@> has joined #yocto10:12
RPmoemoe: WSL? That is known not to work10:12
*** ak77__ <ak77__!~ak@> has left #yocto10:13
LetoThe2nd(why can't people mention such weirdnesses right upfront?)10:13
RPI think we're going to need to start detecting WSL10:14
moemoeRP: Okay. Good to know. I searched for WSL in but it wasn't mentioned there10:14
moemoeJust came to my mind when reading the kernel version above, using it for golang since a while and never had problems...10:15
RPmoemoe: I will mention this to our docs person, we should probably put it in big letters that WSL doesn't work :/10:15
RPmoemoe: OE/Yocto do some interesting things with the system which WSL doesn't support10:16
RPI'd love to have it work but as of today it doesn't10:16
moemoeWould be great to mention it in the docs, or even better detect it automatically, could have saved me a day of trying.10:17
moemoe$ cat /proc/version10:17
moemoeLinux version 4.4.0-17134-Microsoft ( (gcc version 5.4.0 (GCC) ) #345-Microsoft Wed Sep 19 17:47:00 PST 201810:17
moemoesearching for m$ in /proc/version should be the easist wayI guess10:18
moemoeBut thank you for your help so far, RP and LetoThe2nd, sorry I wasted your time trying to hunt an error on a known non-working system.10:19
RPmoemoe: we'll improve the docs and I'll try and add something to detect this, we need to do better here10:19
*** cquast <cquast!~cquast@> has joined #yocto10:21
*** rburton <rburton!> has joined #yocto10:21
*** sgw <sgw!~sgw@> has quit IRC10:22
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto10:22
*** cquast <cquast!~cquast@> has quit IRC10:28
*** rajm <rajm!~robertmar@> has quit IRC10:29
RPmoemoe: patch queued:
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:30
*** cquast <cquast!~cquast@> has joined #yocto10:30
*** anujm <anujm!~anujm@> has quit IRC10:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:34
*** thaytan <thaytan!> has joined #yocto10:37
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC10:38
*** otavio <otavio!~otavio@> has joined #yocto10:41
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto10:41
*** rajm <rajm!~robertmar@> has joined #yocto10:42
*** sgw <sgw!~sgw@> has joined #yocto10:45
*** berton <berton!~berton@> has joined #yocto10:46
*** nathani__ <nathani__!> has joined #yocto10:48
*** berton <berton!~berton@> has quit IRC10:50
*** gtristan <gtristan!~tristanva@> has joined #yocto10:50
*** nathani_ <nathani_!> has quit IRC10:52
*** berton <berton!~berton@> has joined #yocto10:52
*** lusus <lusus!~lusus@> has quit IRC10:55
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto11:00
rburtonmoemoe: what's the error?11:02
moemoerburton: the error was using wsl ;)11:03
rburtonoh right yeah don't do that11:03
*** kuzulis <kuzulis!~kuzulis@> has joined #yocto11:03
rburtonthough bonus points if you root cause it and figure out what the problem is11:04
LetoThe2ndbrownie points, even?11:04
moemoerburton: this is closest I got to the problem11:05
rburtonah yeah thats a problem11:05
rburtonso it can't run native binaries that it build for itself11:05
rburtonmight be useful to file a bug so we keep track of where wsl breaks in case someone really does want to fix it11:06
kuzulisHi guys. What is a best way to generate an different images with a different Linux Kernel patches/configs? For example I have a layer 'foo' which contains the linux recipes and a foo-image recipes.. also I have a layer 'bar' which too has an own linux recipes and own bar-image recipe.. All these layers both are added to bblayers config...11:07
kuzulise.g. foo layer has: meta-foo/recipes-kernel/linux/ and layer bar has: meta-bar/recipes-kernel/linux/..11:08
*** falk0n_ <falk0n_!> has quit IRC11:08
LetoThe2ndkuzulis: if its otherwise completely identical images, just the kernel differs: either select the kernel through PREFERRED_VERSION/PREFERRED_PROVIDER in local.con, or, make it two machines.11:09
rburtonRP: next looks good11:10
*** jkliemann <jkliemann!~jk@> has quit IRC11:11
kuzulisLetoThe2nd: "PREFERRED_VERSION/PREFERRED_PROVIDER" but the Linux kernels are identical for both layers... How I can divide it to two different providers?11:11
LetoThe2ndwell you'd obviously have to give it distinct names, like linux-foo and linux-bar11:12
LetoThe2ndwhich could be merely wrappers around a common linux-funky-stuff.inc11:12
*** falk0n <falk0n!> has joined #yocto11:15
kuzulisLetoThe2nd: Hmm.. but, then I need to modify the local.conf file each time when I want to build the foo-image or bar-image.. Yes? But, is it possible to do it without of modifing of local.conf?11:15
LetoThe2ndkuzulis: -> MACHINES11:15
*** falk0n <falk0n!> has quit IRC11:16
LetoThe2ndin the end you'd basically have two biuld directories. they can share a common sstate, so little performance penalty.11:16
*** falk0n <falk0n!> has joined #yocto11:17
kuzulisLetoThe2nd: So, do I need to imagine an own machine name?11:19
LetoThe2ndif you're lacking imagination, call them machine1 and machine2.....11:20
LetoThe2ndi mean, you need *SOME* kind of distinction *SOMEWHERE*11:22
kuzulisLetoThe2nd: Hmm.. I don't understand a bit... F.e. currently I use an one board 'apalis-imx6' as a basic platform for the different output images... Some of this images has an bluetooth stack enabled, some has an WiFi support enabled and so on... So, it is similar to that a different 'images' belongs to a different 'projects' basen on 'apalis-imx6' machine. Each that project located on own layer (with own image recipe, a main application recipe and so11:27
kuzulison.)... So, is it an one way to do such customizations - it is create an own machines for each 'project/layer'?11:27
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto11:28
LetoThe2ndit really depends on the variations between the projects. but generally, yes, its very common to have a MACHINE config per project.11:29
kuzulisLetoThe2nd: Ok, many thanks for your help. I try look to this way :)11:30
LetoThe2ndkuzulis: in a nutshell, try to view it as three orthogonal things: MACHINE: defines the hardware/feature support for a given project, DISTRO: defines the ABI for a project, IMAGE: defines what packages go into a specific thing11:31
kuzulisLetoThe2nd: What is means of " the ABI for a project" ?11:33
kuzulisLetoThe2nd: I mean in context of Yocto.. :)11:35
LetoThe2ndkuzulis: its the same in the context of yocto.11:35
kuzulisLetoThe2nd: Ok, manu thanks11:36
RPrburton: thanks11:39
*** lusus <lusus!~lusus@> has joined #yocto11:57
*** gtristan <gtristan!~tristanva@> has quit IRC12:05
*** kuzulis <kuzulis!~kuzulis@> has quit IRC12:09
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto12:14
*** xtron <xtron!~xtron@> has joined #yocto12:16
moemoenow binutils-cross-arm fails. /home/yocto/src/yocto-rpi/plain-rpi-thud/tmp/log/cooker/raspberrypi-cm3/console-latest.log -> and /home/yocto/src/yocto-rpi/plain-rpi-thud/tmp/work/x86_64-linux/binutils-cross-arm/2.31-r0/temp/log.do_compile.25454 ->
moemoerunning on branch "thud" and master for meta-raspberrypi12:17
*** gtristan <gtristan!~tristanva@> has joined #yocto12:25
*** rburton <rburton!> has quit IRC12:33
*** rburton_ <rburton_!> has joined #yocto12:33
*** sno <sno!> has quit IRC12:36
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:38
*** nathani_ <nathani_!> has joined #yocto12:49
*** learningc <learningc!> has quit IRC12:51
*** nathani__ <nathani__!> has quit IRC12:53
RPmoemoe: you do seem to be having some bad luck with this :(12:53
RPmoemoe: We build that in our core test builds so it would suggest something rpi related :/12:54
RPmoemoe: you might want to test if qemuarm builds? see if you can at least get that working? We *know* that should work12:54
moemoeRP: I'm currently trying sumo, as there is no official thud release for meta-raspberrypi and I need a working system :)12:56
moemoeBut as soon as this is okay I can strart a qemuarm build w/o meta-raspi in teh background12:56
*** gunnarx__ is now known as gunnarx13:04
*** geissona_ <geissona_!~geissonat@> has joined #yocto13:11
*** gunnarx <gunnarx!> has quit IRC13:17
yoctiNew news from stackoverflow: How to find which Yocto Project recipe populates a particular file on an image root filesystem <>13:29
*** sno <sno!> has joined #yocto13:32
*** sno <sno!> has quit IRC13:34
*** sno <sno!~sno@2a01:598:8084:a54a:79e6:2b91:654a:8b35> has joined #yocto13:35
*** sno <sno!~sno@2a01:598:8084:a54a:79e6:2b91:654a:8b35> has quit IRC13:41
*** sno <sno!> has joined #yocto13:43
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC13:49
*** bernardoaraujo <bernardoaraujo!> has joined #yocto13:49
yatesregarding dnf and package-management, i did notice that specifying PACKAGE_CLASSES ?= "package_rpm" got rpm into my build, but not dnf. I also could not find any reference to dnf in any of my layers.13:55
yatesis it possible that morty did not yet include dnf?13:55
yatesor is specifying PACKAGE_CLASSES ?= "package_rpm" in my build/conf/local.conf does not operate properly and i need to have it in my own distro.conf file?13:57
RPyates: which version are you building (which branch?)13:57
bernardoaraujoI need to have internal copies of all the source code used to build the linux image in my company. That means cloning all the github repos and tarballs to our servers, and making the recipes point to them.13:58
bernardoaraujoPoky has a very large number of recipes, and manually rewriting all of them would be a lot of work... Is there any way of doing that in a efficient and reliable way, instead of manually?13:58
RPbernardoaraujo: using our inbuilt mirroring mechanism?13:58
bernardoaraujohey RP, I'm not aware of it... where can I find more info?13:59
yatesRP: i believe it's Mort, yocto project version 2.2, current version 2.2.4, as stated here:
RPyates: morty contains smart instead of dnf14:00
RPyates: we only moved to dnf later14:00
rburton_yates: morty is *old*14:01
rburton_(just in case you didn't already know)14:01
RPrburton_: have you much for the AB right now?14:01
rburton_was literally gearing up a build14:02
yatesrburton_: i do. there are some painful reasons we need to stay here for right now.14:02
rburton_i can wait, or pull something else in14:02
RPrburton_: can you include -next? I could do with a build to watch the AB UI ;-)14:02
RPrburton_: -next is mainly some bitbake tweaks14:02
rburton_RP: was firing mut so that's based on current next14:02
RPrburton_: could you quickly rebase please :)14:02
rburton_top commit right now is the wsl fix14:03
RPrburton_: its not now14:03
rburton_oh now you've pushed ;)14:03
RPrburton_: just to be awkward :)14:03
rburton_also got mingw master-next with the three new patches in14:04
RPrburton_: thanks. Now lets see if the UI behaves better14:04
yatesRP: would it be hard to modify to pull in dnf instead? i've found it in the latest openembedded project here
rburton_yates: the switch from smart to dnf certainly wasn't trivial14:06
rburton_the rootfs generation is done with that tool so its not just an swap14:06
zeddii_homeand wasn’t there an rpm5 issue with dnf, hence why we are also rpm4+dnf now14:06
RPyates: I'd recommend using a later release, it will be easier14:07
rburton_zeddii_home: pretty sure dnf needs rpm414:07
RPyou have to swap rpm5 for rpm414:07
rburton_yates: at the end of the day dnf and smart both *work*14:07
rburton_we flipped for numerous reasons14:08
rburton_backporting all the patches to morty isn't impossible, but its likely easier to upgrade past morty!14:08
rburton_if you have an OEM who only supports morty, point out how old it is and how its not getting security fixes anymore14:08
yatesrburton_: we're using Variscite SoMs, and they do provide newer yocto project versions, but thos new versions use newer versions of the serial driver, and we've made some very painful tweaks on that version of the serial driver.14:10
yatesand these tweaks are crucial to the functionality our business is providing14:11
yatesthat is, our product14:12
RPyates: I suspect using making their morty kernel work on a later release would be easier than swapping in dnf14:12
* zeddii_home nods14:12
yatesIF we were to switch now, would sumo be right?14:14
bernardoaraujoRP: if I prepend my server to the PREMIRRORS var, how do I know whether the source code will be fetched from the mirror or the actual SRC_URI?14:14
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto14:16
RPbernardoaraujo: BB_FETCH_PREMIRRORONLY = "1"14:16
RPyates: that depends. thud just released, sumo is more stable/tested14:17
RPwe release every six months14:17
*** marka <marka!~masselst@> has joined #yocto14:20
yatesok, thanks. i'm tempted to just use smart... that's the MUCH more direction option for now.14:21
yatesmore direct14:21
yatesi know upgrading is going to be required, but not TODAY... :)14:22
*** ant_work <ant_work!~ant__@> has quit IRC14:22
*** Aethenelle <Aethenelle!Aethenelle@gateway/shell/panicbnc/x-ietbihkfbnmfxpqp> has quit IRC14:23
*** rovanceo_ <rovanceo_!~rovanceo@> has joined #yocto14:23
*** Aethenelle <Aethenelle!Aethenelle@gateway/shell/panicbnc/x-awsjvofkpeageski> has joined #yocto14:23
*** rovanceo <rovanceo!~rovanceo@> has quit IRC14:27
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto14:30
*** lusus <lusus!~lusus@> has quit IRC14:31
*** JaMa <JaMa!~martin@> has quit IRC14:45
*** stephano <stephano!~stephano@> has joined #yocto14:46
*** lpapp_ <lpapp_!~lpapp@kde/lpapp> has joined #yocto14:49
lpapp_hi, is there a way to install native python six from the standard library?14:49
*** Aethenelle <Aethenelle!Aethenelle@gateway/shell/panicbnc/x-awsjvofkpeageski> has left #yocto14:53
*** Aethenelle <Aethenelle!Aethenelle@gateway/shell/panicbnc/x-awsjvofkpeageski> has joined #yocto14:54
*** sgw <sgw!~sgw@> has quit IRC15:05
rburton_lpapp_: python-six-native?15:09
*** sgw <sgw!~sgw@> has joined #yocto15:10
*** peacememories <peacememories!> has joined #yocto15:16
*** peacememories <peacememories!> has quit IRC15:26
lpapp_rburton_: that would bring another layer in, so I have decided to eliminate the use of six in our python code, thanks15:39
lpapp_also, I am not sure why people need native python in the sdk... cannot the system-wide python be used ok?15:40
RPlpapp_: sometimes the system-wide python is too old15:41
rburton_or sometimes the sdk contains python modules that are written in C15:41
*** achingbrain15 <achingbrain15!> has joined #yocto15:41
rburton_*if* you can assume the host has a good enough py and *if* you've verified there is no python-written-in-c in your sdk, it's fairly trivial to knock out15:41
yateswhere does smart get its configuration from? for example the repository uri?15:41
lpapp_is it15:41
rburton_we already do exactly that for perl15:42
rburton_yates: /etc/something :)15:42
yatesthe docs say /etc/smart... but there is no such file/directory. yet it is connecting to the uri i specified in the build...15:43
rburton_yates: magic!  grep for that url?15:43
yatesdon't tell me it gets hardcoded...15:43
lpapp_how to knock out15:43
rburton_must go somewhere else15:43
rburton_lpapp_: see meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb15:43
yatesi ran strace and could see anywhere in /etc15:43
yates-0couldn't see15:44
*** sgw <sgw!~sgw@> has quit IRC15:48
*** sgw <sgw!~sgw@> has joined #yocto15:50
yateshmm. /var/lib/smart/config15:54
yatesberry stwange15:54
yatesthe magic of unconvention...15:54
rburton_hooray smart15:55
rburton_maybe it look in both and the automatic feed configuration should write to /etc instead15:56
JPEWrburton_: Seeing as this is the first layer I've ever maintainer, don't think your off the hook yet, I will have questions :)15:58
rburton_JPEW: that's fair :)15:59
RPJPEW: :D16:00
rburton_JPEW: fwiw i've the last few patches on the list running through the ab now16:01
RPrburton_: for some definition of running ;-)16:01
* RP ducks16:01
rburton_this new run is a lot happier!16:02
rburton_oh forgot to rebase the dnf patch!16:02
JPEWOk. that is one of my questions; How do I patches for meta-mingw get run through the AB?16:02
*** lfa <lfa!> has quit IRC16:02
rburton_JPEW: the nightly-qa-extras run currently exercises it a bit16:03
rburton_fired as part of the "nightly" build16:03
rburton_(nightly isn't ran nightly)16:04
rburton_as you know that's just a build test, doesn't say anything about if it works, so i'm looking forward to your patches :)16:04
JPEWrburton_: Ok, I think thats fine since the volume of patches is low, is it pulling master-next?16:04
rburton_JPEW: the actual automated runs pull the relevant release branch.  otherwise generally master unless told otherwise: i fired the last run manually and told it to pick up master-next explicitly16:05
JPEWrburton_: Ok, would it be sufficent then to notify you or RP when there are changes in master-next that need to be tested and you can pull them into the next build?16:06
rburton_JPEW: absolutely.16:07
JPEWrburton_: OK, that works for me, Thanks!16:07
*** prabhakarlad <prabhakarlad!~prabhakar@> has left #yocto16:08
RPrburton_, JPEW: we can run qa-extras separately too16:15
OutBackDingonrossi: ping... success16:17
nrossiOutBackDingo: success as in you got it booting and running the encrypted volume? :)16:20
* armpit watches JPEW slowly increasing his power16:22
* JPEW arches fingers... "excellent"16:23
OutBackDingonrossi: Yupp....16:25
RParmpit: do I need to do some stable merged?16:28
armpitstable/sumo-next is fine16:31
bernardoaraujoTP: thanks man!!!! bye!16:32
*** bernardoaraujo <bernardoaraujo!> has quit IRC16:32
RParmpit: merged, thanks16:33
*** TobSnyder <TobSnyder!~schneider@> has quit IRC16:33
*** falk0n <falk0n!> has quit IRC16:34
*** falk0n <falk0n!> has joined #yocto16:34
*** xtron_ <xtron_!~xtron@> has joined #yocto16:40
*** lucaceresoli <lucaceresoli!> has quit IRC16:42
*** xtron_ <xtron_!~xtron@> has quit IRC16:42
*** xtron_ <xtron_!~xtron@> has joined #yocto16:43
*** eduardas_m <eduardas_m!~eduardas@> has quit IRC16:44
*** learningc <learningc!~learningc@> has joined #yocto16:45
*** xtron_ <xtron_!~xtron@> has quit IRC16:46
*** Bunio_FH <Bunio_FH!> has quit IRC16:49
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:56
armpitrburton_, vte failed to build in mut.. need to bug it?17:00
rburton_armpit: on it already17:02
RParmpit: I added 5 patches to thud-next17:02
armpitalso there is a warning on do_patch for dnf17:02
armpitRP, k17:03
rburton_yeah on that too17:03
*** rajm <rajm!~robertmar@> has quit IRC17:05
*** martinkelly <martinkelly!~martin@> has joined #yocto17:08
*** georgem <georgem!~georgem@> has quit IRC17:11
*** feddischson <feddischson!> has joined #yocto17:12
*** maudat <maudat!~moda@> has joined #yocto17:14
*** sagner <sagner!~ags@> has quit IRC17:16
*** georgem <georgem!~georgem@> has joined #yocto17:19
*** peacememories <peacememories!> has joined #yocto17:22
*** peacememories <peacememories!> has quit IRC17:26
*** varjag <varjag!> has quit IRC17:27
*** mckoan is now known as mckoan|away17:28
*** WillMiles <WillMiles!> has joined #yocto17:39
*** cquast <cquast!~cquast@> has quit IRC17:45
*** sveinse <sveinse!> has left #yocto17:46
*** Zougloub <Zougloub!> has quit IRC17:52
*** Zougloub <Zougloub!> has joined #yocto17:57
*** scottrif <scottrif!> has joined #yocto18:04
*** learningc <learningc!~learningc@> has quit IRC18:21
*** sgw <sgw!~sgw@> has quit IRC18:30
*** dv_ <dv_!> has quit IRC18:34
*** dreyna <dreyna!> has joined #yocto18:41
*** feddischson <feddischson!> has quit IRC18:44
*** falk0n <falk0n!> has quit IRC18:46
*** dv_ <dv_!> has joined #yocto18:48
*** JPEW <JPEW!cc4da337@gateway/web/freenode/ip.> has quit IRC19:10
la_croix_Evening all. Quick question about standard practice. I have a program that I would like to run periodically. I will trigger it with cron, no problem there, but it's written in go. Is the correct procedure to (cross) compile it myself, and provide the binary to the recipe, or should the recipe do the compilation itself?19:21
aehs29Im a little confused here, is the bitbake command available on the eSDK or not?19:22
*** JPEW <JPEW!cc4da337@gateway/web/freenode/ip.> has joined #yocto19:36
*** yann <yann!> has joined #yocto19:53
*** OpenSorc_ <OpenSorc_!> has quit IRC19:54
*** berton <berton!~berton@> has quit IRC19:57
*** berton <berton!~berton@> has joined #yocto19:57
*** gtristan <gtristan!~tristanva@> has quit IRC20:08
*** ntl <ntl!> has joined #yocto20:12
*** yann <yann!> has quit IRC20:12
*** marka <marka!~masselst@> has quit IRC20:15
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto20:26
*** berton <berton!~berton@> has quit IRC20:29
*** ntl <ntl!> has quit IRC20:32
*** yann <yann!> has joined #yocto20:33
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto20:40
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto20:52
rburton_la_croix_: why would you build it outside of bitbake?  build it in a recipe along with everything else you ship21:01
la_croix_rburton_  No reason, really, I'm just asking what standard practice is. So I just install go on the build machine and build it in the recipe?21:02
rburton_la_croix_: use meta-go to get a go cross compiler21:02
rburton_standard practise is that your layer builds *everything* from sources in a single blast, so you can have *all* the build steps in one place21:04
*** lpapp__ <lpapp__!~lpapp@kde/lpapp> has joined #yocto21:04
la_croix_rburton_ Does this not work in regular go? I saw this: env GOOS=linux GOARCH=arm64 go build foo21:04
rburton_no insert magic binary built using instructions which have got lot21:04
rburton_la_croix_: no idea, never used go21:04
la_croix_rburton_ That makes sense, thank you21:04
rburton_er, 'got lost', but you see the point21:06
rburton_that's the ethos anyway21:06
la_croix_rburton_ Absolutely.21:07
*** lpapp_ <lpapp_!~lpapp@kde/lpapp> has quit IRC21:07
la_croix_rburton_ Never used go myself, actually. This just seems like a decent opportunity to learn it21:07
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto21:10
*** lpapp__ <lpapp__!~lpapp@kde/lpapp> has quit IRC21:11
*** rburton_ <rburton_!> has quit IRC21:13
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC21:20
*** bleu <bleu!> has joined #yocto21:30
*** bleu is now known as brianleu21:31
*** dreyna <dreyna!> has quit IRC21:41
*** WillMiles <WillMiles!> has quit IRC21:49
*** kaspter1 <kaspter1!~Instantbi@> has joined #yocto21:51
*** kaspter <kaspter!~Instantbi@> has quit IRC21:52
*** kaspter1 is now known as kaspter21:52
*** phragment_ <phragment_!> has quit IRC21:55
*** jkliemann <jkliemann!> has joined #yocto21:59
*** geissona_ <geissona_!~geissonat@> has quit IRC22:18
*** geissona_ <geissona_!~geissonat@> has joined #yocto22:19
*** phragment <phragment!> has joined #yocto22:38
*** JPEW <JPEW!cc4da337@gateway/web/freenode/ip.> has quit IRC23:03
*** phragment <phragment!> has quit IRC23:04
*** phragment <phragment!> has joined #yocto23:13
*** phragment <phragment!> has quit IRC23:18
*** [Sno] <[Sno]!> has joined #yocto23:21
*** sno <sno!> has quit IRC23:24
*** phragment <phragment!> has joined #yocto23:32
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:39
*** nathani_ <nathani_!> has quit IRC23:44
*** nathani_ <nathani_!> has joined #yocto23:44
*** nathani_ <nathani_!> has joined #yocto23:45
*** phragment <phragment!> has joined #yocto23:54
*** maudat <maudat!~moda@> has quit IRC23:54
*** yizhao <yizhao!~zhaoyi@> has quit IRC23:54
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto23:56

Generated by 2.11.0 by Marius Gedminas - find it at!