Monday, 2021-09-20

*** ram <ram!~ram@2601:647:4801:6aa0:d0e1:2b78:8e3c:75ca> has quit IRC (Quit: Ping timeout (120 seconds))00:13
*** ram <ram!~ram@2601:647:4801:6aa0:d0e1:2b78:8e3c:75ca> has joined #yocto00:14
moto-timoJPEW: finally understood it is the phosh:phosh uid:gid and have the PIN set.. but it is unhappy after login so <shrug>00:17
ram@marex I have checked the environment variables and I can see the path and the package is available under the work directory as well. Can I know in which file is the dependency package and the version mentioned?00:23
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto00:27
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)00:34
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)00:37
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::81de> has quit IRC (Ping timeout: 260 seconds)00:47
*** jbronder <jbronder!jsbronder@user/jbronder> has joined #yocto00:49
*** jbronder <jbronder!jsbronder@user/jbronder> has quit IRC (Client Quit)00:53
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::81de> has joined #yocto00:53
*** jbronder <jbronder!jsbronder@user/jbronder> has joined #yocto00:54
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto00:54
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)00:59
*** jbronder <jbronder!jsbronder@user/jbronder> has quit IRC (Quit: WeeChat 3.2)00:59
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::81de> has quit IRC (Read error: Connection reset by peer)01:04
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::81de> has joined #yocto01:05
*** jbronder <jbronder!jsbronder@user/jbronder> has joined #yocto01:19
*** jsbronder <jsbronder!~jsbronder@user/jbronder> has quit IRC (Quit: WeeChat 2.9)01:20
*** jbronder is now known as jsbronder01:20
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:20
*** ram <ram!~ram@2601:647:4801:6aa0:d0e1:2b78:8e3c:75ca> has quit IRC (Quit: Ping timeout (120 seconds))01:24
*** bluelightning <bluelightning!~paul@2406:e003:1528:db01:14e8:4ee3:ae7c:4984> has quit IRC (Ping timeout: 260 seconds)01:46
*** camus <camus!~Instantbi@> has joined #yocto02:17
*** mouser <mouser!~mouser@> has joined #yocto02:31
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto02:32
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)03:06
*** arlen_ <arlen_!> has quit IRC (Ping timeout: 260 seconds)03:15
*** camus1 <camus1!~Instantbi@> has joined #yocto03:33
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)03:35
*** camus1 is now known as camus03:35
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto03:45
mouserls -al03:46
* mouser sighs and moves back to the right window...03:46
*** mouser is now known as Ch^W03:47
*** wooosaiii <wooosaiii!> has joined #yocto04:01
*** wooosaiiii <wooosaiiii!> has quit IRC (Ping timeout: 268 seconds)04:04
*** bluelightning <bluelightning!~paul@2406:e003:1528:db01:dcd7:17a1:97dd:288a> has joined #yocto04:06
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 260 seconds)04:21
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto04:24
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)04:25
*** Saur <Saur!> has quit IRC (*.net *.split)04:29
*** lukma <lukma!> has quit IRC (*.net *.split)04:29
*** aeroraptor <aeroraptor!> has quit IRC (*.net *.split)04:29
*** mithro <mithro!> has quit IRC (*.net *.split)04:29
*** twinning[m] <twinning[m]!~twinningm@2001:470:69fc:105::e5db> has quit IRC (*.net *.split)04:29
*** rburton <rburton!rburton@user/rburton> has quit IRC (*.net *.split)04:29
*** aeroraptor <aeroraptor!> has joined #yocto04:30
*** rburton <rburton!rburton@user/rburton> has joined #yocto04:30
*** lukma <lukma!> has joined #yocto04:30
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto04:31
*** Saur <Saur!> has joined #yocto04:31
*** mithro <mithro!> has joined #yocto04:31
*** twinning[m] <twinning[m]!~twinningm@2001:470:69fc:105::e5db> has joined #yocto04:33
*** ram <ram!~ram@2601:647:4801:6aa0:d0e1:2b78:8e3c:75ca> has joined #yocto04:39
*** ram <ram!~ram@2601:647:4801:6aa0:d0e1:2b78:8e3c:75ca> has quit IRC (Client Quit)04:40
*** k4wsys[m] <k4wsys[m]!~k4wsysmat@2001:470:69fc:105::e339> has quit IRC (*.net *.split)04:41
*** moto-timo <moto-timo!sid495702@fedora/ttorling> has quit IRC (*.net *.split)04:41
*** kranzo[m] <kranzo[m]!~kranzomat@2001:470:69fc:105::dd3e> has quit IRC (*.net *.split)04:41
*** Crofton <Crofton!> has quit IRC (*.net *.split)04:41
*** thierryE <thierryE!> has quit IRC (*.net *.split)04:41
*** linkliu60 <linkliu60!~user_name@> has quit IRC (*.net *.split)04:41
*** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has quit IRC (*.net *.split)04:41
*** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has quit IRC (*.net *.split)04:41
*** Guest9844 <Guest9844!> has quit IRC (*.net *.split)04:41
*** rfried <rfried!> has quit IRC (*.net *.split)04:41
*** g0hl1n <g0hl1n!> has quit IRC (*.net *.split)04:41
*** OnkelUlla <OnkelUlla!> has quit IRC (*.net *.split)04:41
*** yocton <yocton!~quassel@2001:bc8:3386::1> has quit IRC (*.net *.split)04:41
*** g0hl1n <g0hl1n!> has joined #yocto04:41
*** OnkelUlla <OnkelUlla!> has joined #yocto04:41
*** thierryE <thierryE!> has joined #yocto04:41
*** linkliu60 <linkliu60!~user_name@> has joined #yocto04:41
*** override1 <override1!> has joined #yocto04:42
*** rfried <rfried!> has joined #yocto04:42
*** Crofton <Crofton!sid401373@2a03:5180:f:2::6:1fdd> has joined #yocto04:42
*** moto-timo <moto-timo!sid495702@fedora/ttorling> has joined #yocto04:42
*** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto04:43
*** kranzo[m] <kranzo[m]!~kranzomat@2001:470:69fc:105::dd3e> has joined #yocto04:44
*** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has joined #yocto04:45
*** k4wsys[m] <k4wsys[m]!~k4wsysmat@2001:470:69fc:105::e339> has joined #yocto04:46
*** amitk <amitk!~amit@> has joined #yocto04:54
*** ChanServ <ChanServ!> has quit IRC (shutting down)04:54
*** ChanServ <ChanServ!> has joined #yocto04:58
*** sets mode: +o ChanServ04:58
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)05:34
*** camus <camus!~Instantbi@> has joined #yocto05:36
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Quit: WeeChat 3.1)05:42
*** ThomasD13 <ThomasD13!> has joined #yocto05:48
*** fleg <fleg!64bf4386e9@user/fleg> has joined #yocto05:51
*** pgowda <pgowda!> has joined #yocto05:54
*** fleg <fleg!64bf4386e9@user/fleg> has quit IRC (Remote host closed the connection)06:14
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto06:17
*** zeddii <zeddii!> has quit IRC (Ping timeout: 265 seconds)06:17
*** fleg <fleg!64bf4386e9@user/fleg> has joined #yocto06:17
*** zeddii <zeddii!> has joined #yocto06:22
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:24
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto06:44
*** mckoan|away is now known as mckoan06:45
mckoangood morning06:46
JosefHolzmayr[m]yo dudX and mckoans06:47
*** creich <creich!> has joined #yocto06:55
*** zpfvo <zpfvo!~fvo@> has joined #yocto06:56
*** fbre <fbre!~fbre@> has joined #yocto06:58
*** rfuentess <rfuentess!~rfuentess@2a01:598:b028:a787:d05d:6829:6438:4ef1> has joined #yocto06:58
*** Tyaku <Tyaku!> has joined #yocto07:02
*** gsalazar <gsalazar!> has joined #yocto07:05
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)07:08
RPJosefHolzmayr[m]: Good morning!07:09
JosefHolzmayr[m]yo RP07:10
*** Tyaku <Tyaku!> has quit IRC (Quit: Lost terminal)07:14
*** frieder <frieder!> has joined #yocto07:19
*** mtudan <mtudan!~mtudan@> has joined #yocto07:24
*** mtudan <mtudan!~mtudan@> has quit IRC (Client Quit)07:25
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)07:34
*** yannd <yannd!~yann@> has quit IRC (Ping timeout: 268 seconds)07:35
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has joined #yocto07:36
*** rfuentess <rfuentess!~rfuentess@2a01:598:b028:a787:d05d:6829:6438:4ef1> has quit IRC (Ping timeout: 264 seconds)07:39
*** florian <florian!> has joined #yocto07:45
*** yannd <yannd!~yann@> has joined #yocto07:47
*** tnovotny <tnovotny!> has joined #yocto07:51
*** behanw <behanw!> has quit IRC (Quit: Connection closed for inactivity)08:05
*** xmn <xmn!> has joined #yocto08:10
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:13
kanavinRP: I adjusted the copy to log/oeqa to symlink, but that wasn't picked into master-next?08:28
*** rfuentess__ <rfuentess__!> has joined #yocto08:32
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has quit IRC (Read error: Connection reset by peer)08:35
*** user_123 <user_123!~user@> has quit IRC (Remote host closed the connection)08:36
*** user_123 <user_123!~user@> has joined #yocto08:36
ThomasD13Hi guys, I have some issues to understand the concept of MULTICONF, image and machine configuration. This is what I assume:09:00
ThomasD13image config: I specify which apps/tools should get deployed in the image file, which holds all I need to boot the linux (kernel, devicetree blob, root fs)09:01
ThomasD13machine configuration: Place to specify which kernel + kernel config + devicetree should be used09:02
qschulzThomasD13: there's no image config, there are image recipes though (the notion is important because some things apply to configruation files and some others to recipes)09:03
ThomasD13Multiconf: Used to build same packages for different architectures. For example when using an SoC, which has ARM A72, R5, M3, etc...09:03
RPkanavin: sorry, just not got to that yet. master-next has a few more pressing issues :/09:03
RP(as in it is rather broken)09:04
ThomasD13qschulz, okay. Apart from that, is my assumption correct?09:04
* RP is rather sad the pkgconfig dependency situation has bitrotted so badly09:05
JosefHolzmayr[m]ThomasD13: it is not incorrect, yet very limited.09:05
ThomasD13JosefHolzmayr[m], I try to get the basic idea of what belongs into image recipe and what in machine configuration :)09:06
fbreHi! Is there a file in sources/poky/meta/classes where the partitions for boot and rootfs are defined? Somehow I think I have seen before there was something like two lines where boot partition and roofs partition was defined for blocksize, partition size etc.09:06
qschulzThomasD13: machine configuration file for everything that is specific to your HW. So kernel, dtb, bootloader, tunes, architecture,etc... could add specific image filesystem "formats" if they are specific to the machine (e.g. the old sdcard.img IMAGE_FSTYPES that was used for the RPi (among others)09:06
JosefHolzmayr[m]ThomasD13: important fact #1: recipe data is local, configuration data is global. hence, whatever you want to do that affects more than the image content selection or its processing, cannot be in the image recipe. thats the one thing.09:07
qschulzThomasD13: image recipe is basically the place where you specific a collectiono f packages to install into filesystems and what kind of filesystems you want (that are machine agnostic)09:08
JosefHolzmayr[m]ThomasD13: important fact #2: MACHINE and DISTRO features are orthogonal, or at least should be. the machine config shall define everything that your build really needs to know to work on a specific piece of hardware, and nothing beyond that.09:08
JosefHolzmayr[m]ThomasD13: therefore, everything that affects multiple packages, e.g. defines your ABI/API, should go into the DISTRO09:08
qschulzmulticonfig is when you have more than one architecture on your HW (e.g. out-of-SoC MCU, cortex-M something in the SoC, etc...)09:08
qschulzwell, I'll let JosefHolzmayr[m] answer you :)09:09
JosefHolzmayr[m]ThomasD13: and important fact #3: multiconfig is primarily used for different machines, but not necessarily to. its more like an "alternative config". so you totally could use it to build a bedig image additional to the standard build.09:09
JosefHolzmayr[m]bdig = debug09:09
*** gsalazar_ <gsalazar_!~gsalazar@> has joined #yocto09:10
JosefHolzmayr[m]qschulz: heh i'm through, feel free to add/correct me.09:12
qschulzJosefHolzmayr[m]: i think we complemented each other's answer so I'm good with that :)09:13
*** gsalazar <gsalazar!> has quit IRC (Ping timeout: 246 seconds)09:13
ThomasD13Okay, so for example my vendor is using a image recipe and machine configuration to build a complete image for specific board (I name it "board_1"). There is also a multiconfig, because it builds packages for the R5 and A72. (There is a SoC on the board)09:13
* kanavin wonders why aren't we seeing use of gtk4 anywhere, yet09:14
kanavinmoto-timo, JPEW i assume phosh is also gtk3?09:14
kanavinit's already on it's third major release!09:14
ThomasD13Now I would like to extend this to a second board. "board_2". The SoC is identical, the hardware around alittle bit different. So I need a different kernel and devicetree. Maybe some different apps on the rootfs.09:15
kanavinI though of adding a recipe, but without actual consumers it's not truly verified.09:15
ThomasD13I would guess, I have to declare a second machine configuration, whereas I define the different kernel/devicetree. Maybe also different u-boot config.09:16
JosefHolzmayr[m]ThomasD13: sounds like you actually want a seperate build that shares some layers.09:16
qschulzkanavin: gnome 40 Google tells me?09:16
ThomasD13And I use another image recipe to specify some other apps on the rootfs09:16
JosefHolzmayr[m]ThomasD13: multiconfig theoretically can used to do "i have this build, but, pretty please, can you also build this completely different thing too?"09:17
kanavinqschulz, none of the gnome components we carry in oe-core throw an error09:17
ThomasD13But I don't understand what I have to too with the multiconfig?09:17
ThomasD13*to do09:17
JosefHolzmayr[m]ThomasD13: but that sounds like headaches. multiconfig really shines when you have one target that internally needs preliminary builds with different configurations. if you want a build for something else altogehter (e.g., a different board): create a new machine, set up a new build.09:18
ThomasD13JosefHolzmayr[m], yes, basically yes. Sharing majority of layers, but I need to specify different kernel/dtb09:18
qschulzJosefHolzmayr[m]: you're missing the fact that the current build is already multiconfig because of the Cortex-R509:18
qschulzThomasD13: so I think you just need to create a new machine and replace board_1 with board_2 in your multiconfig call/configuration files (don't know how it is setup really, JosefHolzmayr[m] will know more for sure)09:19
JosefHolzmayr[m]qschulz: now, why am i? the new build can totally be multiconfig in itself too. but that shoudn't affect the main build target.09:19
qschulzand create a new image recipe09:19
ThomasD13Exactly. I need somehow the same multiconfig in my new build09:19
JosefHolzmayr[m]ThomasD13: the shared layers can bring the multiconfig.09:20
JosefHolzmayr[m]if you glue everything up, you will end up with headaches because you always kick off the main-master-magic-humonguous build even if you are only modifying one target. what happens when board 3 arrives? board 4? board 20?09:22
ThomasD13Okay, so which is pulling what? I think from JosefHolzmayr[m] rules #1 and #2, the machine.conf is pulling the required image recipe (because machine is global and image is local?)09:23
JosefHolzmayr[m]creating a build for 20 different images on 20 different boards that can only be kicked off in one (because thats what a multiconfig build somewhat implies) sounds ridiculous, right? and so is it, also for 2 baords.09:23
ThomasD13But what does multiconfig exactly do? Is it also global?09:23
JosefHolzmayr[m]ThomasD13: no, a machine config pulls no image. the machine configuration is global for the build. the image uses it.09:24
ThomasD13ah okay09:24
qschulzJosefHolzmayr[m]: My understanding is that ThomasD13 does not want to build all machines at once, but rather build a multiconfig setup with board_2+cortex-r509:24
qschulzand they currently have board1_+cortex-r509:25
JosefHolzmayr[m]ThomasD13: now you're getting closer. multiconfig is actually not much more than "give me an additional build in the existing configuration, just let me tweak this handful of variables".09:25
JosefHolzmayr[m]qschulz: nope. they have. board1 = (cortex a + cortex r)09:25
ThomasD13Yes, I dont need to build all machine at once. But I need that everything is build for a single machine at once. So all the packages for R5 and also for A7209:25
qschulzJosefHolzmayr[m]: "There is also a multiconfig, because it builds packages for the R5 and A72. (There is a SoC on the board)"09:26
JosefHolzmayr[m]ThomasD13: see, and thats why you have exactly one build per machine. where each can be multiconfig, or not, depending on the requirements.)09:26
ThomasD13board 1 = (cortex a + cortex r), board 2 = (cortex a + cortex r) but with different kernel/dtb09:27
qschulzBut I'll let ThomasD13 explain themselves, no need for me to talk in their behalf :)09:27
JosefHolzmayr[m]qschulz: it leaves a certain leeway for interpretation, of course - but i think i've said everything necessary anyways. need to earn some money now.09:27
qschulzThomasD13: cortex a in a one machine configuration file, cortex r inb another machine configuration file, then multiconfig for the machine conf of cortex a + machine conf cortex R09:28
jaskij[m]ThomasD13: if I understand you correctly, a slightly hacky way to have all packages "build at once" - with one command - is to just add an image with all the packages.09:29
ThomasD13First of all, thank you all guys for your quick response. I have to reread carefully to understand what you mean.09:30
jaskij[m]My bad, I didn't scroll back far enough09:30
qschulzThomasD13: a machine conf file is for one arch (well, can be more with multilib but let's not go there, you don't seem to need it and if you can avoid it, do so :) )09:31
qschulzso if you have more than one arch (which is your case), you need a machine conf file per arch (one for cortex A + one for cortex R)09:31
ThomasD13One point to note: I don't want a hack to add fast second machine, and build these two machines with one call09:31
ThomasD13qschulz, okay09:32
qschulzso except if the cortex-R packages need to be different on board_1 than board_2, you can share the same machine for the cortex-R in both multiconfig (the one for board_1 and the other for board_2)09:33
ThomasD13qschulz, sorry you mean "except" or "example" ?09:36
qschulzI meant except09:42
ThomasD13Ok to sum up: It seems my vendor has used multiconfig to build for cortex A and cortex R. Another solution to this case would be to specify a machine configuration each for cortex A and R09:43
qschulzThomasD13: you already have a machine configuration file for the cortex-A09:44
qschulzso you just have to write your own machine configuration file for the cortex-A in your board_209:45
qschulzand then replace in the multiconfig bitbake call the cortex-A machine name for board_1 with the one for the cortex-A machine name for board_209:45
*** chrfle <chrfle!> has joined #yocto09:46
ThomasD13ahhh okay - I think i get closer now :)09:47
qschulzwell.. ok. It's not correct to say "machine configuration for cortex-A" but more "everything handled by the cortex-A", including kernel, bootloader, and HW components handled by the kernel running on cortex-A for example09:48
qschulz*"everything that is specific to board_1 and that is handled by the cortex-A"09:48
ThomasD13Maybe the last question, which answer will be "it makes all sense now", or "Ill start from scratch :) ": Is the multiconfig "visible" across different machine configuration?09:50
qschulzyou mean, do the machine configuration files have knowledge they're used in a multiconfig setup?09:51
qschulzThey shouldn't need to, multiconfig is just saying to bitbake: build that image for that machine conf, and this image for this image conf, and this or that image recipe might use the artifacts from that or this image recipe09:52
qschulzor at least that's my understanding09:52
ThomasD13Okay, thank you very much. I need to sort my thoughts... qschulz do you have paypal or anything? I would be happy to spend you at least a cup of coffee or something, to mess around with an noob like me :)09:55
fbreHi! I have a boot and a rootfs partition. Do you know which .bb file or class file puts both images in the .wic.gz image file?09:55
rburtonwhatever WKS_FILE is set to defines the .wks that tells wic what to do09:56
qschulzThomasD13: my work contract does not allow me to receive donations :) and in any case, happy doing this for free :) Thanks for offering, don't hesitate to talk to your bosses to spend some money on supporting Yocto :)
qschulzfbre: classes/image_types_wic.bbclass is very likely to be the class doing that09:57
ThomasD13Alright, I will talk with my boss in our next meeting ;) Maybe i'll spend myself a little tip09:59
fbreqschulz: I want to change the size of the rootfs partition to something bigger than it actually needs to be. I don't see how the partition size is set in image_types_wic.bbclass10:09
jaskij[m]That table doesn't work on mobile10:10
fbreI suppose it's somehow done via the tool 'parted'10:10
qschulzfbre: very likely something you can set in the WKS_FILE10:10
qschulzfbre: seems to indicate it's --fixed-size argument you should pass to your partition in the WKS_FILE10:11
jaskij[m]fbre: why not throw in a first run expand rootfs script? That way you've got it covered regardless of actual storage size.10:12
qschulzjaskij[m]: because the partition is not the last one in the partition table10:12
fbreqschulz: What do you mean with "rootfs script"?10:17
qschulzfbre: it wa jaskij[m] and I assume they were talking about resize2fs or something similar10:23
*** gsalazar_ is now known as gsalazar10:23
fbreX)  aaah, now I've found the location where the partitions are defined: It's in sources/meta-freescale/wic/... where I find a few  files which call the tool 'part' for u-boot, /boot and /10:25
jaskij[m]Yup, write a script which expands the rootfs to full media size the first time the device boots. But if rootfs isn't the last partition it's a moot point.10:25
fbreThis looks promising to add your suggested parameter --fixed-size there10:25
*** mckoan is now known as mckoan|away10:29
fbreDevice       Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type10:29
fbreCurrently, fdisk shows this on my device. I want to have mmcblk1p2  a fixed size of 512M to be able to exchange this partition later without touching mmcblk1p3 behind10:29
fbredev/mmcblk1p1 *  128,0,1     1023,3,32        16384     195215     178832 87.3M  c Win95 FAT32 (LBA)10:31
fbredev/mmcblk1p2    1023,3,32   1023,3,32       196608     895629     699022  341M 83 Linux10:31
fbredev/mmcblk1p3    1023,3,32   1023,3,32       895630    1419917     524288  256M 83 Linux10:31
fbreAnyway, it seems it's one of the files in sources/meta-freescale/wic/ . Now I need to find out which one of them is used for my i.mx810:33
qschulzfbre: if you bitbake -e your image recipe and look for WKS_FULL_PATH in htere, it'll tell you exactly where the file is10:34
*** yocton <yocton!~quassel@2001:bc8:3386::1> has joined #yocto10:46
*** xmn <xmn!> has quit IRC (Ping timeout: 246 seconds)11:05
fbreqschulz: thanx, bitbake -e outputs imx-imx-boot-bootpart.wks11:06
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Read error: Connection reset by peer)11:07
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto11:08
fbreI guess I have to reimplement wic/ in my own meta layer11:10
fbreIs it possible to overload such file in my own meta layer?11:19
fbre... by just copying to my meta layer and modify that?11:19
fbre(y)  thanx for your help!11:22
wCPOI'm a bit puzzled why skopeo-native is trying to find gpgme on the host ([...]/build/tmp/hosttools/ld: cannot find -lgpgme), I assume it is some kind of bug?11:23
rburtondoes it depend on gpgme-native though?11:28
wCPOrburton: It depends on gpgme11:29
rburtonthen yes, bug in the makefiles.11:30
rburtonmost likely not respecting LDFLAGS which point it at the native sysroot11:30
wCPOrburton: sounds likely. skopeo is a Go program, so very likely some missing/wrong flag11:31
wCPOI backported skopeo-native to hardknott, so could already be fixed. I will investigate11:31
*** angolini <angolini!> has joined #yocto11:35
fbrehmm.... just copying   to   sources/my-meta/wic/   doesn't seem to have an effect of the wic.gz file I create with bitbake11:36
fbre(although I added that option --fixed-size 256M)11:37 for the boot partition    and --fixed-size 512M to the rootfs partition11:37
*** rfuentess__ is now known as rfuentess11:37
*** wooosaiii <wooosaiii!> has quit IRC (Remote host closed the connection)11:38
*** wooosaiii <wooosaiii!> has joined #yocto11:39
barathThis is probably a long-shot but... is there something like REQUIRED_VERSION_<pn>?  or a DEPENDS which sets the minimum required version of a dependency?11:40
Saurbarath: There is for runtime dependencies.11:41
barathwhat's it called for runtime dependenceis?11:41
SaurRDEPENDS:${PN} = "foo (>= 1.2.3)"11:42
baraththank you, I didnt know that11:42
barathon a possibly related note, we sometimes have problems with someone screwing up and the PREFERRED_VERSION doesn't actually exist. say, openssl. yocto will then proceed to just pick a "random" version. we've got a hacked branch locally somewhere which will abort the build. is there a more "yoctonic" way of solving that? some QA thing?11:44
SaurIt is rarely used as typically when building with bitbake you have control of the layers and what versions the different recipes use.11:44
barathyeah, we have control of those. it'd just be more elegant to have yocto abort instead of us grepping for yocto choosing another version because whatever we specified doesnt exist because someone made a typo or mistake etc11:50
JosefHolzmayr[m]barath: abort, or at least report. yeah, i've seen that too and think an info or warning on such would be nice.11:52
barathit's "reported" in the sense that there's warnings (IIRC) printed about yocto choosing another version, but yeah11:53
barathmaybe there's a QA trick I'm not aware of11:53
barathI'm concerned about missing this in automated CIs. shipping an incorrect openssl version can be kind of embarrassing :D11:53
JosefHolzmayr[m]ah there's warnings? nice. but then its up to your CI to actually evaluate the logs ;-)11:53
barath:D sure you could say that... but grep-driven CIs don't sound super robust. if the outputs/what we grep for changes formats, we might never notice11:55
barathI guess we could parse the package manifest, which I assume includes versions. but then you'd have to wait for the entire build to complete before detecting the error.11:55
JosefHolzmayr[m]barath: well, watching the output for two strings ("warning" and "error") almost never hurts in CI11:56
RPbarath: there is a open bug to make DEPENDS = "openssl (=X.Y.Z)" work but it hasn't happened as yet11:56
RPbarath: we've also talked about making PREFERRED_VERSION mismatches fatal but haven't added any option as yet11:57
barathRP: thank you, I'll look for that11:57
barathJosef Holzmayr (TheYoctoJester): and that's a good point11:57
JosefHolzmayr[m]barath: :)11:57
barathfor reference, this seems to be the bug about adding versioning support to depends
barathif someone were to take a crack at it, would it help to look at how the same was implemented for RDEPENDS?12:02
RPbarath: we rely on the package managers for that so probably not :/12:05
barathah yes, that makes sense... alright12:05
RPbarath: we've not implemented this as it is quite hard to do :(12:05
baraththat's good to know at least, thx :) maybe I can justify it to management at some point12:09
RPbarath: would be nice to have it, we've certainly talked about it for a while12:10
*** paulg <paulg!> has joined #yocto12:10
*** jwillikers <jwillikers!> has joined #yocto12:22
*** fleg <fleg!64bf4386e9@user/fleg> has quit IRC (Remote host closed the connection)12:33
*** fleg <fleg!64bf4386e9@user/fleg> has joined #yocto12:35
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has joined #yocto12:41
*** rfuentess <rfuentess!> has quit IRC (Ping timeout: 246 seconds)12:44
*** yannd <yannd!~yann@> has quit IRC (Ping timeout: 264 seconds)12:56
*** Guest46 <Guest46!~Guest46@> has joined #yocto12:58
Guest46I'm using --ptable gpt in the *.wks file, and I get the error: GPT:Primary header thinks Alt. header is not at the end of the disk.12:59
Guest46GPT:31116287 !=3126681512:59
Guest46GPT:Alternate GPT header not at the end of the disk12:59
Guest46GPT:31116287 !=3126681512:59
Guest46GPT: Use GNU Parted to correct GPT errors.12:59
Guest46Is the backup header missing with --ptable gpt?13:00
*** RP <RP!~richard@2001:8b0:aba:5f3c:96de:80ff:fe6d:2d2b> has quit IRC (Quit: Leaving.)13:02
*** vermaete <vermaete!> has joined #yocto13:02
*** RP <RP!~richard@2001:8b0:aba:5f3c:96de:80ff:fe6d:2d2b> has joined #yocto13:03
vermaeteIn case of a development at the master of all layers, does it still make sens to point SSTATE_MIRRORS to the
vermaeteOr in other words, how often in that updated?13:04
vermaete(and who is doing it?)13:04
*** yannd <yannd!~yann@> has joined #yocto13:08
JPEWvermaete: Yes, and the Yocto autobuilder populates it13:09
vermaeteand is 'master' than 'the /dev' or 3.4?13:10
vermaete3.4/                                               04-Sep-2021 10:16                   -13:10
vermaetedev/                                               09-Aug-2017 15:42                   -13:10
vermaeteI only see the date of creation of the directory, i think.13:10
JPEWvermaete: (see step #2)13:14
*** vermaete <vermaete!> has quit IRC (Quit: Client closed)13:16
*** FredO <FredO!> has joined #yocto13:17
fbreX)  aaaah, I have to add WKS_FILE = ""  to my machine.conf  file and then bitbake uses my partitioning  with --fixed-size13:18
*** rsalveti <rsalveti!> has joined #yocto13:28
ThomasD13When I have a variable like this: "KERNEL_CONFIG_FRAGMENTS_append_j7-evm = " ${WORKDIR}/devmem.cfg" ", is "../devmem.cfg" only appended, when machine configuration "j7-evm" is used?13:28
qschulzThomasD13: yes13:33
qschulzwell, machine named j7-evm or if j7-evm is part of MACHINEOVERRIDES13:34
ThomasD13qschulz, thanks that was my next question. If this kind of syntax only applies to machine configuration :)13:34
vmesonkanavin: re: [16:35] <kanavin> RP: I've heard others are working on it? and working and working and working, and no patches are showing up :-/13:43
vmesonif librsvg is slowing you down from trying out phosh, go for it. I'm back from vacation but buried under a stack of email and likely $dayjob oblications.13:44
*** roussinm <roussinm!> has joined #yocto13:49
ThomasD13Has someone an idea how to debug this kind of error, when bitbake does not even start to use "-e" ?
Wouter0100Is there any proper way to "force" a specific username when showing the login prompt? I want someone who hooks up a screen, to only be able to login to a specific user.13:56
qschulzThomasD13: I assume DEF_TOOLCHAIN_PATH is not defined anywhere13:56
fullstopJust to confirm my suspicions, there is no way to modify a bbclass in a layer?13:56
rburtonWouter0100: don't tell users the other passwords?13:57
qschulzfullstop: you can override it but not use a bbappend mechanism if that's the question13:57
fullstopRight, so I can't extend what is already there -- it must be replaced entirely.13:57
vmesonThomasD13: there's always strace ....13:57
ThomasD13alright, I'll dig into that :)13:58
fullstopI can work around it, qschulz, thanks for the response.13:58
Wouter0100rburton: I surely won't, but regardless I'd love to let them skip the `username` field if that'd be possible :)13:58
qschulzfullstop: however, I'd highly encourage you to not override it and send a patch upstream so everybody can benefit from it and you don't have to have a forever burden on your shoulders when you'll need to upgrade your layers13:58
rburtonWouter0100: you could  just start a bash with the right user on the consoles instead of a login prompt, but that might bite you if you actually need to login as another user13:59
fullstopqschulz: It's not that big of a benefit to others.  The process that I have for updating devices executes opkg in an environment which does not have /sbin in PATH, so updating kernel modules fails since depmod fails to execute.13:59
fullstopI can update the environment to include /sbin, but it turns it into a two-step process.13:59
ThomasD13I just copied the vendor's machine configuration and renamed it. But it seems there is a lot *_append_vendorMachineConfig in all these layers :/ Seems to be get complicated14:00
qschulzThomasD13: use MACHINEOVERRIDES for that ;)14:00
qschulzand... in some cases, it might be a good idea to just include the original machine configuration file instead of copy-pasting it (not that it would help in any way on that specific issue)14:01
ThomasD13qschulz, I'll check what MACHINEOVERRIDES does exactly. This was just my first step to add additional machine config :S14:01
qschulzbut yeah, vendor BSPs aren't known to be very easy/nice to work with14:01
Wouter0100rburton: we don't have any other users and sudo is not installed either. We've build our own PAM module for a `management` user to ease up logging in, so we do want PAM - but preferably *only* to the management user. All other users (jncl. root) are disabled on purpose, as we've a different image for testing purpose.14:01
Wouter0100But I'm unable to find any way to do so :(14:02
qschulzWouter0100: you could print the username right before the input for the user name14:02
rburtonWouter0100: so how are you going to login as management if the consoles are all pre-logged in?14:02
rburtonyou just need to change what init spawns on the consoles14:02
*** sakoman <sakoman!> has joined #yocto14:02
Wouter0100Oh noh, they're not pre-logged in :P. Sorry I may make it look confusing14:03
rburtonso what do you want?14:03
Wouter0100In the login prompt I want to skip the `username` input field and directly go to the next step for authentication (normally a password input field, but in our case the custom PAM module) for the `management` user  :D14:04
rburtonWouter0100: you might need to swap to proper getty, but getty can do that14:07
Wouter0100Oh, interesting. Found something related to it in the Arch docs:
Wouter0100Thanks!! I'll have a look into that.14:08
*** arlen_ <arlen_!> has joined #yocto14:09
*** vmeson <vmeson!> has quit IRC (Quit: Konversation terminated!)14:14
*** vmeson <vmeson!> has joined #yocto14:23
*** behanw <behanw!> has joined #yocto14:25
*** fbre <fbre!~fbre@> has quit IRC (Quit: fbre)14:38
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto14:47
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:52
moto-timoJPEW: immediately after login to phosh, it seems to fail because the connection is refused to gsd-media-keys... ring any bells?14:55
JPEWHmm, no14:55
JPEWLooks like it's trying to talk to gnome-settings-daemon?14:56
*** Guest46 <Guest46!~Guest46@> has quit IRC (Quit: Connection closed)14:56
moto-timoJPEW: right... so maybe the daemon isn't running (or maybe I forgot to install it)14:57
JPEWmoto-timo: Ya, missing RDEPENDS probably14:57
*** Xagen <Xagen!> has quit IRC (Remote host closed the connection)15:00
*** Xagen <Xagen!> has joined #yocto15:00
kanavinvmeson, I'll give it a shot15:04
JaMaRP: I think qemu-native is missing ninja-native dependency with your changes in master-next, should I send a patch or do you already have similar somewhere15:04
RPJaMa: I don't have that. I'm a little puzzled why we wouldn't see that on the autobuilder15:05
JaMahere it fails with "ERROR: Cannot find Ninja"15:05
JaMawith no ninja on host, but i don't see it in HOSTTOOLS_NONFATAL so it shouldn't probably matter15:06
RPJaMa: has ninja-native in DEPENDS15:06
ThomasD13Hmm.. I see that DEF_TOOLCHAIN_PATH is set by "". But nothing in the layers seem to reference that include. How is that possible?15:06
JaMameta/recipes-devtools/qemu/ overwrites that DEPENDS15:07
ThomasD13ewdt@ewdt-server:~/oe/arago/sources$ grep -r toolchain-arm15:07
ThomasD13Binary file meta-arago/.git/index matches15:07
RPJaMa: so meson is probably missing there too? How did this ever work I wonder? :/15:07
rburtonThomasD13: maybe its included as toolchain-${SOME_VARIABLE}.inc15:07
JaMawell it doesn't include only qemu-native.inc15:07
ThomasD13ahhhhh... thx rburton15:08
rburtonthat was a guess15:08
ThomasD13yes but make sense. I didn't have that possibility in my mind15:08
JaMaRP: you're right | /OE/build/oe-core/tmp-glibc/work/x86_64-linux/qemu-native/6.0.0-r0/qemu-6.0.0/configure: 6415: --version: not found15:09
JaMa| /OE/build/oe-core/tmp-glibc/work/x86_64-linux/qemu-native/6.0.0-r0/qemu-6.0.0/configure: 6418: setup: not found15:09
JaManow qemu-native builds fine again with
ThomasD13When I create a new machine configuration, do I have to link this somehow to a distribution?15:21
RPJaMa: thanks, I'll queue that15:27
RPJaMa: torn on that layer.conf patch, it is a pain but it does let us fix some of the dependencies15:29
*** rcw <rcw!~rcwoolley@> has joined #yocto15:30
vdWhen you guys do customer versioned releases, what do you use for the version? image PV? multiconfig forcing a few preferred versions? distro version?15:42
jaskij[m]I think I've hit another bug, either in multiconfig or in imx-boot (meta-freescale). I'm doing a multiconfig build and even when building for a non-default config, I'm getting a lack of compatibility error between imx-boot and the default machine.15:43
jaskij[m]changing the `MACHINE ?= "xxx"` line in `local.conf` fixes that error15:44
jaskij[m]even though I'm running bitbake with multiconfig specifying a different machine15:45
*** ThomasD13 <ThomasD13!> has quit IRC (Ping timeout: 252 seconds)15:46
*** zpfvo <zpfvo!~fvo@> has quit IRC (Quit: Leaving.)15:50
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:50
*** zpfvo <zpfvo!~fvo@> has quit IRC (Client Quit)15:51
*** pgowda <pgowda!> has quit IRC (Quit: Connection closed for inactivity)15:51
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:51
*** zpfvo <zpfvo!~fvo@> has quit IRC (Client Quit)15:52
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:52
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)15:54
*** frieder <frieder!> has quit IRC (Remote host closed the connection)15:58
*** whuang0389 <whuang0389!> has joined #yocto16:03
*** zpfvo <zpfvo!~fvo@> has quit IRC (Quit: Leaving.)16:03
*** FredO <FredO!> has quit IRC (Quit: Leaving)16:04
JaMaRP: I've included it in my bigger builds to see how badly world is affected, but I kind of like them as the build issues are often relatively clear and easy to fix16:07
JaMaso there might be still enough time for external layers to fix possible fallback16:07
*** goliath <goliath!~goliath@user/goliath> has joined #yocto16:08
vdJPEW: with whisk (or in your setup) what does a customer release version correspond to? the image recipe PV or something else?16:10
vmesonkanavin: that's good, thanks!16:12
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:13
JaMaRP: got another strange ExpansionError in one of my builds, but don't know what exactly causes this (unless it looks really familiar to you):
*** dev1990 <dev1990!~dev@> has joined #yocto16:16
*** rfuentess__ <rfuentess__!> has joined #yocto16:20
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has quit IRC (Ping timeout: 264 seconds)16:24
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Read error: Connection reset by peer)16:24
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto16:41
Tokamakin yocto, is there a way to setup a chroot like environment with all the system files for inspection/modification in a recipe?  kinda like a finalize rootfs step?16:42
rburtonTokamak: manual inspection or automated rootfs qa?16:43
Tokamake.g. i'd like to tweak /etc/passwd after all recipes have injected their accounts (just one use case)16:43
Tokamakautomated apart of the build.  intended for both qa and actual modification16:43
rburtonso, automated16:44
rburtonyou can do whatever you want in ROOTFS_POSTPROCESS_COMMAND16:44
kergothif you just want to run shell scripts to tweak the rootfs, that's what ROOTFS_POSTPROCESS_COMMAND is for, though it doesn't run in a chroot16:44
rburtonbut it does run in a pseudo-context so you are 'root'16:44
Tokamakthanks!  that covers the passwd use case!  will look into this16:45
rburtonthere's already optional commands available for that which manipulate passwd fwiw16:45
Tokamakis there a chroot mechanism (relying on qemu / binfmt integration) for running configuration scrips for certain packages (firewalld's firewall-cmd is the next on my bucket list)16:46
rburtonno but you can run stuff in qemu-user16:49
rburtonbut if firewall-cmd expects to be able to speak to a running firewalld, then that's not going to work16:50
Tokamakdo you have an example of a hook to running qemu-user w/ing yocto?16:50
rburtonthe postinst intercepts like update_font_cache. they're designed to be executed by package management scripts, but show how to call qemuwrapper16:52
Tokamaktrue.  i'm relatively unfamiliar with firewalld, but there does appear to be a firewall-offline-cmd that might fit this current task at hand :)16:53
*** marex <marex!~marex@> has quit IRC (Ping timeout: 252 seconds)16:54
rburtonand if you're lucky its a script so doesn't need qemu16:55
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has joined #yocto16:56
Tokamakthanks for the pointer to qemu class -> postinst_intercept16:57
Tokamakthanks for the insight, rburton16:58
*** rfuentess__ <rfuentess__!> has quit IRC (Ping timeout: 246 seconds)16:59
RPJaMa: something is putting None in the varlist, we should perhaps fix that, then you'd get a better error message17:00
*** florian <florian!> has joined #yocto17:01
rburtonTokamak: alternatively, you can write a on-first-boot postinst script17:05
*** rfuentess__ <rfuentess__!> has joined #yocto17:05
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has quit IRC (Ping timeout: 246 seconds)17:08
vdHow can I look up the IMAGE_LINGUAS value for spanish/spain?17:09
vdthank but where do I look up these values?17:10
Tokamakinteresting.  nice to know as well!17:10
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto17:19
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)17:30
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 268 seconds)17:37
JPEWvd: whisk doesn't really impose any sort of versioning like that17:40
JaMaRP: definitely helps :) bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: There are recursive references in fetcher variables, likely through SRC_URI17:41
JaMaThe variable dependency chain for the failure is: SRCPV -> PV -> SRCPV -> PV -> WORKDIR -> T17:42
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto17:42
JaMaRP: still not clear why lxc from meta-virtualization fails this one in one build, but the same recipe doesn't seem to trigger this in another very similar build17:42
JaMaRP: will let you know when I have some clearer reproducer17:43
*** yates <yates!> has joined #yocto17:44
yatesbasic question: is the do_patch task performed before or after do_configure?17:44
JaMaRP: ok, now it's more clear (of course there is some old junk in meta-qti which doesn't play nice with latest lxc change from meta-virtualization), your bitbake fix is all we need, thanks17:52
vdyates: before, since you want to configure patch sources...17:52
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has quit IRC (Ping timeout: 268 seconds)17:53
*** florian <florian!> has joined #yocto18:02
rburtonyates: you can look stuff like that up trivially. base.bbclass: addtask configure after do_patch18:03
vdbasically specifying a recipe name without semicolon is equivalent to mc:${BB_CURRENT_MC}:pn, correct?18:05
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has joined #yocto18:05
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 -
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto18:11
*** ant__ <ant__!> has joined #yocto18:42
*** rfuentess__ <rfuentess__!> has quit IRC (Ping timeout: 264 seconds)18:45
*** rfuentess <rfuentess!> has joined #yocto18:45
JaMaRP: meta/recipes-devtools/qemu/ is also missing the dependencies18:56
*** SalamaSalama[m] <SalamaSalama[m]!~moustafa5@2001:470:69fc:105::e6c4> has joined #yocto19:11
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Read error: Connection reset by peer)19:13
RPJaMa: thanks for confirming. It is hopefully useful the new code shows the dependency chain :) (when it works properly!)19:43
RPJaMa: I'll tweak the qemu recipe again, thanks19:43
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto19:46
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has joined #yocto19:46
*** rfuentess <rfuentess!> has quit IRC (Ping timeout: 265 seconds)19:49
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 264 seconds)19:51
*** rfuentess__ <rfuentess__!~rfuentess@2a01:598:b028:a787:9d25:fde:d879:bc97> has joined #yocto19:51
ant__RP, JaMa: hi there19:51
ant__RP: what is the 'best' way to implement a switch/case construct? python?19:52
ant__see here
ant__I must evaluate more tags and apply patch accordingly19:52
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto19:53
ant__JaMa, ^ this is the evil enigma2 TV interface :)19:53
ant__soon enigma3 they swear19:53
*** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has quit IRC (Ping timeout: 264 seconds)19:54
*** rfuentess__ <rfuentess__!~rfuentess@2a01:598:b028:a787:9d25:fde:d879:bc97> has quit IRC (Remote host closed the connection)20:00
*** rfuentess__ <rfuentess__!~rfuentess@2a01:598:b028:a787:9d25:fde:d879:bc97> has joined #yocto20:01
whuang0389lol i dont know which email I used to register for the open source summit20:01
RPant__: python is probably easiest20:02
*** rfuentess__ <rfuentess__!~rfuentess@2a01:598:b028:a787:9d25:fde:d879:bc97> has quit IRC (Remote host closed the connection)20:05
*** rfuentess__ <rfuentess__!~rfuentess@2a01:598:b028:a787:9d25:fde:d879:bc97> has joined #yocto20:06
*** rfuentess__ <rfuentess__!~rfuentess@2a01:598:b028:a787:9d25:fde:d879:bc97> has quit IRC (Remote host closed the connection)20:17
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Remote host closed the connection)20:20
*** whuang0389 <whuang0389!> has quit IRC (Quit: Client closed)20:21
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto20:22
*** yannd <yannd!~yann@> has quit IRC (Ping timeout: 264 seconds)20:39
*** opello <opello!~opello@about/csharp/opello> has joined #yocto20:46
opellohi, is there any way to debug why a run.do_install script is suddenly being generated without a function (which shows up in bitbake -e recipe)?20:47
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)20:59
vdIs it preferred to customize IMAGE_NAME or IMAGE_BASENAME?21:18
*** sakoman <sakoman!> has quit IRC (Ping timeout: 260 seconds)21:19
*** florian <florian!> has quit IRC (Ping timeout: 265 seconds)21:20
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto21:24
*** FredO <FredO!> has joined #yocto21:27
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 264 seconds)21:28
*** sakoman <sakoman!> has joined #yocto21:33
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)21:33
*** xmn <xmn!> has joined #yocto21:55
*** florian <florian!> has joined #yocto21:59
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)22:04
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)22:34
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto22:52
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds)22:59
*** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto23:09
*** florian <florian!> has joined #yocto23:12
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)23:14
*** camus1 <camus1!~Instantbi@> has joined #yocto23:24
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)23:26
*** camus1 is now known as camus23:26
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)23:40
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)23:42

Generated by 2.17.2 by Marius Gedminas - find it at!