| *** 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 #yocto | 00:14 | |
| moto-timo | JPEW: 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 #yocto | 00:27 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds) | 00:34 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> 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 #yocto | 00:49 | |
| *** jbronder <jbronder!jsbronder@user/jbronder> has quit IRC (Client Quit) | 00:53 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::81de> has joined #yocto | 00:53 | |
| *** jbronder <jbronder!jsbronder@user/jbronder> has joined #yocto | 00:54 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 00: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 #yocto | 01:05 | |
| *** jbronder <jbronder!jsbronder@user/jbronder> has joined #yocto | 01:19 | |
| *** jsbronder <jsbronder!~jsbronder@user/jbronder> has quit IRC (Quit: WeeChat 2.9) | 01:20 | |
| *** jbronder is now known as jsbronder | 01:20 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> 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@58.246.136.202> has joined #yocto | 02:17 | |
| *** mouser <mouser!~mouser@209.147.121.179> has joined #yocto | 02:31 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 02:32 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds) | 03:06 | |
| *** arlen_ <arlen_!~arlen@50-32-89-83.adr01.dlls.pa.frontiernet.net> has quit IRC (Ping timeout: 260 seconds) | 03:15 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 03:33 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 03:35 | |
| *** camus1 is now known as camus | 03:35 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 03:45 | |
| mouser | ls -al | 03:46 |
| * mouser sighs and moves back to the right window... | 03:46 | |
| *** mouser is now known as Ch^W | 03:47 | |
| *** wooosaiii <wooosaiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 04:01 | |
| *** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC (Ping timeout: 268 seconds) | 04:04 | |
| *** bluelightning <bluelightning!~paul@2406:e003:1528:db01:dcd7:17a1:97dd:288a> has joined #yocto | 04:06 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 260 seconds) | 04:21 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 04:24 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds) | 04:25 | |
| *** Saur <Saur!~pkj@proxy01.se.axis.com> has quit IRC (*.net *.split) | 04:29 | |
| *** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has quit IRC (*.net *.split) | 04:29 | |
| *** aeroraptor <aeroraptor!sid503835@id-503835.ilkley.irccloud.com> has quit IRC (*.net *.split) | 04:29 | |
| *** mithro <mithro!sid24875@id-24875.ilkley.irccloud.com> 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!sid503835@id-503835.ilkley.irccloud.com> has joined #yocto | 04:30 | |
| *** rburton <rburton!rburton@user/rburton> has joined #yocto | 04:30 | |
| *** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has joined #yocto | 04:30 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 04:31 | |
| *** Saur <Saur!~pkj@proxy01.se.axis.com> has joined #yocto | 04:31 | |
| *** mithro <mithro!sid24875@id-24875.ilkley.irccloud.com> has joined #yocto | 04:31 | |
| *** twinning[m] <twinning[m]!~twinningm@2001:470:69fc:105::e5db> has joined #yocto | 04:33 | |
| *** ram <ram!~ram@2601:647:4801:6aa0:d0e1:2b78:8e3c:75ca> has joined #yocto | 04: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!sid401373@id-401373.lymington.irccloud.com> has quit IRC (*.net *.split) | 04:41 | |
| *** thierryE <thierryE!sid286446@id-286446.lymington.irccloud.com> has quit IRC (*.net *.split) | 04:41 | |
| *** linkliu60 <linkliu60!~user_name@72.19.13.156> 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!~override@ec2-3-138-201-125.us-east-2.compute.amazonaws.com> has quit IRC (*.net *.split) | 04:41 | |
| *** rfried <rfried!~rfried@practical-trainings.com> has quit IRC (*.net *.split) | 04:41 | |
| *** g0hl1n <g0hl1n!~g0hl1n@bubus.at> has quit IRC (*.net *.split) | 04:41 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC (*.net *.split) | 04:41 | |
| *** yocton <yocton!~quassel@2001:bc8:3386::1> has quit IRC (*.net *.split) | 04:41 | |
| *** g0hl1n <g0hl1n!~g0hl1n@bubus.at> has joined #yocto | 04:41 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto | 04:41 | |
| *** thierryE <thierryE!sid286446@id-286446.lymington.irccloud.com> has joined #yocto | 04:41 | |
| *** linkliu60 <linkliu60!~user_name@72.19.13.156> has joined #yocto | 04:41 | |
| *** override1 <override1!~override@ec2-3-138-201-125.us-east-2.compute.amazonaws.com> has joined #yocto | 04:42 | |
| *** rfried <rfried!~rfried@practical-trainings.com> has joined #yocto | 04:42 | |
| *** Crofton <Crofton!sid401373@2a03:5180:f:2::6:1fdd> has joined #yocto | 04:42 | |
| *** moto-timo <moto-timo!sid495702@fedora/ttorling> has joined #yocto | 04:42 | |
| *** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto | 04:43 | |
| *** kranzo[m] <kranzo[m]!~kranzomat@2001:470:69fc:105::dd3e> has joined #yocto | 04:44 | |
| *** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has joined #yocto | 04:45 | |
| *** k4wsys[m] <k4wsys[m]!~k4wsysmat@2001:470:69fc:105::e339> has joined #yocto | 04:46 | |
| *** amitk <amitk!~amit@103.208.71.23> has joined #yocto | 04:54 | |
| *** ChanServ <ChanServ!ChanServ@services.libera.chat> has quit IRC (shutting down) | 04:54 | |
| *** ChanServ <ChanServ!ChanServ@services.libera.chat> has joined #yocto | 04:58 | |
| *** cadmium.libera.chat sets mode: +o ChanServ | 04:58 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 05:34 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 05:36 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Quit: WeeChat 3.1) | 05:42 | |
| *** ThomasD13 <ThomasD13!~thomasd13@dsl01.212.114.255.148.ip-pool.nefkom.net> has joined #yocto | 05:48 | |
| *** fleg <fleg!64bf4386e9@user/fleg> has joined #yocto | 05:51 | |
| *** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 05:54 | |
| *** fleg <fleg!64bf4386e9@user/fleg> has quit IRC (Remote host closed the connection) | 06:14 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 06:17 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 265 seconds) | 06:17 | |
| *** fleg <fleg!64bf4386e9@user/fleg> has joined #yocto | 06:17 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 06:22 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:24 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 06:44 | |
| *** mckoan|away is now known as mckoan | 06:45 | |
| mckoan | good morning | 06:46 |
| JosefHolzmayr[m] | yo dudX and mckoans | 06:47 |
| *** creich <creich!~creich@p200300f6af34b210d25002826bf78cc7.dip0.t-ipconnect.de> has joined #yocto | 06:55 | |
| *** zpfvo <zpfvo!~fvo@88.130.216.3> has joined #yocto | 06:56 | |
| *** fbre <fbre!~fbre@145.253.222.69> has joined #yocto | 06:58 | |
| *** rfuentess <rfuentess!~rfuentess@2a01:598:b028:a787:d05d:6829:6438:4ef1> has joined #yocto | 06:58 | |
| *** Tyaku <Tyaku!~Tyaku@176-154-243-92.abo.bbox.fr> has joined #yocto | 07:02 | |
| *** gsalazar <gsalazar!~gsalazar@173.111.90.149.rev.vodafone.pt> has joined #yocto | 07:05 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 07:08 | |
| RP | JosefHolzmayr[m]: Good morning! | 07:09 |
| JosefHolzmayr[m] | yo RP | 07:10 |
| *** Tyaku <Tyaku!~Tyaku@176-154-243-92.abo.bbox.fr> has quit IRC (Quit: Lost terminal) | 07:14 | |
| *** frieder <frieder!~frieder@p50937620.dip0.t-ipconnect.de> has joined #yocto | 07:19 | |
| *** mtudan <mtudan!~mtudan@95.168.120.4> has joined #yocto | 07:24 | |
| *** mtudan <mtudan!~mtudan@95.168.120.4> has quit IRC (Client Quit) | 07:25 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 07:34 | |
| *** yannd <yannd!~yann@88.120.44.86> has quit IRC (Ping timeout: 268 seconds) | 07:35 | |
| *** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has joined #yocto | 07:36 | |
| *** rfuentess <rfuentess!~rfuentess@2a01:598:b028:a787:d05d:6829:6438:4ef1> has quit IRC (Ping timeout: 264 seconds) | 07:39 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 07:45 | |
| *** yannd <yannd!~yann@88.120.44.86> has joined #yocto | 07:47 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 07:51 | |
| *** behanw <behanw!uid110099@id-110099.uxbridge.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 08:05 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 08:10 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 08:13 | |
| kanavin | RP: I adjusted the copy to log/oeqa to symlink, but that wasn't picked into master-next? | 08:28 |
| *** rfuentess__ <rfuentess__!~rfuentess@tmo-097-180.customers.d1-online.com> has joined #yocto | 08: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@14.142.4.2> has quit IRC (Remote host closed the connection) | 08:36 | |
| *** user_123 <user_123!~user@14.142.4.2> has joined #yocto | 08:36 | |
| ThomasD13 | Hi guys, I have some issues to understand the concept of MULTICONF, image and machine configuration. This is what I assume: | 09:00 |
| ThomasD13 | image 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 |
| ThomasD13 | machine configuration: Place to specify which kernel + kernel config + devicetree should be used | 09:02 |
| qschulz | ThomasD13: 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 |
| ThomasD13 | Multiconf: Used to build same packages for different architectures. For example when using an SoC, which has ARM A72, R5, M3, etc... | 09:03 |
| RP | kanavin: 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 |
| ThomasD13 | qschulz, okay. Apart from that, is my assumption correct? | 09:04 |
| * RP is rather sad the pkgconfig dependency situation has bitrotted so badly | 09:05 | |
| JosefHolzmayr[m] | ThomasD13: it is not incorrect, yet very limited. | 09:05 |
| ThomasD13 | JosefHolzmayr[m], I try to get the basic idea of what belongs into image recipe and what in machine configuration :) | 09:06 |
| fbre | Hi! 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 |
| qschulz | ThomasD13: 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 |
| qschulz | ThomasD13: 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 DISTRO | 09:08 |
| qschulz | multiconfig 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 |
| qschulz | well, 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 = debug | 09:09 |
| *** gsalazar_ <gsalazar_!~gsalazar@194.38.148.130> has joined #yocto | 09:10 | |
| JosefHolzmayr[m] | qschulz: heh i'm through, feel free to add/correct me. | 09:12 |
| qschulz | JosefHolzmayr[m]: i think we complemented each other's answer so I'm good with that :) | 09:13 |
| JosefHolzmayr[m] | :) | 09:13 |
| *** gsalazar <gsalazar!~gsalazar@173.111.90.149.rev.vodafone.pt> has quit IRC (Ping timeout: 246 seconds) | 09:13 | |
| ThomasD13 | Okay, 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, yet | 09:14 | |
| kanavin | moto-timo, JPEW i assume phosh is also gtk3? | 09:14 |
| kanavin | it's already on it's third major release! | 09:14 |
| ThomasD13 | Now 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 |
| kanavin | I though of adding a recipe, but without actual consumers it's not truly verified. | 09:15 |
| ThomasD13 | I 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 |
| qschulz | kanavin: gnome 40 Google tells me? | 09:16 |
| ThomasD13 | And I use another image recipe to specify some other apps on the rootfs | 09: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 |
| kanavin | qschulz, none of the gnome components we carry in oe-core throw an error | 09:17 |
| ThomasD13 | But I don't understand what I have to too with the multiconfig? | 09:17 |
| ThomasD13 | *to do | 09: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 |
| ThomasD13 | JosefHolzmayr[m], yes, basically yes. Sharing majority of layers, but I need to specify different kernel/dtb | 09:18 |
| qschulz | JosefHolzmayr[m]: you're missing the fact that the current build is already multiconfig because of the Cortex-R5 | 09:18 |
| qschulz | ThomasD13: 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 |
| qschulz | and create a new image recipe | 09:19 |
| ThomasD13 | Exactly. I need somehow the same multiconfig in my new build | 09: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 |
| ThomasD13 | Okay, 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 |
| ThomasD13 | But 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 |
| ThomasD13 | ah okay | 09:24 |
| qschulz | JosefHolzmayr[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-r5 | 09:24 |
| qschulz | and they currently have board1_+cortex-r5 | 09: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 |
| ThomasD13 | Yes, 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 A72 | 09:25 |
| qschulz | JosefHolzmayr[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 |
| ThomasD13 | board 1 = (cortex a + cortex r), board 2 = (cortex a + cortex r) but with different kernel/dtb | 09:27 |
| qschulz | But 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 |
| qschulz | ThomasD13: 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 R | 09: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 |
| ThomasD13 | First 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 enough | 09:30 |
| qschulz | ThomasD13: 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 |
| qschulz | so 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 |
| ThomasD13 | One point to note: I don't want a hack to add fast second machine, and build these two machines with one call | 09:31 |
| ThomasD13 | qschulz, okay | 09:32 |
| qschulz | so 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 |
| ThomasD13 | qschulz, sorry you mean "except" or "example" ? | 09:36 |
| qschulz | I meant except | 09:42 |
| ThomasD13 | Ok 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 R | 09:43 |
| qschulz | ThomasD13: you already have a machine configuration file for the cortex-A | 09:44 |
| qschulz | so you just have to write your own machine configuration file for the cortex-A in your board_2 | 09:45 |
| qschulz | and 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_2 | 09:45 |
| *** chrfle <chrfle!~chrfle@217-209-195-249-no206.tbcn.telia.com> has joined #yocto | 09:46 | |
| ThomasD13 | ahhh okay - I think i get closer now :) | 09:47 |
| qschulz | well.. 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 example | 09:48 |
| qschulz | *"everything that is specific to board_1 and that is handled by the cortex-A" | 09:48 |
| ThomasD13 | Maybe 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 |
| qschulz | visible? | 09:50 |
| qschulz | you mean, do the machine configuration files have knowledge they're used in a multiconfig setup? | 09:51 |
| ThomasD13 | Yes | 09:51 |
| qschulz | They 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 recipe | 09:52 |
| qschulz | or at least that's my understanding | 09:52 |
| ThomasD13 | Okay, 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 |
| fbre | Hi! 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 |
| rburton | whatever WKS_FILE is set to defines the .wks that tells wic what to do | 09:56 |
| qschulz | ThomasD13: 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 :) https://www.yoctoproject.org/join/ | 09:57 |
| qschulz | fbre: classes/image_types_wic.bbclass is very likely to be the class doing that | 09:57 |
| ThomasD13 | Alright, I will talk with my boss in our next meeting ;) Maybe i'll spend myself a little tip | 09:59 |
| fbre | qschulz: 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.bbclass | 10:09 |
| jaskij[m] | That table doesn't work on mobile | 10:10 |
| fbre | I suppose it's somehow done via the tool 'parted' | 10:10 |
| qschulz | fbre: very likely something you can set in the WKS_FILE | 10:10 |
| qschulz | fbre: https://pretalx.com/media/yocto-project-summit-2020/submissions/GVU8HS/resources/Norbert_Kaminski_Wic_plugin_devel_0Lszv3V.pdf seems to indicate it's --fixed-size argument you should pass to your partition in the WKS_FILE | 10: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 |
| qschulz | jaskij[m]: because the partition is not the last one in the partition table | 10:12 |
| jaskij[m] | Fair | 10:12 |
| fbre | qschulz: What do you mean with "rootfs script"? | 10:17 |
| qschulz | fbre: it wa jaskij[m] and I assume they were talking about resize2fs or something similar | 10:23 |
| *** gsalazar_ is now known as gsalazar | 10:23 | |
| fbre | X) aaah, now I've found the location where the partitions are defined: It's in sources/meta-freescale/wic/... where I find a few ...wks.in 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 |
| fbre | This looks promising to add your suggested parameter --fixed-size there | 10:25 |
| *** mckoan is now known as mckoan|away | 10:29 | |
| fbre | Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type | 10:29 |
| fbre | Currently, 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 behind | 10:29 |
| fbre | dev/mmcblk1p1 * 128,0,1 1023,3,32 16384 195215 178832 87.3M c Win95 FAT32 (LBA) | 10:31 |
| fbre | dev/mmcblk1p2 1023,3,32 1023,3,32 196608 895629 699022 341M 83 Linux | 10:31 |
| fbre | dev/mmcblk1p3 1023,3,32 1023,3,32 895630 1419917 524288 256M 83 Linux | 10:31 |
| fbre | Anyway, it seems it's one of the ...wks.in files in sources/meta-freescale/wic/ . Now I need to find out which one of them is used for my i.mx8 | 10:33 |
| qschulz | fbre: if you bitbake -e your image recipe and look for WKS_FULL_PATH in htere, it'll tell you exactly where the file is | 10:34 |
| *** yocton <yocton!~quassel@2001:bc8:3386::1> has joined #yocto | 10:46 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 246 seconds) | 11:05 | |
| fbre | qschulz: thanx, bitbake -e outputs imx-imx-boot-bootpart.wks | 11:06 |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Read error: Connection reset by peer) | 11:07 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 11:08 | |
| fbre | I guess I have to reimplement wic/imx-imx-bootpart.wks.in in my own meta layer | 11:10 |
| fbre | imx-imx-boot-bootpart.wks.in | 11:10 |
| fbre | Is it possible to overload such wks.in file in my own meta layer? | 11:19 |
| fbre | ... by just copying to my meta layer and modify that? | 11:19 |
| rburton | yes | 11:22 |
| fbre | (y) thanx for your help! | 11:22 |
| wCPO | I'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 |
| rburton | yes | 11:27 |
| rburton | does it depend on gpgme-native though? | 11:28 |
| wCPO | rburton: It depends on gpgme | 11:29 |
| rburton | then yes, bug in the makefiles. | 11:30 |
| rburton | most likely not respecting LDFLAGS which point it at the native sysroot | 11:30 |
| wCPO | rburton: sounds likely. skopeo is a Go program, so very likely some missing/wrong flag | 11:31 |
| wCPO | I backported skopeo-native to hardknott, so could already be fixed. I will investigate | 11:31 |
| *** angolini <angolini!uid62003@id-62003.helmsley.irccloud.com> has joined #yocto | 11:35 | |
| fbre | hmm.... just copying imx-imx-boot-bootpart.wks.in to sources/my-meta/wic/ doesn't seem to have an effect of the wic.gz file I create with bitbake | 11:36 |
| fbre | (although I added that option --fixed-size 256M) | 11:37 |
| fbre | ...to for the boot partition and --fixed-size 512M to the rootfs partition | 11:37 |
| *** rfuentess__ is now known as rfuentess | 11:37 | |
| *** wooosaiii <wooosaiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC (Remote host closed the connection) | 11:38 | |
| *** wooosaiii <wooosaiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 11:39 | |
| barath | This 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 |
| rburton | no | 11:41 |
| Saur | barath: There is for runtime dependencies. | 11:41 |
| barath | hm | 11:41 |
| barath | what's it called for runtime dependenceis? | 11:41 |
| Saur | RDEPENDS:${PN} = "foo (>= 1.2.3)" | 11:42 |
| barath | thank you, I didnt know that | 11:42 |
| barath | on 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 |
| Saur | It is rarely used as typically when building with bitbake you have control of the layers and what versions the different recipes use. | 11:44 |
| barath | yeah, 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 etc | 11: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 |
| barath | it's "reported" in the sense that there's warnings (IIRC) printed about yocto choosing another version, but yeah | 11:53 |
| barath | maybe there's a QA trick I'm not aware of | 11:53 |
| barath | I'm concerned about missing this in automated CIs. shipping an incorrect openssl version can be kind of embarrassing :D | 11: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 notice | 11:55 |
| barath | I 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 CI | 11:56 |
| RP | barath: there is a open bug to make DEPENDS = "openssl (=X.Y.Z)" work but it hasn't happened as yet | 11:56 |
| RP | barath: we've also talked about making PREFERRED_VERSION mismatches fatal but haven't added any option as yet | 11:57 |
| barath | RP: thank you, I'll look for that | 11:57 |
| barath | Josef Holzmayr (TheYoctoJester): and that's a good point | 11:57 |
| JosefHolzmayr[m] | barath: :) | 11:57 |
| barath | for reference, this seems to be the bug about adding versioning support to depends https://bugzilla.yoctoproject.org/show_bug.cgi?id=8745 | 12:01 |
| barath | if someone were to take a crack at it, would it help to look at how the same was implemented for RDEPENDS? | 12:02 |
| RP | barath: we rely on the package managers for that so probably not :/ | 12:05 |
| barath | ah yes, that makes sense... alright | 12:05 |
| RP | barath: we've not implemented this as it is quite hard to do :( | 12:05 |
| barath | that's good to know at least, thx :) maybe I can justify it to management at some point | 12:09 |
| RP | barath: would be nice to have it, we've certainly talked about it for a while | 12:10 |
| *** paulg <paulg!~paulg@24-212-228-244.cable.teksavvy.com> has joined #yocto | 12:10 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 12:22 | |
| *** fleg <fleg!64bf4386e9@user/fleg> has quit IRC (Remote host closed the connection) | 12:33 | |
| *** fleg <fleg!64bf4386e9@user/fleg> has joined #yocto | 12:35 | |
| *** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has joined #yocto | 12:41 | |
| *** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> has quit IRC (Ping timeout: 246 seconds) | 12:44 | |
| *** yannd <yannd!~yann@88.120.44.86> has quit IRC (Ping timeout: 264 seconds) | 12:56 | |
| *** Guest46 <Guest46!~Guest46@147.161.171.108> has joined #yocto | 12:58 | |
| Guest46 | I'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 |
| Guest46 | GPT:31116287 !=31266815 | 12:59 |
| Guest46 | GPT:Alternate GPT header not at the end of the disk | 12:59 |
| Guest46 | GPT:31116287 !=31266815 | 12:59 |
| Guest46 | GPT: Use GNU Parted to correct GPT errors. | 12:59 |
| Guest46 | Is 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!~vermaete@ptr-figrjr0x4cx8oewa33u.18120a2.ip6.access.telenet.be> has joined #yocto | 13:02 | |
| vermaete | hi, | 13:02 |
| *** RP <RP!~richard@2001:8b0:aba:5f3c:96de:80ff:fe6d:2d2b> has joined #yocto | 13:03 | |
| vermaete | In case of a development at the master of all layers, does it still make sens to point SSTATE_MIRRORS to the sstate.yoctoproject.org? | 13:03 |
| vermaete | Or in other words, how often in that sstate.yoctoproject.org updated? | 13:04 |
| vermaete | (and who is doing it?) | 13:04 |
| *** yannd <yannd!~yann@88.120.44.86> has joined #yocto | 13:08 | |
| JPEW | vermaete: Yes, and the Yocto autobuilder populates it | 13:09 |
| vermaete | and is 'master' than 'the /dev' or 3.4? | 13:10 |
| vermaete | 3.4/ 04-Sep-2021 10:16 - | 13:10 |
| vermaete | dev/ 09-Aug-2017 15:42 - | 13:10 |
| vermaete | I only see the date of creation of the directory, i think. | 13:10 |
| JPEW | vermaete: https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html (see step #2) | 13:14 |
| *** vermaete <vermaete!~vermaete@ptr-figrjr0x4cx8oewa33u.18120a2.ip6.access.telenet.be> has quit IRC (Quit: Client closed) | 13:16 | |
| *** FredO <FredO!~willy562@bras-base-crnypq0201w-grc-06-76-69-222-77.dsl.bell.ca> has joined #yocto | 13:17 | |
| fbre | X) aaaah, I have to add WKS_FILE = "mystuff.wks.in" to my machine.conf file and then bitbake uses my partitioning with --fixed-size | 13:18 |
| *** rsalveti <rsalveti!uid117878@id-117878.uxbridge.irccloud.com> has joined #yocto | 13:28 | |
| ThomasD13 | When 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 |
| qschulz | ThomasD13: yes | 13:33 |
| qschulz | well, machine named j7-evm or if j7-evm is part of MACHINEOVERRIDES | 13:34 |
| qschulz | ThomasD13: https://pretalx.com/media/yocto-project-summit-2021/submissions/WTT3UV/resources/Demystifying_the_OVERRIDES_mechan_no6J6fb.pdf | 13:34 |
| ThomasD13 | qschulz, thanks that was my next question. If this kind of syntax only applies to machine configuration :) | 13:34 |
| vmeson | kanavin: 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 |
| vmeson | if 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!~mroussin@bras-base-qubcpq1306w-grc-07-184-145-217-104.dsl.bell.ca> has joined #yocto | 13:49 | |
| ThomasD13 | Has someone an idea how to debug this kind of error, when bitbake does not even start to use "-e" ? https://hastebin.com/uhayiyaxoy.sql | 13:55 |
| Wouter0100 | Is 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 |
| qschulz | ThomasD13: I assume DEF_TOOLCHAIN_PATH is not defined anywhere | 13:56 |
| fullstop | Just to confirm my suspicions, there is no way to modify a bbclass in a layer? | 13:56 |
| rburton | Wouter0100: don't tell users the other passwords? | 13:57 |
| qschulz | fullstop: you can override it but not use a bbappend mechanism if that's the question | 13:57 |
| fullstop | Right, so I can't extend what is already there -- it must be replaced entirely. | 13:57 |
| vmeson | ThomasD13: there's always strace .... | 13:57 |
| ThomasD13 | alright, I'll dig into that :) | 13:58 |
| fullstop | I can work around it, qschulz, thanks for the response. | 13:58 |
| Wouter0100 | rburton: I surely won't, but regardless I'd love to let them skip the `username` field if that'd be possible :) | 13:58 |
| qschulz | fullstop: 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 layers | 13:58 |
| rburton | Wouter0100: 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 user | 13:59 |
| fullstop | qschulz: 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 |
| fullstop | I can update the environment to include /sbin, but it turns it into a two-step process. | 13:59 |
| ThomasD13 | I 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 complicated | 14:00 |
| qschulz | ThomasD13: use MACHINEOVERRIDES for that ;) | 14:00 |
| qschulz | and... 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 |
| ThomasD13 | qschulz, I'll check what MACHINEOVERRIDES does exactly. This was just my first step to add additional machine config :S | 14:01 |
| qschulz | but yeah, vendor BSPs aren't known to be very easy/nice to work with | 14:01 |
| Wouter0100 | rburton: 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 |
| Wouter0100 | But I'm unable to find any way to do so :( | 14:02 |
| qschulz | Wouter0100: you could print the username right before the input for the user name | 14:02 |
| rburton | Wouter0100: so how are you going to login as management if the consoles are all pre-logged in? | 14:02 |
| rburton | you just need to change what init spawns on the consoles | 14:02 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:02 | |
| Wouter0100 | Oh noh, they're not pre-logged in :P. Sorry I may make it look confusing | 14:03 |
| rburton | so what do you want? | 14:03 |
| Wouter0100 | In 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 :D | 14:04 |
| rburton | Wouter0100: you might need to swap to proper getty, but getty can do that | 14:07 |
| Wouter0100 | Oh, interesting. Found something related to it in the Arch docs: https://wiki.archlinux.org/title/getty#Prompt_only_the_password_for_a_default_user_in_virtual_console_login | 14:08 |
| Wouter0100 | Thanks!! I'll have a look into that. | 14:08 |
| *** arlen_ <arlen_!~arlen@50-32-89-83.adr01.dlls.pa.frontiernet.net> has joined #yocto | 14:09 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Quit: Konversation terminated!) | 14:14 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 14:23 | |
| *** behanw <behanw!uid110099@id-110099.uxbridge.irccloud.com> has joined #yocto | 14:25 | |
| *** fbre <fbre!~fbre@145.253.222.69> has quit IRC (Quit: fbre) | 14:38 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 14:47 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:52 | |
| moto-timo | JPEW: immediately after login to phosh, it seems to fail because the connection is refused to gsd-media-keys... ring any bells? | 14:55 |
| JPEW | Hmm, no | 14:55 |
| JPEW | Looks like it's trying to talk to gnome-settings-daemon? | 14:56 |
| *** Guest46 <Guest46!~Guest46@147.161.171.108> has quit IRC (Quit: Connection closed) | 14:56 | |
| moto-timo | JPEW: right... so maybe the daemon isn't running (or maybe I forgot to install it) | 14:57 |
| JPEW | moto-timo: Ya, missing RDEPENDS probably | 14:57 |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Remote host closed the connection) | 15:00 | |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 15:00 | |
| kanavin | vmeson, I'll give it a shot | 15:04 |
| JaMa | RP: 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 somewhere | 15:04 |
| RP | JaMa: I don't have that. I'm a little puzzled why we wouldn't see that on the autobuilder | 15:05 |
| JaMa | here it fails with "ERROR: Cannot find Ninja" | 15:05 |
| JaMa | with no ninja on host, but i don't see it in HOSTTOOLS_NONFATAL so it shouldn't probably matter | 15:06 |
| RP | JaMa: qemu_6.0.0.bb has ninja-native in DEPENDS | 15:06 |
| ThomasD13 | Hmm.. I see that DEF_TOOLCHAIN_PATH is set by "toolchain-arm.inc". But nothing in the layers seem to reference that include. How is that possible? | 15:06 |
| JaMa | meta/recipes-devtools/qemu/qemu-native_6.0.0.bb overwrites that DEPENDS | 15:07 |
| ThomasD13 | ewdt@ewdt-server:~/oe/arago/sources$ grep -r toolchain-arm | 15:07 |
| ThomasD13 | Binary file meta-arago/.git/index matches | 15:07 |
| ThomasD13 | ewdt@ewdt-server:~/oe/arago/sources$ | 15:07 |
| RP | JaMa: so meson is probably missing there too? How did this ever work I wonder? :/ | 15:07 |
| rburton | ThomasD13: maybe its included as toolchain-${SOME_VARIABLE}.inc | 15:07 |
| JaMa | well it doesn't include qemu_6.0.0.bb only qemu-native.inc | 15:07 |
| ThomasD13 | ahhhhh... thx rburton | 15:08 |
| rburton | that was a guess | 15:08 |
| ThomasD13 | yes but make sense. I didn't have that possibility in my mind | 15:08 |
| JaMa | RP: 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 found | 15: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 found | 15:09 |
| JaMa | now qemu-native builds fine again with https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=2f3e0f020a132ddab636fa69c6f9ce2c5acb6285 | 15:12 |
| ThomasD13 | When I create a new machine configuration, do I have to link this somehow to a distribution? | 15:21 |
| RP | JaMa: thanks, I'll queue that | 15:27 |
| RP | JaMa: torn on that layer.conf patch, it is a pain but it does let us fix some of the dependencies | 15:29 |
| *** rcw <rcw!~rcwoolley@45.72.203.103> has joined #yocto | 15:30 | |
| vd | When 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 error | 15:44 |
| jaskij[m] | even though I'm running bitbake with multiconfig specifying a different machine | 15:45 |
| *** ThomasD13 <ThomasD13!~thomasd13@dsl01.212.114.255.148.ip-pool.nefkom.net> has quit IRC (Ping timeout: 252 seconds) | 15:46 | |
| *** zpfvo <zpfvo!~fvo@88.130.216.3> has quit IRC (Quit: Leaving.) | 15:50 | |
| *** zpfvo <zpfvo!~fvo@88.130.216.3> has joined #yocto | 15:50 | |
| *** zpfvo <zpfvo!~fvo@88.130.216.3> has quit IRC (Client Quit) | 15:51 | |
| *** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 15:51 | |
| *** zpfvo <zpfvo!~fvo@88.130.216.3> has joined #yocto | 15:51 | |
| *** zpfvo <zpfvo!~fvo@88.130.216.3> has quit IRC (Client Quit) | 15:52 | |
| *** zpfvo <zpfvo!~fvo@88.130.216.3> has joined #yocto | 15:52 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 15:54 | |
| *** frieder <frieder!~frieder@p50937620.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection) | 15:58 | |
| *** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto | 16:03 | |
| *** zpfvo <zpfvo!~fvo@88.130.216.3> has quit IRC (Quit: Leaving.) | 16:03 | |
| *** FredO <FredO!~willy562@bras-base-crnypq0201w-grc-06-76-69-222-77.dsl.bell.ca> has quit IRC (Quit: Leaving) | 16:04 | |
| JaMa | RP: 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 fix | 16:07 |
| JaMa | so there might be still enough time for external layers to fix possible fallback | 16:07 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 16:08 | |
| vd | JPEW: with whisk (or in your setup) what does a customer release version correspond to? the image recipe PV or something else? | 16:10 |
| vmeson | kanavin: that's good, thanks! | 16:12 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:13 | |
| JaMa | RP: got another strange ExpansionError in one of my builds, but don't know what exactly causes this (unless it looks really familiar to you): http://dpaste.com//EDB9LJMK7 | 16:15 |
| *** dev1990 <dev1990!~dev@78.10.71.240> has joined #yocto | 16:16 | |
| *** rfuentess__ <rfuentess__!~rfuentess@tmo-097-180.customers.d1-online.com> has joined #yocto | 16: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@172.58.190.196> has joined #yocto | 16:41 | |
| Tokamak | in 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 |
| rburton | Tokamak: manual inspection or automated rootfs qa? | 16:43 |
| Tokamak | e.g. i'd like to tweak /etc/passwd after all recipes have injected their accounts (just one use case) | 16:43 |
| Tokamak | automated apart of the build. intended for both qa and actual modification | 16:43 |
| rburton | so, automated | 16:44 |
| Tokamak | yes | 16:44 |
| rburton | you can do whatever you want in ROOTFS_POSTPROCESS_COMMAND | 16:44 |
| kergoth | if 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 chroot | 16:44 |
| rburton | but it does run in a pseudo-context so you are 'root' | 16:44 |
| Tokamak | thanks! that covers the passwd use case! will look into this | 16:45 |
| rburton | there's already optional commands available for that which manipulate passwd fwiw | 16:45 |
| Tokamak | is 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 |
| rburton | no but you can run stuff in qemu-user | 16:49 |
| rburton | but if firewall-cmd expects to be able to speak to a running firewalld, then that's not going to work | 16:50 |
| Tokamak | do you have an example of a hook to running qemu-user w/ing yocto? | 16:50 |
| rburton | the postinst intercepts like update_font_cache. they're designed to be executed by package management scripts, but show how to call qemuwrapper | 16:52 |
| Tokamak | true. 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@195.140.253.44> has quit IRC (Ping timeout: 252 seconds) | 16:54 | |
| rburton | and if you're lucky its a script so doesn't need qemu | 16:55 |
| *** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has joined #yocto | 16:56 | |
| Tokamak | thanks for the pointer to qemu class -> postinst_intercept | 16:57 |
| Tokamak | thanks for the insight, rburton | 16:58 |
| *** rfuentess__ <rfuentess__!~rfuentess@tmo-097-180.customers.d1-online.com> has quit IRC (Ping timeout: 246 seconds) | 16:59 | |
| RP | JaMa: something is putting None in the varlist, we should perhaps fix that, then you'd get a better error message | 17:00 |
| *** florian <florian!~florian@dynamic-093-132-078-233.93.132.pool.telefonica.de> has joined #yocto | 17:01 | |
| RP | JaMa: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=6609e989dde9119de933d1a1f178acf5eefd816e | 17:02 |
| rburton | Tokamak: alternatively, you can write a on-first-boot postinst script | 17:05 |
| *** rfuentess__ <rfuentess__!~rfuentess@tmo-097-180.customers.d1-online.com> has joined #yocto | 17:05 | |
| *** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has quit IRC (Ping timeout: 246 seconds) | 17:08 | |
| vd | How can I look up the IMAGE_LINGUAS value for spanish/spain? | 17:09 |
| rburton | es-es | 17:09 |
| vd | thank but where do I look up these values? | 17:10 |
| Tokamak | interesting. nice to know as well! | 17:10 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 17:19 | |
| *** florian <florian!~florian@dynamic-093-132-078-233.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 17:30 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 268 seconds) | 17:37 | |
| JPEW | vd: whisk doesn't really impose any sort of versioning like that | 17:40 |
| JaMa | RP: 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_URI | 17:41 |
| JaMa | The variable dependency chain for the failure is: SRCPV -> PV -> SRCPV -> PV -> WORKDIR -> T | 17:42 |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 17:42 | |
| JaMa | RP: 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 build | 17:42 |
| JaMa | RP: will let you know when I have some clearer reproducer | 17:43 |
| *** yates <yates!~user@fv-nc-f7af8b91e1-234237-1.tingfiber.com> has joined #yocto | 17:44 | |
| yates | basic question: is the do_patch task performed before or after do_configure? | 17:44 |
| JaMa | RP: 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, thanks | 17:52 |
| vd | yates: before, since you want to configure patch sources... | 17:52 |
| vd | patched* | 17:52 |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has quit IRC (Ping timeout: 268 seconds) | 17:53 | |
| *** florian <florian!~florian@dynamic-093-132-078-233.93.132.pool.telefonica.de> has joined #yocto | 18:02 | |
| rburton | yates: you can look stuff like that up trivially. base.bbclass: addtask configure after do_patch | 18:03 |
| vd | basically 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 #yocto | 18:05 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 18:07 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 18:11 | |
| *** ant__ <ant__!~ant@host-79-24-62-179.retail.telecomitalia.it> has joined #yocto | 18:42 | |
| *** rfuentess__ <rfuentess__!~rfuentess@tmo-097-180.customers.d1-online.com> has quit IRC (Ping timeout: 264 seconds) | 18:45 | |
| *** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> has joined #yocto | 18:45 | |
| JaMa | RP: meta/recipes-devtools/qemu/qemu-system-native_6.0.0.bb is also missing the dependencies | 18:56 |
| *** SalamaSalama[m] <SalamaSalama[m]!~moustafa5@2001:470:69fc:105::e6c4> has joined #yocto | 19:11 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Read error: Connection reset by peer) | 19:13 | |
| RP | JaMa: thanks for confirming. It is hopefully useful the new code shows the dependency chain :) (when it works properly!) | 19:43 |
| RP | JaMa: I'll tweak the qemu recipe again, thanks | 19:43 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 19:46 | |
| *** Belsirk <Belsirk!~rfuentess@2a01:598:88b8:1eac:d05d:6829:6438:4ef1> has joined #yocto | 19:46 | |
| *** rfuentess <rfuentess!~rfuentess@tmo-097-180.customers.d1-online.com> 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 #yocto | 19:51 | |
| ant__ | RP, JaMa: hi there | 19:51 |
| ant__ | RP: what is the 'best' way to implement a switch/case construct? python? | 19:52 |
| ant__ | see here https://github.com/OpenPLi/openpli-oe-core/blob/develop/meta-openpli/recipes-mediacenter/kodi/kodi_18.bb#L110 | 19:52 |
| ant__ | I must evaluate more tags and apply patch accordingly | 19:52 |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 19:53 | |
| ant__ | JaMa, ^ this is the evil enigma2 TV interface :) | 19:53 |
| ant__ | soon enigma3 they swear | 19: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 #yocto | 20:01 | |
| whuang0389 | lol i dont know which email I used to register for the open source summit | 20:01 |
| RP | ant__: python is probably easiest | 20: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 #yocto | 20: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!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Quit: Client closed) | 20:21 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 20:22 | |
| *** yannd <yannd!~yann@88.120.44.86> has quit IRC (Ping timeout: 264 seconds) | 20:39 | |
| *** opello <opello!~opello@about/csharp/opello> has joined #yocto | 20:46 | |
| opello | hi, 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 | |
| vd | Is it preferred to customize IMAGE_NAME or IMAGE_BASENAME? | 21:18 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Ping timeout: 260 seconds) | 21:19 | |
| *** florian <florian!~florian@dynamic-093-132-078-233.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 265 seconds) | 21:20 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 21:24 | |
| *** FredO <FredO!~willy562@bras-base-crnypq0201w-grc-06-76-69-222-77.dsl.bell.ca> has joined #yocto | 21:27 | |
| *** amitk <amitk!~amit@103.208.71.23> has quit IRC (Ping timeout: 264 seconds) | 21:28 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 21:33 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 21:33 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 21:55 | |
| *** florian <florian!~florian@dynamic-093-132-078-233.93.132.pool.telefonica.de> has joined #yocto | 21:59 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Ping timeout: 276 seconds) | 22:04 | |
| *** florian <florian!~florian@dynamic-093-132-078-233.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 22:34 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has joined #yocto | 22: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 #yocto | 23:09 | |
| *** florian <florian!~florian@dynamic-093-132-078-233.93.132.pool.telefonica.de> has joined #yocto | 23:12 | |
| *** dev1990 <dev1990!~dev@78.10.71.240> has quit IRC (Quit: Konversation terminated!) | 23:14 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 23:24 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 23:26 | |
| *** camus1 is now known as camus | 23:26 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 23:40 | |
| *** florian <florian!~florian@dynamic-093-132-078-233.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 23:42 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!