Tuesday, 2020-09-22

*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto00:01
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC00:04
*** nslu2-log_ is now known as nslu2-log00:04
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC00:12
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto00:15
JPEWkhem: Wants doesn't mean it has to wait, it just means it starts the generation00:15
JPEWEffectively, it's saying: "start ssh key generation no later than when I create the SSH sockets"00:16
JPEWBut it is *not* saying "wait until key generation is complete before creating the socket". That would be After=00:16
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto00:20
*** rcw <rcw!~rcw@> has quit IRC00:20
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC00:23
*** nslu2-log_ is now known as nslu2-log00:23
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC00:26
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto00:26
*** rcw <rcw!~rcw@> has joined #yocto00:26
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto00:37
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC00:40
*** nslu2-log_ is now known as nslu2-log00:40
*** rcw <rcw!~rcw@> has quit IRC00:44
JPEWkhem, RP: Sent an RFC to the mailing list that I think will do what you are asking00:45
JPEW...ish. systemd is really fuzzy on when "init" is "complete" :)00:45
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC00:53
*** samvlewis <samvlewis!~samvlewis@> has quit IRC00:54
*** samvlewis <samvlewis!~samvlewis@> has joined #yocto00:54
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto00:55
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC00:58
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto00:59
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has quit IRC01:01
*** samvlewis <samvlewis!~samvlewis@> has quit IRC01:12
*** samvlewis <samvlewis!~samvlewis@> has joined #yocto01:18
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto01:28
*** samvlewis <samvlewis!~samvlewis@> has quit IRC01:36
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:39
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC01:43
*** samvlewis <samvlewis!~samvlewis@> has joined #yocto01:49
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC02:09
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto02:10
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC02:17
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto02:18
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto02:32
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC02:36
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC02:41
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto02:43
kergothrburton: am i rememberign wrong, or did you have something to lint python code that's in classes?02:43
kergothRP: should think about running https://github.com/netromdk/vermin against bitbake (and possibly oe-core libs) as a CI/autobuilder operation to check against our defined dependent python versions02:46
*** hpsy1 <hpsy1!~hpsy@> has joined #yocto02:47
*** hpsy <hpsy!~hpsy@> has quit IRC02:49
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto02:54
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC02:56
*** nslu2-log_ is now known as nslu2-log02:56
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto03:29
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC03:32
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto03:37
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto03:37
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC03:39
*** nslu2-log_ is now known as nslu2-log03:39
*** alejandrohs <alejandrohs!~alejandro@2605:6000:1306:9479::a59> has quit IRC04:19
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC04:25
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto04:31
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC04:34
*** nslu2-log_ is now known as nslu2-log04:34
*** jobroe <jobroe!~manjaro-u@p579eb9ab.dip0.t-ipconnect.de> has joined #yocto04:51
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-pbqjixdcjaqoljgk> has quit IRC05:02
*** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto05:16
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto05:27
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC05:32
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto05:39
*** MiskaX <MiskaX!trop0y73ze@rankki.sonarnerd.net> has quit IRC05:41
*** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto05:42
*** sxiii <sxiii!~sw@cm-> has quit IRC05:45
*** Yatekii <Yatekii!~yatekii@huesser.dev> has quit IRC05:48
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC05:52
*** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-060.hsi5.kabel-badenwuerttemberg.de> has joined #yocto05:53
*** kaspter <kaspter!~Instantbi@> has quit IRC06:04
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:04
*** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC06:06
*** chris_ber <chris_ber!~quassel@> has joined #yocto06:15
*** dmoseley <dmoseley!~dmoseley@> has quit IRC06:16
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto06:16
*** sxiii <sxiii!~sw@cm-> has joined #yocto06:22
*** paulg <paulg!~paulg@24-212-228-244.cable.teksavvy.com> has quit IRC06:22
*** zeddii <zeddii!~zeddii@CPE04d4c4975b80-CM64777d5e8820.cpe.net.cable.rogers.com> has quit IRC06:23
*** ArnaudP <ArnaudP!~ArnaudP@111988HD51007.ikexpress.com> has quit IRC06:23
*** ArnaudP <ArnaudP!~ArnaudP@111988HD51007.ikexpress.com> has joined #yocto06:24
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto06:34
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC06:34
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC06:35
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC06:36
*** nslu2-log_ is now known as nslu2-log06:36
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto06:40
*** zandrey <zandrey!~zandrey@> has joined #yocto06:46
*** zeddii <zeddii!~zeddii@CPE04d4c4975b80-CM64777d5e8820.cpe.net.cable.rogers.com> has joined #yocto06:46
*** carlsb3rg <carlsb3rg!c147afcf@> has quit IRC06:48
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto06:50
*** fl0v0 <fl0v0!~fvo@> has joined #yocto06:51
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC06:52
*** nslu2-log_ is now known as nslu2-log06:53
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto06:57
*** koty0f <koty0f!~filip@> has joined #yocto06:58
*** hpsy1 <hpsy1!~hpsy@> has quit IRC07:05
*** w00die <w00die!~w00die@> has quit IRC07:05
*** w00die <w00die!~w00die@> has joined #yocto07:07
*** C-o-r-E <C-o-r-E!~corey@modemcable069.166-70-69.static.videotron.ca> has quit IRC07:14
*** C-o-r-E <C-o-r-E!~corey@modemcable149.12-178-173.mc.videotron.ca> has joined #yocto07:16
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto07:17
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto07:20
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.> has quit IRC07:24
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto07:28
*** fbre <fbre!91fdde45@> has joined #yocto07:28
*** manuel1985 <manuel1985!~manuel@> has joined #yocto07:31
fbreHi! I'm searching for a magic kernel menuconfig switch which enables USB for me. I have switched on a lot of switches already but I don't see such message on console: [ 5267.508825] usb 1-1.1: new full-speed USB device number 4 using ci_hdrc07:35
fbreI think I'm still missing the magic menuconfig switch for ci_hdrc07:35
fbreDo you know which entry is for ci_hdrc?07:36
fbreCurrently, I don't see console messages when I'm plugging in/out an USB dongle07:37
fbre...and dmesg logging either07:37
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto07:40
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has joined #yocto07:44
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC07:44
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has quit IRC07:50
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has joined #yocto07:51
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto07:52
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC07:54
*** nslu2-log_ is now known as nslu2-log07:55
*** fbre <fbre!91fdde45@> has quit IRC08:01
*** mckoan|away is now known as mckoan08:02
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC08:06
*** fbre <fbre!91fdde45@> has joined #yocto08:07
*** dleppich <dleppich!~dleppich@> has joined #yocto08:08
*** wertigon <wertigon!~per@c-e961225c.021-396-7673741.bbcust.telenor.se> has joined #yocto08:09
dleppichHello guys :) I'm quite new to the yocto project and embedded linux in general. Do you know of any simple tasks to get hands on and dig into the yocto project? I already read some websites and quick start guides, but don't really know what to do next. I will need Yocto at my work soon and want to prepare as good as possible..08:11
wertigonQuick question about SDK; so I have built the SDK and everything work as intended, however, I get a lot of targets which blows the size of the SDK to ~6GB uncompressed. Any way to slim these down?08:11
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto08:11
wertigondleppich: Hmm, I find making a personal small project works best08:12
qschulzdleppich: look at the YoctoProject youtube channel. There are a few tutorials for beginners here :) Otherwise, like wertigon said try to build a small project with Yocto. You can use qemu if you don't have a board available yet08:13
wertigonNo idea what your setup is, and there are a million ways to go08:13
fbredleppich: I would search YouTube for "yocto tutorial for beginners"08:13
qschulzdleppich: start small to not get overwhelmed08:13
wertigondleppich: If you have a board available, one good way to get started is to get an LED to blink :)08:14
wertigonAnd on that topic, maybe see if you can create an LED controller for a USB LED strip?08:15
*** lucaceresoli__ <lucaceresoli__!~lucaceres@78-134-51-148.v4.ngi.it> has joined #yocto08:15
dleppichI have the BeagleBone Black and a SAMA5D3 XPlained available. Bringing an LED to live sounds interesting, but where is the connection to the yocto project? I already worked with Raspberrys and Arduinos in the past and controlled different kinds of electronics. I know how to write a program doing this.08:15
dleppichWould the task here be to write a recipe for such a program and use yocto to build an image with my program inside and burn this to the board?08:16
wertigonIt is a starting point at least :)08:16
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has quit IRC08:17
dleppichYou wrote something about writing an LED controller. How exactly do I do this? Or do ask differently (I'm not that lazy): What do I have to learn to do this? I never wrote a controller nor do I know how they are used or work..08:17
wertigonBuild on what you know and are comfortable with; for my use case, I have played around a bit with robotics so ROS and image recognition through USB camera08:17
wertigonLED controller is pretty much just buy an LED strip powered by USB (available @ ikea) and plug it in08:18
wertigonPreferrably an RGB one08:19
wertigonLots of places carry it, is cheap hardware (around $20 for a package)08:19
wertigonAnd then you simply learn to communicate with that and figure out a way to communicate08:20
*** lucaceresoli__ <lucaceresoli__!~lucaceres@78-134-51-148.v4.ngi.it> has quit IRC08:20
dleppichOkay, you mean a real hardware LED controller. I know these little "boxes". But what do you mean by writing a controller? Some embedded system which is able to e.g. play various animations on the strip and be controlled by some input?08:20
wertigonSo say, in the end you can either press a button or remotely send a command that allows you to send mode and color ranges somehow08:20
dleppichAh okay, think I go it08:20
*** gourve_l <gourve_l!~laurent@static-176-175-104-214.ftth.abo.bbox.fr> has quit IRC08:20
wertigonMore like some Human Interface to the LED strip :)08:20
wertigonNo need to reinvent the wheel too much ya?08:21
dleppichI did something like this on Arduino before, what exactly would be the difference to do this with yocto? Just writing the recipe again, right?08:21
wertigonYeah, you learn to work with Yocto basically08:22
dleppichI also know how to use GPIO pins on the raspberry pi for example, but not how to do this on arbitrary platforms to manually control pins. What is the general approach on other boards?08:22
wertigonIf you want more of a challenge, hook up a USB webcam and ROS, and try to work with some image recognition (like, make it recognize an item and blink LED if that item is shown)08:22
*** gourve_l <gourve_l!~laurent@> has joined #yocto08:23
ptsnevesdleppich its linux, so the gpio kernel entry points are the same just with different pin number/id08:23
dleppichThat sounds interesting but I never worked with image recognition before and I think it would be too much out of scope for my future projects, but I might dive into this in my freetime :)08:24
ptsnevesi also do not think the program is the relevant thing if you want to learn yocto I would suggest instead taking some random meson,makefile project etc and try to create a recipe08:24
ptsnevesstarting by using the devtool08:24
wertigonAnyway, my SDK is 2.3GB compressed - is there any way to make it smaller?08:25
dleppichptsneves: That sounds like a good way to go. Are there any references out there, what projects are easy to write recipes for to get started? Because I have no clue what projects to look for to be honest. I'm a "normal" Linux user I'd say but had nothing to do with self compiling and building projects before08:26
qschulzdleppich: create an image and flash it first. Once that's done, add a package to your image, check it's installed. Then create a recipe for some code you find on the internet (or your company's). That's probably going to be the first hurdle since it is not uncommon to have code not meant to be cross-compiled08:26
wertigonused bitbake myimage -c populate_sdk to generate08:26
qschulzdleppich: YoctoProject YT channel, tutorials playlist.08:26
qschulzdleppich: very accessible08:26
dleppichwertigon, ptsneves and qschulz: Thanks so far! I will go through your recommendations and should be busy for quite a while! Thanks again :)08:27
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto08:28
wertigonOr phrased another way; I don't need qemu in my Yocto SDK since our devs all have hardware access08:29
ptsnevesdleppich: Follow qschulz order and change do the recipe i said at the end. There are many, depending on what you want to do, cmake autotools meson or make08:29
wertigonAny way to remove qemu from the SDK?08:29
ptsneveswertigon why do you not use devtool from yocto?08:30
*** psnsilva__ <psnsilva__!~psnsilva@> has quit IRC08:30
wertigonptsneves: Short answer; our guys are hooked on Windows :D08:32
*** camus1 <camus1!~Instantbi@> has joined #yocto08:32
wertigonSo they develop in Visual Studio but need the gcc crosscompiler + libraries + target files08:32
ptsneves:)  i did not know yocto generated sdks for windows08:32
*** kaspter <kaspter!~Instantbi@> has quit IRC08:32
*** camus1 is now known as kaspter08:32
wertigonIt does with mingw-layer08:33
ptsneveswow that is very neat. I use the mingw layer but never for sdk. Ok let me check the exact variable08:33
wertigonBasicly we have the base OS (my responsibility) and then the App that Does Stuff(tm) (think proprietary protocol firewall)08:34
wertigonThey need to be able to build the App... On Windows... Using our crosscompiler08:34
fbreVisual Studio supports projects for building Linux programs. Just use it and setup your cross-compiler for your platform08:36
ptsnevesok so there are variables called SDK_DEPENDS and SDK_RDPEPENDS. They are set in poky/meta/classes/populate_sdk_base.bbclass:08:36
ptsnevesSDK_DEPENDS = "virtual/fakeroot-native xz-native cross-localedef-native nativesdk-qemuwrapper-cross ${@' '.join(["%s-qemuwrapper-cross" % m for m in d.getVar("MULTILIB_VARIANTS").split()])} qemuwrapper-cross"08:37
ptsnevesso modify the TOOLCHIN_TARGET_TASK and TOOLCHAIN_HOST_TASAK08:37
ptsnevesTOOLCHAIN_HOST_TASAK and set it to your hearts desire :)08:37
wertigonOk so if I set TOOLCHAIN_TARGET_TASK = "beagleboard" and TOOLCHAIN_HOST_TASK = "win32" that should pretty much only compile beagleboard support?08:38
wertigonFor win32 I guess08:39
ptsnevesno, unless you have some package called beagleboard08:39
wertigonAnd yes, probably not exactly those values, but in theory08:39
wertigonOk, I'll have a look, thanks :)08:40
ptsnevesimagine these variables as the image install of the sdk. One is for cross libraries others are for host binaries like the cross compiler08:40
ptsneveswertigon let me know if this helped. I am very curious what will be the value of these variables for the windows sdk case08:43
*** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:f19e:6519:4064:1cca> has joined #yocto08:46
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto08:52
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC08:56
*** eduardas <eduardas!~eduardas@> has joined #yocto08:56
*** paulg <paulg!~paulg@24-212-228-244.cable.teksavvy.com> has joined #yocto09:00
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto09:03
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has joined #yocto09:03
*** fbre <fbre!91fdde45@> has quit IRC09:09
*** sstiller <sstiller!~sstiller@p200300f07f13f9014137f624ecf6b07a.dip0.t-ipconnect.de> has joined #yocto09:15
wertigonptsneves: Did a second recon of the SDK rootfs, it appears I can cut most of it down by *not* providing qemu in the SDK09:19
wertigonFor some reason the mingw SDK provides Qemu to *all* thinkable architectures and each Qemu binary is 100 MB09:19
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto09:20
ptsnevesgreat. I can tell you from experience you can make very very slim sdks but then you need to manually add glibc and stlibc++ cross canadian compiler etc. Regardless, what is the current size you have now?09:20
wertigonSo that's roughly 26*100MB and I feel like that is a LOT of wasted space ^^;09:21
wertigonCurrent SDK size unwrapped:09:21
wertigon6.5G according to du -hs09:22
ptsneveshuge. I do not know what are your dependencies but that seems massive for one target09:22
wertigonYeah, definitely09:22
wertigon2.3 GB is qemu binaries09:23
wertigonThen of course Windows binaries are inefficient09:23
ptsnevesi would say 100MB is about what should be expected09:23
ptsnevesyeah, it could be that there is a static linking of the windows runtime and this makes binares big09:23
wertigonAye, that sounds more in line09:23
wertigonIt is not unusual for BSPs to be several GB in size on Windows09:28
wertigonAnd here BSP is roughly another 2 GB09:28
rburtonshould be trivial to change the nativesdk qemu to build just the target arch09:29
rburtonqemu-native builds all arches because then it can be built once09:29
wertigonYeah, I think I should build a Linux SDK and find out the differences09:29
*** micka <micka!~micka@reverse-75.fdn.fr> has quit IRC09:37
*** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto09:42
*** rob_w_ <rob_w_!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto09:49
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-gfnzclsgwcrefetp> has joined #yocto10:14
RPzeddii: looks like we have a kernel issue with 3.2 M3 - beaglebone doesn't boot :(10:20
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has quit IRC10:29
RPI think M3 rc1 is bad enough we'll need an rc210:30
*** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC10:30
*** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto10:33
*** amboar <amboar!~amboar@ozlabs.org> has joined #yocto10:39
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC10:41
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto10:42
amboarwe're hitting https://github.com/systemd/systemd/issues/16878 with systemd 246.2 in openbmc10:43
amboarthis is fixed by patches in 246.410:43
amboarcan it be bumped? I can send a patch, just trying to figure out where10:44
RPamboar: which release is that in? We do take stable updates for components10:48
amboarah, I think we're on dunfell?10:51
amboarRP: dunfell10:52
RPamboar: that should be acceptable10:52
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has joined #yocto10:55
RPsakoman: ^^^10:55
*** hpsy <hpsy!~hpsy@> has joined #yocto10:56
qschulzdunfell is 244.3?10:57
qschulzmaster is 246.210:57
qschulzaccording to http://layers.openembedded.org/layerindex/recipe/122137/10:58
amboarah, maybe we're somewhere on master then10:58
amboarmy unscientific check was grepping for dunfell10:58
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC10:59
amboarqschulz: ah, that "Other Branches" section is great11:00
qschulzamboar: yeah that's an awesome feature!11:00
qschulzamboar: so if RP says it's fine for backporting on dunfell, it probably is fine for master?11:00
amboarright; I'd hope so11:00
amboarI'd probably skip the backport11:01
amboarthe bug was introduced in 24611:01
amboar245 doesn't have the issue11:01
RPyes, that uprev would be great for master11:02
pevHm, just got a new machine and installed with Ubuntu 20.04 and dunfell. Did a couple of full core-image-minimal builds for qemuarm and qemuarmv5. qemuarm seems to work but v5 I noticed that ubuntu spots a bunch of crashes during build and the resultant armv5 doesn't appear to run. Is that a known issue?11:04
RPpev: we've don't test v5 anymore. It should work and this is the first time I've seen it reported that it doesn't11:09
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC11:14
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto11:16
*** Bunio_FH <Bunio_FH!~bunio@> has joined #yocto11:17
*** foo59 <foo59!55dd880c@c136-12.icpnet.pl> has joined #yocto11:20
pevRP: Ah, OK. I'll see if I can work out what's going on easily. Just trying to do a parallel Debian 10 install on the same machine as I was using that previously with no errors that I was aware of...11:21
*** mort is now known as mortbot11:24
*** mortbot is now known as mort11:24
*** berton <berton!~berton@> has joined #yocto11:42
*** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC11:53
*** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto11:54
*** dmation <dmation!~dmation@> has joined #yocto11:59
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has quit IRC11:59
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has joined #yocto11:59
*** foo59 <foo59!55dd880c@c136-12.icpnet.pl> has quit IRC12:02
*** cengiz_io <cengiz_io!~cengiz_io@> has quit IRC12:20
*** cengiz_io <cengiz_io!~cengiz_io@> has joined #yocto12:21
zeddiiRP: have we pinged Kevin @ WindRiver yet ? Some kernel merge may have caused it, but I don't have the h/w here to try.12:36
*** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC12:36
*** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto12:39
zeddiiRP, actually Kevin has a patch this morning: [kernel-meta yocto-5.8&master] beaglebone: Switch to sdhci-omap driver12:39
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC12:41
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto12:41
*** Bunio_FH <Bunio_FH!~bunio@> has quit IRC12:42
RPzeddii: ah, hopefully we can get that merged, rebuilt and get another test...12:43
RPseebs: around?12:44
*** rcw <rcw!~rcw@> has joined #yocto12:44
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto12:44
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto12:46
zeddiiRP: yep, merging now, will send the bumps in the next few mins.12:47
RPzeddii: thanks. I also filed a bug about an x86 backtrace that looked problematic12:48
*** rizzitello <rizzitello!~quassel@> has joined #yocto13:02
dleppichHey guys, is it a good idea to write a recipe based on a git repository or should I better grab the sources directly from a tarball? The problem I see with git is that it is not version stable (or am I missing an option to set a specific commit / tag / branch?).13:03
rburtonset SRCREV to the specific SHA13:03
rburtoneither is good, neither is 'better'13:03
*** C-o-r-E <C-o-r-E!~corey@modemcable149.12-178-173.mc.videotron.ca> has quit IRC13:03
rburtonsome tarballs are easier to build than git as there may be files in the tarballs which you need more tools to rebuild from git13:04
*** C-o-r-E <C-o-r-E!~corey@modemcable069.166-70-69.static.videotron.ca> has joined #yocto13:04
rburtonand tarballs can be cached/mirrored more easily13:04
dleppichk, thanks13:05
*** rizzitello <rizzitello!~quassel@> has quit IRC13:06
*** camus1 <camus1!~Instantbi@> has joined #yocto13:06
zeddiiif you think the recipe will ever need to be source debugged locally, or uprev'd / patched frequently, git is much better imho.13:07
*** kaspter <kaspter!~Instantbi@> has quit IRC13:07
*** camus1 is now known as kaspter13:07
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto13:08
ptsnevesbig amount of git repositories kills parsing. Was just in a meeting where multiple teams said it got so bad they started having pre-mirror of the git as a form of cache13:09
dleppichI just started learning yocto and tried to write a recipe for htop. Whatever I try, I did not get it working. I also googled for a recipe for htop and found one in the meta-openembedded layer (which is not working for me as well). Can someone please help me figure out what to do to get my recipe working / explain why it is not working?13:10
ptsnevesdleppich can you post a paste of the error you have when using the meta-openembedded?13:12
dleppichI just tried and now everything is in flames... I need to check what I messed up with13:15
ptsnevesHey guys. When i run -c clean on a recipe, and if the make clean target is broken we cannot clean the directory ever13:15
ptsneveswe are stuck. -c cleanall is affected as well. Has anybody hit this issue?13:16
dleppichI had this issue as well. I just removed everything inside of workspace manually, but I'm quite sure this is not the way to go13:17
zeddiiptsneves: did you try setting CLEANBROKEN="1" in the recipe ?13:17
zeddiior alternatively, carry a patch that fixes the clean target in the Makefiles (and send it to the upstream project of course).13:17
ptsnevesThe cleanbroken is a good tip, althoug i am fixing the Makefile indeed. Regardless the situation of an unrecoverable error even with cleanall is very not intuitive13:19
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.> has quit IRC13:19
*** Sandrita83 <Sandrita83!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto13:19
dleppichI have a reproducible htop problem now :) I created a new recipe with "devtool add htop https://github.com/htop-dev/htop". That worked. Trying to build it fails: "bitbake htop". Output: https://pastebin.com/e6EZT95M13:20
ptsneveschecking for addnwstr in -lncursesw6... nochecking for addnwstr in -lncursesw... nochecking for addnwstr in -lncurses... noconfigure: error: You may want to use --disable-unicode or install libncursesw.13:22
paulbarkerdleppich: I recommend adding the meta-openembedded layer and using the htop recipe from there13:22
ptsnevesnotice that error13:22
dleppichpaulbarker: I think in a solution oriented approach I would do that, but my goal is to learn yocto and to understand this issue, in order to learn to fix it.13:23
ptsneveseither you add the dependency to libncurses or you disable it with build flags. Most likely adding DEPENDS += "ncurses" is what you need, as i do not imagine htop without ncurses :)13:23
rburtonptsneves: only if you use AUTOREV13:23
* paulbarker dleppich: Ah in that case making your own recipe is definitely the way to go!13:23
rburton(re git repos causing build slowdown)13:23
qschulzdleppich: though IIRC we highly discourage people to get tarball from github.. basically, tags and releases can be "redone" meaning your source has changed without you knowing (or requiring some work on your end). Though it's still possible if someone rebases master/main branch, it is pretty well-known this is a very bad practice13:24
* paulbarker always forgets that irccloud posts messages differently when you press ctrl+enter13:24
dleppichptsneves: I added the DEPENDS already on my own (I forgot the +). Still, in both cases it produces the same error (or it seems to be the same)13:25
qschulzdleppich: do not build on arch please :)13:27
ptsnevesdleppich then try EXTRA_OECONF += "--disable-unicode", although this is a hunch. I have never looked at the htop build system. I would suggest that you have a look at the recipe of meta-openembedded and cross check with what you understand and not. You can ask here what does not make sense for you13:27
*** dlan <dlan!~dennis@> has joined #yocto13:27
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto13:27
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has quit IRC13:28
qschulzdleppich: https://docs.yoctoproject.org/ref-manual/ref-system-requirements.html?highlight=ubuntu#supported-linux-distributions13:28
dleppichqschulz: I know, but this issue doesn't seem to be OS related to me, or am I wrong?13:29
qschulzmake sure that all packages defined in the sections below are installed on your host as well. There is almost no chance this has an impact on your error but it might be an issue in the long term13:29
dleppichI installed all packages listed there13:30
dleppichAnd I have no troubles using packages which are shipped in the meta layers already included. I got first issues when writing / generating my own recipes13:30
ptsneves@qschultz i do not think this has anything to do with the environment. This is not a native package and the libraries missing are for target.13:30
qschulzptsneves: 1) you can use autocompletion for any nick :D 2) yes, still.. arch is known to break/change often and is definitely not supported. So staying within tested boundaries is better when someone's starting their Yocto journey :)13:31
dleppichptsneves: I tried this "EXTRA_OECONF += ..."-magic, but still getting an error: https://pastebin.com/jfHQ5U3D13:32
dleppichI saw that there is a CROPS (or spelled similar) docker container to use yocto inside of it. Is that a solution that is usable in daily use?13:32
rburtondoes anyone still use ccache or is everyone using icecream now?13:34
ptsnevesdleppich so definitely for some reason the libncurses is not being considered by the htop build system.13:35
rburtonvmeson: it looks like WR still at least test ccache builds.  do you know of anyone actually using it?13:35
ptsnevesmy employer does13:36
ptsnevesrburton my employer does13:37
ptsnevesdleppich are you inheriting autotools. Also could you pastebin the recipe?13:37
dleppichyep: https://pastebin.com/g72LwkjC13:39
dleppichI just added "ncurses" to DEPENDS (the other was auto generated by devtool) and the "--disable-unicode" to EXTRA_OECONF. The rest was generated13:40
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC13:41
ptsnevesdleppich as expected there is a quirk to get htop to build. You need a patch so that htop build system uses pkgconfig properly13:45
ptsnevesthen it shall detect libncurses properly13:46
dleppichI also tried that with my dockerized yocto-setup: https://pastebin.com/EnPyPUT (same issue)13:49
dleppichptsneves: This patch doesn't work for me as well (or I did it wrong): https://pastebin.com/StTDpcdL13:49
ptsnevesok then i would need to try it out localy13:50
ptsneveswhich i can do only a bit later13:50
ptsnevesnothing seems wrong on your part though13:50
dleppichThat's the exact error I get: https://pastebin.com/riaxfYRY13:50
dleppichptsneves: Okay, that makes me feel a little bit less dumb. Thanks so far!13:51
qschulzdleppich: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/htop/files/0001-Use-pkg-config.patch13:51
dleppichqschulz, I just tried that without success :/13:52
qschulzdleppich: how did you "try"?13:52
dleppichI added the patch to a newly created "files" folder next to the .bb file and added this file to the SRC_URI variable (https://pastebin.com/StTDpcdL)13:53
*** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has joined #yocto13:55
dleppichI'm sorry to have that many questions and I hope I can give some help back one day in the future.. But, I have another and maybe simpler issue with a self created recipe for an ncurses based tetris game I found on github. A part was generated by "devtool" and I already figured out a way to fix compilation problems due to "bad git usage". The issue is, that my recipe does not create an executable "tetris" in the final image. This is my recipe: https://14:00
rburtonyour install lines are almost right, bindir not base_bindir and install-d (make directory) before you put something into it14:01
rburtonso remove base_ and swap those two lines around14:01
dleppichI got these lines from another package, but have no clue what they mean. Could you please explain them to me or give me a hint where I can find some good reference?14:02
rburton'man install' :)14:03
rburtoninstall -d is basically mkdir14:03
rburtonthe other line is a glorified cp14:03
dleppich'man install' says: "treat all arguments as directory names; create all components of the specified directories".. I would never guess that this is something similar to mkdir14:05
*** rizzitello <rizzitello!~quassel@> has joined #yocto14:06
dleppichWhat are ${D} ${S} and ${bindir}. I would guess that ${bindir} might be the directory of the future "bin", like /usr/bin. ${S} could be the source directory. Am I correct this far? What is ${D}14:06
paulbarkerdleppich: You can find these in the reference manual, e.g. https://www.yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#var-D14:08
dleppichpaulbarker, thanks14:08
dleppichrburton, I think I got your changes and explanations, but the "bitbake ncurses-tetris" is still failing: https://pastebin.com/ttaJ4Z9614:11
dleppichThis is my current recipe: https://pastebin.com/M4401M4014:11
rburtonfor an executable you want 0755, to be executable14:13
dleppichTrue, but this does not solve the error above14:14
eduardashello, which bitbake variable contains just the cross-compilation prefix for toolchain?14:17
eduardasI am trying to cross-compile open-plc-utils with the projects Makefile14:18
eduardaswhich takes the variable CROSS for this purpose14:18
eduardasOpenWRT has TARGET_CROSS for this14:19
eduardascan not find a Yocto equivalent14:19
wertigonHuh, strange14:21
wertigonI look at the qemu architectures generated14:21
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has joined #yocto14:21
wertigonand all of them are in... EXCEPT the one I use, arm6414:22
paulbarkereduardas: Does the Makefile ignore $CC?14:22
wertigonI want the opposite to be true, I want arm64 qemu if anything14:22
wertigonwhen doing populate_sdk14:22
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC14:24
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto14:25
eduardaspaulbarker: no, but I think it ignores LD ,because I've grepped LD=$(CROSS)ld14:25
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto14:25
paulbarkereduardas: I'd recommend patching the makefile then, Yocto usually sets CC and LD to include some required flags if I remember correctly14:26
paulbarkerYou can examine the run.do_compile file to see what is set14:28
eduardaspaulbarker: ok, but I'd still like to know whether there is a bitbake variable that contains just the toolchain prefix14:28
*** rob_w_ <rob_w_!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC14:28
eduardaspaulbarker: I've already looked at it, could not find it14:28
paulbarkereduardas: I'm unsure of one myself, other than searching the reference manual14:28
*** stacktrust <stacktrust!~stacktrus@cpe-67-250-48-90.nyc.res.rr.com> has quit IRC14:29
paulbarkerMaybe https://www.yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#var-CROSS_COMPILE ?14:30
*** stacktrust <stacktrust!~stacktrus@cpe-67-250-48-90.nyc.res.rr.com> has joined #yocto14:31
eduardaspaulbarker: thank you14:31
ptsneveseduardas beware The OpenEmbedded build system sets the CROSS_COMPILE variable only in certain contexts (e.g. when building for kernel and kernel module recipes).14:32
ptsnevesyou should use TARGET_SYS instead as it is guaranteed to exist everywhere14:33
eduardasstill does not work, though... not sure which flag is improper here14:34
eduardasptsneves: seems TARGET_PREFIX is set correctly in my recipe14:36
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto14:38
ptsneveshonestly eduardas it seems your compiler is defective14:38
ptsnevesdid you build it in yocto14:38
eduardasptsneves: yes, this is latest stable yocto release14:40
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC14:41
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto14:42
ptsnevesone funny thing why is your version %14:43
ptsnevesnot that it is the root cause14:43
*** koty0f <koty0f!~filip@> has quit IRC14:44
ptsneveseduardas can you print the spec by running the ${CC} --version14:45
eduardasptsneves: bitbake -c devshell does not work for this recipe for some reason14:47
eduardasptsneves: not sure how I'm supposed to get into the compilation environment properly otherwise14:47
ptsnevesyou just find the compiler in the sysroot14:47
eduardasptsneves: oh, ok... a moment14:47
ptsnevesor you can just prepend bbwarn $(${CC} --version)14:48
paulbarkereduardas: Have you patched the Makefile so it doesn't override CC, LD, etc?14:48
eduardasptsneves: arm-poky-linux-gnueabi-gcc (GCC) 9.3.014:49
ptsnevessorry only -v14:49
*** jobroe <jobroe!~manjaro-u@p579eb9ab.dip0.t-ipconnect.de> has quit IRC14:50
ptsnevesby the way what recipe is failing? a bad spec would fail very early14:50
eduardaspaulbarker: no, I haven't yet, since passing the prefix via CROSS seemed to work for OpenWRT... still wanted to try this approach.. will patch if nothing else works14:50
*** rizzitello <rizzitello!~quassel@> has quit IRC14:51
eduardasptsneves: https://pastebin.com/rq22xM3T14:51
*** xtron1 <xtron1!~xtron@> has joined #yocto14:51
*** rizzitello <rizzitello!~quassel@> has joined #yocto14:52
eduardasptsneves: GCC output you asked for: https://pastebin.com/dSdbXJin14:52
*** d32 <d32!2ef3c527@> has joined #yocto14:54
armpitYPTM: armpit is on14:54
JaMaYPTM: JaMa is on14:56
*** sno <sno!~sno@p5b25b0d4.dip0.t-ipconnect.de> has quit IRC14:57
*** sno <sno!~sno@p5b25b0d4.dip0.t-ipconnect.de> has joined #yocto14:59
smurrayYPTM: Scott Murray is on15:00
qschulzdleppich: are you sure you saved and recompiled with the saved recipe? because your FILES is commented but it is incorrect15:01
qschulzand the default FILES_${PN} will just work in your case15:01
*** rizzitello <rizzitello!~quassel@> has quit IRC15:02
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC15:03
*** eduardas <eduardas!~eduardas@> has quit IRC15:05
d32I'm trying to solve "cfg80211: failed to load regulatory.db". I'm building core-image-minimal for linux-fslc 5.0.7. Looking at wireless-regdb_2019.06.03.bb this seems to be the file that installs the required files in /lib/firmware and I'm thinking this might solve the failure. Can someone tell me how to get my project to use and build this file?15:06
*** rizzitello <rizzitello!~quassel@> has joined #yocto15:06
*** kaspter <kaspter!~Instantbi@> has quit IRC15:07
*** kaspter <kaspter!~Instantbi@> has joined #yocto15:07
*** rizzitello <rizzitello!~quassel@> has quit IRC15:08
*** rizzitello <rizzitello!~quassel@> has joined #yocto15:10
qschulzd32: create a new image recipe based on core-image-minimal if you want and add this package to IMAGE_INSTALL or whatever the name of the variable for including packages in core-image-minimal is15:12
qschulzd32: highly suggesting taking the time to follow the Live coding sessions on YoctoProject Youtube channel15:13
dleppichqschulz, yes, I'm using vim and when reopening the recipe it is in the state I posted: https://pastebin.com/M4401M40.15:14
dleppichBut I found the issue: I forgot a $ in the install line just before {bindir}15:14
dleppichNow I'm fighting another issue. The Makefile is unable to cross-compile the game. I took a look at it and it was using 'g++' directly. I replaced it with $(CC) and created a patch for this change, which did not succeed.15:15
dleppichI wanted to try to cross compile it by hand to check what I am missing, but I don't know where the cross compiler is located, can you help me out?15:16
tlwoernerpaulbarker: what's the tool called (license scanning)?15:17
paulbarkertlwoerner: scancode-tk class in meta-spdxscanner15:17
tlwoernerpaulbarker: thanks!15:18
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto15:18
dleppichAnd a general question: I wrote a patch file to (hopefully but still not working correctly) make the Makefile cross compile. Is there a way I can check if my patch get applied in bitbake?15:20
rburtonread log.do_patch15:21
qschulzdleppich: UGH the dollar sign :D15:22
dleppichWhere can I find this?15:22
dleppichqschuld: Yeah, I only found it by accident :D15:22
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:23
qschulzdleppich: I suspect CXXFLAGS/LDFLAGS are also overriden? or if multiple makefile/cmake are in play, g++ is hardcoded in other places15:23
d32qschulz: Thanks, yes I have seen most of the live coding sessions and they have been very informative for me. What I did until now is IMAGE_INSTALL_append = " wireless-regdb-static" in core-image-minimal.bbappend. But I realize now I wrote it in my recipes-core folder, which probably should be recipes-connectivity?15:23
qschulzdleppich: CXX and not CC I think also15:23
dleppichI tried it with CXX as well15:24
*** stacktrust <stacktrust!~stacktrus@cpe-67-250-48-90.nyc.res.rr.com> has quit IRC15:24
qschulzd32: does not matter. check your bbappend is found by running bitbake-layers show-appends15:24
qschulzif it's there, it's used :)15:24
dleppichqschulz: In both cases $(CC) and $(CXX) the log file tells me, that g++ is being used: "g++ -c main.cpp -lncurses ..."15:25
dleppichWhere does this information come from? I do not set either of these variables in the makefile15:26
*** chris_ber <chris_ber!~quassel@> has quit IRC15:26
rburton<insert rant about how makefiles are hard to write correctly here>15:26
qschulzdleppich: bitbake <recipe> -e | grep -e "^SRC_URI="15:26
qschulzdo you have your patch in there?15:26
qschulzdoes your patch ends with ".patch" or ".diff"?15:27
dleppichrburton: Sorry for being too bad :/15:27
qschulzdleppich: oh no, he was complaining about the original author :)15:27
rburtonit's not your makefile! :)15:27
qschulzdleppich: you see what all people have to go through :)15:27
dleppichrburton: But I still don't know how to write it better :P15:28
dleppichgrep output is: SRC_URI="file://0001-Make-makefile-crosscompile.patch"15:28
qschulzdleppich: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n519 for CC and CXX setting15:28
qschulzdleppich: well... you kinda have an issue there, where's the git repo in that variable :D?15:28
qschulzyou probably forgot += in SRC_URI15:28
qschulzdleppich: that's the point of rburton, it's hard to write a good makefile. People here usually recommend cmake or meson15:29
dleppichThis is my recipe: https://controlc.com/fafa05f715:30
dleppichI have multiline SRC_URI15:30
dleppichI seem to have a talent on finding "easy" tasks to get into Yocto :D15:30
qschulzd32: do you actually have an issue? because what you did seem correct to me15:31
qschulzdleppich: why do you not have the git repo in there then?15:31
qschulz(there = SRC_URI)15:31
dleppichI have no clue.. The git repo is in the recipe file15:32
qschulzdleppich: you don't need your FILES_${PN} BTW15:32
dleppichTrue, on my way finding out the $ bug, I forgot to comment it out again15:33
qschulzdleppich: also... are you SURE that you're reading the log.do_compile **symlink**? because it'll keep the old logs as well15:33
dleppichqschulz: Yes, I'm following the symlink15:34
*** tgamblin <tgamblin!~tgamblin@2607:fea8:e2e1:1110::52bc> has joined #yocto15:34
*** stacktrust <stacktrust!~stacktrus@cpe-67-250-48-90.nyc.res.rr.com> has joined #yocto15:34
qschulzdleppich: are you using devtool build tetris? or bitbake tetris?15:35
dleppichbitbake ncurses-tetris15:35
qschulzalso, to check if the patch is applied, check first in log.do_patch, and to be extra super sure, you can go in the build directory of this recipe15:35
dleppichI did not know there is a devtool build.. But after trying it out I get the same issue: "file format not recognized"15:36
qschulzdleppich: so... you did devtool add <> for the recipe right?15:36
dleppichFull error: https://controlc.com/08a677a015:36
dleppichYes, 'devtool add ncurses-tetris <GIT_REPO>'15:37
qschulzdleppich: probably because it's x86 and not arm15:37
qschulzdleppich: mmmm where did you put your patch?15:37
dleppichin 'workspace/recipes/ncurses-tetris/files15:37
dleppichI set the machine to "qemuarm" in the local.conf15:38
qschulzmmmmm... not sure about devtool15:38
qschulzhandling patches directly15:38
*** dmation <dmation!~dmation@> has quit IRC15:38
qschulzbasically, when you're using devtool, modify the sources directly15:38
qschulzso in workspace/sources/ncruses-tetris15:38
dleppichThis is the output of 'bitbake ncurses-tetris': https://controlc.com/313b17ef15:39
qschulzmodify whatever you need, there. Commit for every change. Once finished, devtool finish and it'll create patches fro you and should add them to SRC_URI IIRC15:39
qschulzdleppich: it's fine, I just wanted to make sure you weren't forcing a task of the recipe to be run (-c task)15:40
dleppichI have no log.do_patch btw..15:40
qschulzdleppich: well, that's an issue :)15:40
dleppichDo I have to somewhere register the patch file? Because I just created it in a newly created 'files' folder and added it to the SRC_URI variable (which seem not to be updated correctly)15:41
qschulzdleppich: I'm not sure devtool handles it correctly that's my point15:41
qschulzaaaaand... technically it's a non-issue15:41
qschulzbecause devtool is made so that you modify the source code directly, then you commit those changes (in devtool workspace), then devtool finish15:42
dleppichOkay, I just saw devtool today for the first time and wasn't aware of it's capabilities. I thought I had to write the patch by hand with the diff tool15:42
qschulzdleppich: I know patches and other files (not tarball, git repos, etc...) are installed into workspace/sources/<recipe>/oe-local-files. So I don't know really if your thing works15:42
armpitYPTM: is over15:43
*** xtron1 <xtron1!~xtron@> has quit IRC15:43
qschulzdleppich: nope :) obviously not a perfect tool, but very helpful :)15:43
ecdhedleppich: you can go manually generate patches too (I was unaware that devtool would do it for you and had a lengthy manual process before)15:43
qschulzdleppich: sorry that wasn't clear.. when doing devtool modify <recipe>, if the recipe has patches it puts them into workspace/sources/<recipe>/oe-local-files15:44
dleppichI checked out the 'oe-workdir' symlink and it points to a directory where my patch is also inside (I never put it in there)15:44
qschulzecdhe: how do you make your devtool'ed recipe use those manually crafted patches then?15:44
qschulzdleppich: not workdir, oe-local-files15:44
dleppichI have no 'oe-local-files'15:45
qschulzdleppich: anyway, I would give up on making devtool take patches :)15:45
*** xtron <xtron!~xtron@> has joined #yocto15:45
qschulzdleppich: AH! I think devtool does not execute the patch step once you have the sources!15:46
dleppichqschulz: Kk ^^ But how would you patch "normally"?15:46
*** xtron <xtron!~xtron@> has quit IRC15:46
dleppichIs there a command to clear the sources or do I just 'rm -rf' them?15:46
qschulzbecause to show you the sources, it fetches them and applies the patches on top in the workspace15:46
qschulzdleppich: either you modify manually in workspace/sources/<recipe>, until you're happy15:46
qschulzthose changes will be taken even without committing15:47
*** xtron <xtron!~xtron@> has joined #yocto15:47
qschulz(provided your recipe is dispalyed when you do devtool status)15:47
qschulzthen you can commit and run devtool finish when you're happy15:47
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC15:47
*** xtron <xtron!~xtron@> has quit IRC15:48
dleppichOkay, so what do I have to do to clear my broken status and start it again? Without doing everything manually and without starting a new project?15:48
*** xtron <xtron!~xtron@> has joined #yocto15:48
qschulzhalstead: there is a missing redirect from http to https on docs.yoctoproject.org if that was not on prupose :)15:49
qschulzhalstead: (hi /me waves)15:49
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC15:49
qschulzdleppich: you're good, just remove from SRC_URI your patch, re-apply it to the sources in the workspace, and remove the file from workspace/recipes/)15:49
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto15:49
qschulzdleppich: AH! apparently one could do devtool sync!15:50
qschulz(reading the docs help :D)15:50
qschulzdleppich: FYI: https://docs.yoctoproject.org/ref-manual/ref-devtool-reference.html15:51
qschulz(maybe devtool sync would pick up and apply your patch)15:52
dleppichdevtool sync was not working for me (or I have used it wrong). For now I removed my patch from the recipe and deleted the files directory15:53
dleppichNow I will try to apply the patch in the sources and use devtool to do the magic15:53
ecdheqschulz: I made devtool put the code into the workspace, edit the code, and build to test my edit.  If my edit built and had desireable behavior, I committed it as a patch, then used `git format-patch' to generate a patch file, which I then copy to meta-my-layer/recipes-kernel/linux/files/, which is on my FILESEXTRAPATHS_prepend; then I can add the the patches by adding them to my SRC_URI.15:53
*** dev1990 <dev1990!~dev@dynamic-81-168-186-230.ssp.dialog.net.pl> has quit IRC15:54
qschulzecdhe: exactly what I did before I discovered devtool finish :) (still doing it "your" way sometimes though :) )15:55
qschulzdleppich: I barely use devtool honestly so I discover as mucha s you do15:55
dleppichqschulz: Sorry, it still doesn't work. I now directly edited the Makefile in workdir/sources/ncurses-tetris from 'g++' to '$(CXX)'15:56
RPJPEW: I assume you'll send a v2 of the sshkey systemd patch? (looked good to me with the tweak, thanks)15:56
dleppich'devtool status' and 'devtool finish' do nothing15:56
JPEWRP: Will do15:57
qschulzdleppich: workspace/sources15:57
dleppichqschulz: What do you mean?15:58
*** xtron <xtron!~xtron@> has quit IRC15:59
*** xtron <xtron!~xtron@> has joined #yocto15:59
qschulzdleppich: it's workspace/sources/ncurses-tetris, not workdir16:00
d32qschulz: I have re-checked, and found out my mistake. I tried to use the wireless-regdb-static in core-image-minmal.bbappend. But then I got an error mesage saying nothing RPROVIDES 'wireless-regdb-static' After some googling it looked like core-image-base would have more chance of succes so I built with that. As a result I did not get an error16:00
d32message, but I realize now I did not have a core-image-base.bbappend...so it never got into the image. So my new question is how to resolve the RPROVIDES error.16:00
dleppichqschulz: Yup, typo ^^16:00
qschulzdleppich:  but if devtool status returns nothing... not great, because it does for me16:00
dleppichI think I will purge my current progress and start over with 'devtool add'16:01
qschulzd32: which yocto release are you using?16:02
qschulzdleppich: devtool modify ncurses-tetris -n otherwise should put it back into your devtool workspace layer16:02
d32qschulz: 2.7.416:03
qschulzd32: yeah, does not exist in 2.7.416:04
qschulzd32: you need to add meta-openembedded/meta-networking to your bblayers.conf16:06
qschulzd32: http://layers.openembedded.org/layerindex/recipe/100831/16:06
d32qschulz: OK thanks a lot I will try it!16:08
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC16:08
dleppichqschulz: Not that I get it wrong this time. I have a clean recipe created with 'devtool add'. I added the do_configure and do_install things I had before. Now I get the file format error16:08
dleppichqschulz: Now I go into workspace/sources/tetris/ (I renamed it) and edit Makefile from 'g++' to '$(CXX)', right?16:08
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto16:08
*** dleppich_ <dleppich_!~dleppich@> has joined #yocto16:09
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto16:09
dleppich_hmm, weird reconnect16:09
qschulzdleppich_: yeah that should help16:09
qschulzprobably  still missing CXXFLAGS and LDFLAGS but that should put you in the right direction16:09
*** fl0v0 <fl0v0!~fvo@> has quit IRC16:10
dleppich_Now that I edited Makefile, 'devtool status' is just listing me the 'tetris' recipe16:10
dleppich_What to do next?16:10
qschulzdevtool build tetris or bitbake tetris?16:11
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC16:12
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC16:12
*** dleppich <dleppich!~dleppich@> has quit IRC16:12
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto16:12
dleppich_qschulz: both crash on do_package with the 'file format not recognized' error16:13
*** w00die <w00die!~w00die@> has quit IRC16:14
*** lxc6 <lxc6!d9d0c05b@217-208-192-91-no98.tbcn.telia.com> has joined #yocto16:14
qschulzdleppich_: they are doing the same thing so only calling one is fine16:14
*** w00die <w00die!~w00die@> has joined #yocto16:15
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto16:15
lxc6is there a variable containing the directory name from where oe-init-build-env was invoked?16:16
dleppich_As it is not working now and also not applying the patch (there is no do_patch log file and do_compile shows that 'g++' was being used the first time, now telling 'tetris is up to date'), what do I have to do next?16:16
paulbarkerlxc6: I don't believe so. What do you need it for?16:16
lxc6paulbarker need to invoke a shell script from a bitbake recipe.16:17
qschulzlxc6: add this shell script to SRC_URI of the recipe?16:18
qschulzdleppich_: worked for me /me shrugs16:20
*** khem <khem!~khem@unaffiliated/khem> has quit IRC16:21
qschulzdleppich_: ahah, wait... forgot the do-install task16:21
lxc6qschulz the SRC_URI is described from the bb recipe source dir? how do you mean it helps med to trigger that shell script at a certain call point?16:22
qschulzdleppich_: yeah.. works for me. You probably are not modifying the correct sources?16:23
dleppich_I modified 'workspace/sources/tetris/Makefile'16:23
*** ptsneves <ptsneves!b0dd7824@> has quit IRC16:24
qschulzdleppich_: well, I did too... and it compiles16:24
*** mckoan is now known as mckoan|away16:25
qschulzdleppich_: tested on thud. I only added your do_install and do_configure to the devtool'ed recipe and modified the makefile, nothing else16:25
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC16:25
dleppich_qschulz: This is how my files look right now: https://controlc.com/4ece85c516:26
qschulzdleppich_: mmmm.... youi have run devtool finish once in the past right?16:26
qschulzcheck that's in nowhere in your layers outside of devtool workspace16:26
dleppich_how exactly do I invoke devtool finish?16:26
qschulzdleppich_: I do have rm -rf *.o instead of rm *.o tbf16:27
qschulzdleppich_: forget about devtool finish for now.16:28
dleppich_well, that shouldn't change anything, right?16:28
qschulzdleppich_: also, don't take tetris binary from ${S} that'll bite you later, you should not specify anything16:28
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto16:28
qschulzdleppich_: try and we'll see :)16:29
dleppich_qschulz: I mean, if I 'rm *.o' or 'rm -rf *.o'. These are only files without any directories.. But I'll try it16:29
dleppich_Now it worked..16:30
dleppich_qschulz: When I remove the '-rf', it works as well.. Somehow this change in the recipe have forced bitbake to update something16:31
qschulzdleppich_: no it does not "work as well"16:31
qschulzbecause your .o files are not removed somehow?16:32
qschulzin poky, everyone is doing `rm -f`16:32
dleppich_Okay, so the force flag was important..16:32
qschulzdleppich_: apparently, no fucking idea why though16:32
qschulzmaybe someone knows but I don't :)16:32
dleppich_qschulz: Anyway.. my qemuarm image did correctly build with bitbake and I just ran tetris inside it <316:33
dleppich_qschulz: Thanks so much for helping me for so long, you are my personal hero of today!16:33
dleppich_After all this struggle, I should give this tetris guy a merge request with some changes to his makefile :D16:33
*** xtron1 <xtron1!~xtron@> has joined #yocto16:34
qschulzdleppich_: our pleasure :) have fun with yocto16:34
dleppich_qschulz: Thanks! I have really learned a lot today! Bye :)16:35
*** dleppich_ <dleppich_!~dleppich@> has quit IRC16:35
*** zandrey <zandrey!~zandrey@> has quit IRC16:36
marexqschulz: what is it with the rm -f ?16:36
*** xtron <xtron!~xtron@> has quit IRC16:37
marexqschulz: if you do rm *.o and there are no .o files, rm will return error code , if you do rm -f *.o and there are no .o files, it will return 0 (success)16:37
*** dev1990 <dev1990!~dev@dynamic-81-168-186-230.ssp.dialog.net.pl> has joined #yocto16:53
*** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-060.hsi5.kabel-badenwuerttemberg.de> has quit IRC16:58
*** dev1990 <dev1990!~dev@dynamic-81-168-186-230.ssp.dialog.net.pl> has quit IRC17:10
*** rizzitello <rizzitello!~quassel@> has quit IRC17:11
kiwi_29hello. I have a software which is hosted on git. When I clone it ...it has 3 directories. Each has a different software to compile using configure, make and make install . I am sort of confused, how to implement a single recipe to compile source from all three directories. Any ideas or links to recipes which does something like this?17:13
*** Yatekii <Yatekii!~yatekii@huesser.dev> has joined #yocto17:13
*** dev1990 <dev1990!~dev@dynamic-81-168-186-230.ssp.dialog.net.pl> has joined #yocto17:15
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto17:18
marexkiwi_29: add a top-level makefile or split your repo (that's likely the proper approach)17:23
kiwi_29It is an opensource project, I cannot change it :(   marex17:23
paulbarkerkiwi_29: May be easier to just write 3 recipes, use a common .inc file to specify SRC_URI and SRCREV17:24
marexkiwi_29: it is an open source project, so you should be able to change it :)17:25
kiwi_29Hi paulbarker ... many thanks .. I was veering towards that solutions ... I guess ..thats it then17:25
marexkiwi_29: what project is that ?17:25
kiwi_29marex ... true.. but there is no time to go through that cycle of submitting changes..and waiting for it to get approved ...also it is not a yocto compatible project ... as in I do not know if the maintainers want any yocto related changes17:27
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:28
*** manuel1985 <manuel1985!~manuel@> has left #yocto17:29
marexkiwi_29: you can track a local patch17:30
marexkiwi_29: might be better to fix the upstream, esp. if you ever plan to upgrade in the long run17:30
*** xtron1 <xtron1!~xtron@> has quit IRC17:31
kiwi_29is there a way to change environment variable S in recipe multiple times?17:40
kiwi_29in the shell version of do_<something> I could not change using S =   syntax17:40
zeddiino. but you don't need to.17:40
zeddiiit's just a variable, you can use it as reference point, or use ${WORKDIR}17:41
kiwi_29configure from autotools autotools_do_configure only uses path from S17:41
zeddiiyou may need to call the even lower functions directly.17:42
zeddiior just create three recipes :D all cloning that same repo.17:42
kiwi_29on it ;)17:42
zeddiiI've called the autotools functions directly in the past, but don't think I have any like that at the moment.17:43
zeddiibut many of the go recipes I maintain are invoking a bunch of builds in various source directories.17:43
zeddiiheh. I see paulbarker recommended the same thing :D17:44
zeddiiif your do_compile is python, you might be able to set the var, but I'm not sure how well it would work.17:45
zeddiiI quick grep shows that other recipes are mucking with it:17:45
zeddiimeta/recipes-multimedia/alsa/alsa-tools_1.2.2.bb:        dd.setVar("S", os.path.join(d.getVar("S"), subdir))17:46
zeddiiand in fact, that one is then invoking autotools17:46
zeddiiso have a closer look at that.17:46
marexwell, isnt there already a recipe for that project anyway ? check the layerindex first ?17:47
marexkiwi_29: ^17:47
lxc6If I define SRC_URI to a local file isn't that file supposed to be copied to $WORKDIR?17:47
kiwi_29thanks marex17:55
*** ptsneves <ptsneves!b0dd7824@> has joined #yocto17:58
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC18:01
*** sakoman <sakoman!~steve@> has joined #yocto18:01
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC18:02
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto18:02
*** sakoman <sakoman!~steve@> has quit IRC18:07
*** sakoman <sakoman!~steve@> has joined #yocto18:29
*** sakoman <sakoman!~steve@> has quit IRC18:40
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:41
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:41
*** NiksDev <NiksDev!~NiksDev@> has quit IRC18:44
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto18:44
*** sakoman <sakoman!~steve@> has joined #yocto18:48
*** dmoseley <dmoseley!~dmoseley@> has quit IRC18:53
*** sakoman <sakoman!~steve@> has quit IRC18:58
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto18:59
*** sakoman <sakoman!~steve@> has joined #yocto19:03
*** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:f19e:6519:4064:1cca> has quit IRC19:06
*** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:62e7:1c6c:fe39:b439> has joined #yocto19:07
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has quit IRC19:08
*** sakoman <sakoman!~steve@> has quit IRC19:09
*** georgem <georgem!~georgem@> has quit IRC19:12
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC19:15
*** georgem <georgem!~georgem@> has joined #yocto19:15
*** sstiller <sstiller!~sstiller@p200300f07f13f9014137f624ecf6b07a.dip0.t-ipconnect.de> has quit IRC19:22
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC19:27
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto19:27
*** sakoman <sakoman!~steve@> has joined #yocto19:32
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC19:32
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto19:44
*** tgamblin <tgamblin!~tgamblin@2607:fea8:e2e1:1110::52bc> has quit IRC19:44
*** NiksDev <NiksDev!~NiksDev@> has quit IRC20:00
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto20:00
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.> has quit IRC20:02
zeddiiCrofton|cloud: for the first time ever, I was able to boot a zcu102 image in qemu. does that count as a boot test :P20:02
*** kaspter <kaspter!~Instantbi@> has quit IRC20:05
*** camus1 <camus1!~Instantbi@> has joined #yocto20:05
*** camus1 is now known as kaspter20:08
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto20:14
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto20:21
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto20:35
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC20:44
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto20:49
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC20:56
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has joined #yocto20:58
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC21:00
Crofton|cloudHow long have you been there ....21:04
*** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC21:11
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has quit IRC21:12
*** berton <berton!~berton@> has quit IRC21:17
*** bsmerbeck <bsmerbeck!4a6132e0@pool-74-97-50-224.prvdri.fios.verizon.net> has joined #yocto21:22
bsmerbeckSo I'm scratching my head on this one. Trying to install a python package on my image, and use a systemd service that gets removed after first boot to run a setup of a postgresql database among other commands and functions. I install the package (psycopg2) by using ROOTFS_POSTPROCESS_COMMAND. It simply runs a `python3 setup.py install`. In the21:25
bsmerbeckinitscript (set to run after postgresql.service), the package is needed. Using `journalctl` the log shows that the module isn't recognized. HOWEVER, when I su to the user the systemd service runs as, and just do a simple `python3; import psycopg2`, it works without error. Any thoughts on why it's not recognized in the systemd service?21:25
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC21:28
*** bsmerbeck <bsmerbeck!4a6132e0@pool-74-97-50-224.prvdri.fios.verizon.net> has quit IRC21:35
*** wertigon <wertigon!~per@c-e961225c.021-396-7673741.bbcust.telenor.se> has quit IRC21:57
*** dagmcr <dagmcr!sid323878@gateway/web/irccloud.com/x-tvtcywbcxqyywjvn> has quit IRC22:04
*** ukembedded <ukembedded!sid304355@gateway/web/irccloud.com/x-wpwrpcrbfruwccux> has quit IRC22:04
*** rsalveti <rsalveti!uid117878@gateway/web/irccloud.com/x-svetjwmbwdypbltn> has quit IRC22:04
*** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/x-hsofequfhuqotzwe> has quit IRC22:04
*** ndec <ndec!sid219321@linaro/ndec> has quit IRC22:04
*** fancer <fancer!fancer@gateway/web/irccloud.com/x-nztgsvisgylzvqld> has quit IRC22:04
*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has quit IRC22:04
*** ndec <ndec!sid219321@linaro/ndec> has joined #yocto22:05
*** dagmcr <dagmcr!sid323878@gateway/web/irccloud.com/x-hhxgyvilgfkanbar> has joined #yocto22:05
*** rsalveti <rsalveti!uid117878@gateway/web/irccloud.com/x-lhyggrdugkbossmz> has joined #yocto22:05
*** fancer <fancer!fancer@gateway/web/irccloud.com/x-zbtufgayjibdgmtu> has joined #yocto22:06
*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has joined #yocto22:06
*** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/x-etljggmhaktzsznq> has joined #yocto22:06
*** ukembedded <ukembedded!sid304355@gateway/web/irccloud.com/x-smoghejpsvobcqeq> has joined #yocto22:07
RPsakoman: as a headsup warning, the new buildtools has some issues with oe-selftest :(22:17
RPsakoman: that is why master/master-next are now struggling22:18
sakomanBummer, sorry to hear that :-(22:18
RPsakoman: I think I have an idea to fix it, its just a pain to enable22:24
RP(need a new build tools, then more testing)22:24
sakomanRP: I'll wait till your testing is complete before pulling anything into dunfell22:26
sakomanIs this something we should hold the release for?22:26
sakomanI suspect it is only an issue for autobuilder users22:27
RPsakoman: no, its only the autobuilder22:28
*** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC22:29
sakomanDoing another round of dunfell hw testing on imx6 and stm32mp -- so far looks good22:30
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto22:31
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC22:33
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC22:33
*** kaspter <kaspter!~Instantbi@> has quit IRC22:34
*** kaspter <kaspter!~Instantbi@> has joined #yocto22:34
RPsakoman: I merged the changes for dunfell while I remember22:35
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto22:36
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC22:36
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto22:36
*** C-o-r-E <C-o-r-E!~corey@modemcable069.166-70-69.static.videotron.ca> has quit IRC22:37
*** C-o-r-E <C-o-r-E!~corey@modemcable149.12-178-173.mc.videotron.ca> has joined #yocto22:39
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC22:42
*** samvlewis <samvlewis!~samvlewis@> has quit IRC22:45
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto22:46
*** samvlewis <samvlewis!~samvlewis@> has joined #yocto22:51
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC22:51
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC23:11
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto23:11
RPsakoman: did you run a perf test build for dunfell? Next question is when to build the release?23:14
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC23:15
* RP -> Zzzz23:18
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto23:20
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC23:24
sakomanRP: the perf test is queued23:32
sakomanWe can build whenever convenient23:33
*** camus1 <camus1!~Instantbi@> has joined #yocto23:57
*** kaspter <kaspter!~Instantbi@> has quit IRC23:58
*** camus1 is now known as kaspter23:58

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!