| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto | 00:00 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Quit: qschulz) | 00:32 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 00:34 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 00:41 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 00:42 | |
| *** camus1 is now known as camus | 00:42 | |
| *** zeddiii <zeddiii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 00:43 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 268 seconds) | 00:44 | |
| *** zeddiii <zeddiii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 272 seconds) | 01:06 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 01:07 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 01:22 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 258 seconds) | 01:24 | |
| *** camus1 is now known as camus | 01:24 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 01:30 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-140-204.home.otenet.gr> has joined #yocto | 01:32 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-140-204.home.otenet.gr> has quit IRC (Ping timeout: 256 seconds) | 01:34 | |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:f415:8836:bf4c:cedc> has joined #yocto | 02:14 | |
| whuang0389 | why? source poky/oe-init-build-env | 02:15 |
|---|---|---|
| whuang0389 | Error: The bitbake directory (/home/whuang/repos/tmp2/yocto/layers/bitbake) does not exist! Please ensure a copy of bitbake exists at this location or specify an alternative path on the command line | 02:15 |
| whuang0389 | meh nvm i refreshed my shell | 02:16 |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 255 seconds) | 02:19 | |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:f415:8836:bf4c:cedc> has quit IRC (Quit: Client closed) | 02:23 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 02:24 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 02:41 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 265 seconds) | 02:43 | |
| *** camus1 is now known as camus | 02:43 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 03:13 | |
| *** amitk <amitk!~amit@103.208.69.46> has joined #yocto | 03:21 | |
| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 276 seconds) | 03:26 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 04:55 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 04:55 | |
| *** camus1 is now known as camus | 04:55 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 04:57 | |
| *** yates <yates!~user@096-036-098-109.biz.spectrum.com> has quit IRC (Ping timeout: 255 seconds) | 05:39 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 252 seconds) | 06:12 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has joined #yocto | 06:12 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has quit IRC (Quit: Client closed) | 06:20 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:21 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 06:26 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 246 seconds) | 06:27 | |
| *** Neur0mante <Neur0mante!~Neur0mant@host-80-21-103-84.business.telecomitalia.it> has joined #yocto | 06:38 | |
| *** frieder <frieder!~frieder@mue-88-130-69-235.dsl.tropolys.de> has joined #yocto | 06:41 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:42 | |
| mihai | good morning! | 06:46 |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 06:46 | |
| *** zpfvo <zpfvo!~fvo@i5E86ACB8.versanet.de> has joined #yocto | 06:57 | |
| *** zyga_ is now known as zyga | 07:11 | |
| *** zyga_ <zyga_!~zyga@31.0.173.147> has joined #yocto | 07:40 | |
| *** hpsy <hpsy!~hpsy@85.203.15.7> has joined #yocto | 07:42 | |
| *** zyga <zyga!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Ping timeout: 255 seconds) | 07:43 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 07:44 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 07:53 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 07:54 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 07:58 | |
| LetoThe2nd | yo dudX | 08:01 |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 258 seconds) | 08:04 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 08:05 | |
| qschulz | howdy | 08:07 |
| RP | morning! | 08:19 |
| LetoThe2nd | RP: indeed. | 08:20 |
| qschulz | LetoThe2nd: I see that you're working hard on your dad jokes :) | 08:25 |
| *** zyga_ is now known as zyga | 08:26 | |
| florian | good morning | 08:27 |
| LetoThe2nd | qschulz: i am absolutely entitled to do so. | 08:29 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has joined #yocto | 08:32 | |
| Schlumpf | Hi all, is there any chance to append or override a do_compile_prepend() command of a .bb file in a .bbappend file? | 08:34 |
| Schlumpf | *overwrite | 08:35 |
| qschulz | Schlumpf: I don't think so | 08:35 |
| qschulz | so your only way out (at least, whichcomes to mind right now) would be to make do_compile[noexec] = "1" and then put the content of your do_compile into a task that is put after (or before?) do_compile | 08:37 |
| LetoThe2nd | "yo dawg, we heard you like overrides, so put overwrites in your override.... erm, nevermind." </xzibit> | 08:38 |
| qschulz | you can reuse do_compile from classes (if there are any), directly within that new task if you want (e.g. cmake_do_compile) | 08:38 |
| qschulz | Schlumpf: you can make your _prepend override-specific if it's possible for you to modify the recipe/bbappend in which it is set | 08:39 |
| qschulz | for variables, you could have used _remove though not nice | 08:40 |
| qschulz | I don | 08:40 |
| qschulz | 't think it exsist for tasks | 08:40 |
| Schlumpf | Many thanks, prepending the underlying class of the compile command did the job. | 08:52 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:07 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has quit IRC (Quit: Client closed) | 09:09 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 09:20 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has joined #yocto | 09:20 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 09:24 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 09:25 | |
| *** camus1 is now known as camus | 09:25 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has quit IRC (Quit: Client closed) | 09:30 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.96.230> has quit IRC (Read error: Connection reset by peer) | 09:43 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.96.230> has joined #yocto | 09:44 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.96.230> has quit IRC (Read error: Connection reset by peer) | 09:47 | |
| splatch | LetoThe2nd: are you dad now? | 09:48 |
| LetoThe2nd | splatch: "now".. since more than 7 years already. | 09:48 |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.96.230> has joined #yocto | 09:49 | |
| splatch | LetoThe2nd: guess I am too late to send gratulations ;-) | 09:50 |
| LetoThe2nd | splatch: heh, somewhat, yeah. | 09:51 |
| splatch | anyhow, I will throw a question which is somewhat close and far from yocto itself. OTA. I noticed there are multiple ways of doing it, there is rauc, mender, swupdate and others which handle it. Anyone has any remarks related to above or other things which would like to share? I am currently working with swupdate, but I am not entirely happy with it. | 09:53 |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.96.230> has quit IRC (Ping timeout: 258 seconds) | 09:54 | |
| rburton | an old colleage was very happy with swupdate for their setup | 09:55 |
| splatch | rburton: can you refer if it was microcontroller, embedded/gateway device, ipc or something else? | 09:55 |
| rburton | handheld device | 09:55 |
| qschulz | splatch: I think it would make sense to expose the reasons why you're not happy with swupdate | 09:55 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has joined #yocto | 09:58 | |
| splatch | qschulz: yeah, I think these are mainly on my end, yet I find it hard to fix. I see swupdate documentation quite sparse and sometimes written with assumption that reader knows the tool. In my case it is rather opposite. Comparing documentation itself, swupdate seems to be quite low in comparison to others. There were also some technical challanges such as USB update not working out of the box with warrior. | 10:00 |
| splatch | It did improve lately, yet I had to sacrifice fair amount of time to trace it down. Now I am stuck with a failing update which seems to be related to update image contents. As far I can find description how to verify signatures of signed files I can't find any pointers how to inspect image itself (beside format description), which I would assume kind of semi standard task. | 10:00 |
| splatch | I can't talk really about lover level stuff (ie bootloader update) cause I am stuck with things way above of the advanced features. | 10:01 |
| LetoThe2nd | splatch: well its a matter of perspective. swupdate is a classic "scratch your own itch" open source project, whereas mender is a commercial product. | 10:03 |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.96.230> has joined #yocto | 10:04 | |
| LetoThe2nd | i think rauc is somewhere in between | 10:04 |
| ejoerns[m] | splatch: despite these update frameworks solve many pain-points already, I would bet you run into issues during integration with all of them. Thus I would not take this instantly as a hint to switch the framework. Having all components working tightly together in a reliable way is probably almost all times at least a little bit of pain ;) | 10:04 |
| splatch | yes, I see this difference very well, I am well aware of such thing cause I do work with adoption of another oss project > product deployment on top of gardware | 10:04 |
| splatch | it looks like never ending story, especially when rolling updates are involved ;) | 10:05 |
| qschulz | splatch: just FYI, meta-swupdate is regularly updated, even for old releases of Yocto IIRC | 10:06 |
| ejoerns[m] | LetoThe2nd: no RAUC is fully open source, too ;) | 10:06 |
| qschulz | I had a look at thud support a few months ago and it was supporting the latest version of swupdate | 10:06 |
| qschulz | so if there are bugs in swupdate, it's pretty easy to stay up-to-date (at least on the side of Yocto :) ) | 10:06 |
| ejoerns[m] | qschulz: not sure if you should stick to thud when being able to update and caring for a minimus of security... ;) its EOL for some time now | 10:08 |
| splatch | that's quite good message since I do yocto stuff once a year (July-August) | 10:08 |
| LetoThe2nd | ejoerns[m]: i wasn't referring to the license model, but the different mission backgrounds. | 10:08 |
| splatch | I believe main battle goes not over the tool but service which can be sold on subscription basis. This is clearly what mander does, not sure about rauc, but there is one more tool I noticed which does pretty much the same | 10:09 |
| splatch | right, it is a blynkkk | 10:10 |
| ejoerns[m] | LetoThe2nd: I would expect both to have the same mission background ;) but would be interesting to hear how you perceive this difference :) | 10:11 |
| LetoThe2nd | ejoerns[m]: "both" when there are already three things mentioned? ;-) | 10:12 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Remote host closed the connection) | 10:12 | |
| ejoerns[m] | splatch: yes, mender has both an open source and a supscription part. And it focuses on deployment / hosting services which swupdate and RAUC does not. The full capability of mender you will probably only get with the paid service. but you could also use their server infrastructure and use a custom update client (at least theoretically) | 10:13 |
| ejoerns[m] | LetoThe2nd: To my understanding the pool of 'fully open source' was already shrunken to swupdate + RAUC ;) | 10:14 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 10:15 | |
| qschulz | ejoerns[m]: not my problem anymore :) (re: EOL) | 10:15 |
| splatch | ejoerns[m]: at scale I am currently are I am far from looking for paid options (I pay with own pain if necessary), if I would have 1000s of devices then yes, their model would simplify my life. Since I expect 10 units deployed this/next year I will rather stay with USB or manunal update. | 10:15 |
| splatch | what I actually liked in mender way was clear separation of update steps and "hooks" which you in theory could get into with scripts and so on. For swupdate I do see pre/post hooks alone and nothing more. | 10:16 |
| qschulz | splatch: you can write your own handlers in swupdate, so feel free to implement what you want for your scripts ;) | 10:18 |
| LetoThe2nd | ejoerns[m]: hehe yes, but i'm not gonna do the OSS zealot thing there. so i am purely looking at the background/mission statements, which sound to me a lot like: 1)swupdate: scratch-your-own-itch by stefano. others are invited to use it, but its not the main goal. 2) rauc: make-a-product-to-solve-own-problem by ptx. it being a product means that it being used by others is at least encouraged. 3) mender: create a product and sell | 10:18 |
| LetoThe2nd | it. the OSS part seems to be merely a door opener/sales argument. | 10:18 |
| LetoThe2nd | ejoerns[m]: please note that this is specifically my own personal perception of things, which might or might not be correct. | 10:19 |
| splatch | there are cases where oss is in theory needed to sell since recipient can think of switching vendor, it barely happens but public/military sector could favor such a way | 10:19 |
| *** Neur0mante <Neur0mante!~Neur0mant@host-80-21-103-84.business.telecomitalia.it> has quit IRC (Ping timeout: 246 seconds) | 10:20 | |
| LetoThe2nd | "it all depends." (TM) | 10:21 |
| splatch | qschulz: first, I need to get two or three steps 1) understand the tool 2) understand its apis 3) understand (read as learn) C or Lua. Then I will be set! | 10:21 |
| *** Neur0mante <Neur0mante!~Neur0mant@host-80-21-103-84.business.telecomitalia.it> has joined #yocto | 10:23 | |
| ejoerns[m] | LetoThe2nd: thanks for this insight :) I don't want do comment or rate this as I am not really an independent observer but it's interesting to hear ;) | 10:27 |
| splatch | now, as I did engage some of you I will throw my trouble :) | 10:28 |
| splatch | https://gist.github.com/splatch/434a8bd842d61033e017f6a1e0cc45a3 | 10:28 |
| splatch | uname returns different result than modules packaged with update image, update image is feed from .ext4.gz or direct.p2.gz (another invention through custom patch to wic), both result in same trouble. Missalignment of kernel version and modules. | 10:29 |
| splatch | my build/layer is configured wih PREFERRED_VERSION_linux-intel="5.10%" and PREFERRED_PROVIDER_virtual/kernel = "linux-intel" | 10:30 |
| LetoThe2nd | ejoerns[m]: :) | 10:30 |
| splatch | I can't find really any references to 4.19.80, this is really an previous system release running on the device. | 10:31 |
| splatch | do I have some boot trouble or something? | 10:31 |
| splatch | first line of my dmesg says [ 0.000000] Linux version 4.19.80-intel-pk-standard (oe-user@oe-host) (gcc version 8.3.0 (GCC)) #1 SMP PREEMPT Mon Jul 13 12:50:56 UTC 2020 | 10:32 |
| splatch | so it is wrongly booted | 10:32 |
| ejoerns[m] | splatch: you could inspect the image you build and then packed into the update to see if that contains the expected artifacts. This will probably tell you if its a build-system issue or if something during the update went wrong | 10:32 |
| splatch | the more I look into it the more I am convinced it is my mistake, cause swupdate does the flashing and does switch partitions just fine, what goes odd is a boot argument. | 10:33 |
| LetoThe2nd | splatch: so you are having a "boot argument" muahahahaha | 10:35 |
| * LetoThe2nd feels mightly proud to get the dad joke thing done so well! | 10:35 | |
| splatch | das klasik! https://www.youtube.com/watch?v=RYQUsp-jxDQ | 10:42 |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 10:45 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 258 seconds) | 10:46 | |
| *** camus1 is now known as camus | 10:46 | |
| splatch | LetoThe2nd: so, there is a thing with a boot, my first image did not have fsck enabled by default and now I'd like to fix it. I've tried to enable it via kernel argument coming from wic bootloader options. While it will fix issue with new installations where I flash image I would need to do a bootloader update with older installations. I found a way to compile in fsck into kernel commandline options, yet I | 10:48 |
| splatch | am not certain what happens later with it. | 10:48 |
| dvorkindmitry | may I set PACKAGE_FEED_ARCHS in the machine config, not in distro (I have MC: configuration)? | 10:53 |
| splatch | .. looks like I will have to update bootloader anyway.. | 11:08 |
| *** zpfvo <zpfvo!~fvo@i5E86ACB8.versanet.de> has quit IRC (Ping timeout: 265 seconds) | 11:11 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 11:14 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 11:17 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 246 seconds) | 11:18 | |
| *** camus1 is now known as camus | 11:18 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 11:27 | |
| *** zpfvo <zpfvo!~fvo@i5E86ACB8.versanet.de> has joined #yocto | 12:29 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has quit IRC (Quit: Client closed) | 12:44 | |
| v2d | hi all -- does a multiconfig configuration file takes precedence over a machine configuration file, or the opposite? | 12:54 |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has joined #yocto | 12:56 | |
| LetoThe2nd | v2d: best to think of a mc as "an additional local.conf customization" | 12:56 |
| LetoThe2nd | v2d: hence, it technically can overwrite anything that the machine config sets, but its a rather bad practise i'd say. | 12:56 |
| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 12:57 | |
| v2d | LetoThe2nd it seems like a good idea to isolate customer configuration such as defining a different TMPDIR and tweaking the default image (for different keys or password for example) | 12:58 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has joined #yocto | 12:59 | |
| LetoThe2nd | v2d: "it depends" (TM) (as usual) | 12:59 |
| v2d | so you can build mc:customer:hw-default-image or something.We'll see how it goes | 13:01 |
| JPEW | v2d: This is exactly what we do. In fact, we even wrote a tool to manage it for you: https://github.com/garmin/whisk | 13:02 |
| qschulz | JPEW: you're everywhere :D | 13:04 |
| LetoThe2nd | JPEW: i hereby declare that "whiskex" means "building in pyrex using whisk". | 13:07 |
| * LetoThe2nd is off whiskexing. | 13:07 | |
| JPEW | LetoThe2nd: Well, whisk *does* have "native" Pyrex support, for obvious reasons :) | 13:08 |
| JPEW | https://github.com/garmin/whisk#building-in-a-container | 13:08 |
| LetoThe2nd | who cares about real support when we can have fun with crazy names instead? | 13:09 |
| JPEW | LetoThe2nd: Next time I need to name something, I'm going to ask you.... I find it one of the hardest parts :) | 13:10 |
| *** pinpox <pinpox!~pinpox@v2202101107577140883.nicesrv.de> has joined #yocto | 13:10 | |
| LetoThe2nd | JPEW: yes please! | 13:11 |
| * paulg wonders what happened to LetoThe1st | 13:11 | |
| JPEW | As it happens, our company even has a mild fascination with umlauts ;) | 13:11 |
| v2d | I'm currently using kas, but I'll keep an eye on whisk | 13:12 |
| LetoThe2nd | paulg: according to my persona folklore, he was my gradfather and died while carrying out a suicidal assault on baron wladimir harkonnen, shortly after sending my grandmother and father off into the desert to seek refuge with the fremen. | 13:13 |
| JPEW | Maybe I should start on those books.... I ran out of my usual reading fodder | 13:14 |
| LetoThe2nd | JPEW: unless you are into a somewhat weird scifi-politics conglomerate which decays into weird musings on violence, drugs and various "adult" mindwashing techniques, don't do. | 13:16 |
| JPEW | LetoThe2nd: Ah... maybe I'll just watch the movie instead then :) | 13:18 |
| LetoThe2nd | JPEW: well my nickname has a kind of personal history, but in a nutshell, the character is a 3500year old sandworm, god emperor of the known universe and quite the asshole. felt appropriate. | 13:19 |
| JPEW | LetoThe2nd: You've aged well | 13:20 |
| LetoThe2nd | thanks. | 13:20 |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 13:20 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 268 seconds) | 13:21 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 13:21 | |
| paulg | Stay away from Fred Ward and Kevin Bacon. | 13:23 |
| LetoThe2nd | paulg: ? | 13:24 |
| paulg | https://www.imdb.com/title/tt0100814/?ref_=nm_flmg_act_63 | 13:25 |
| paulg | Spoof sci fi of the 1990s where they go on a killing spree of giant sandworms. | 13:26 |
| LetoThe2nd | sounds perfectly sensible to me. | 13:27 |
| RobertBerger | @LetoThe2nd: Oida. A much more interesting question is why LetoThe2nd is not called LetoThe3rd. The answer is here: http://www.faqs.org/faqs/sf/dune-faq/part1/ | 13:28 |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Remote host closed the connection) | 13:29 | |
| LetoThe2nd | RobertBerger: little to add. | 13:30 |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 272 seconds) | 13:32 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Quit: Leaving) | 13:38 | |
| *** ant__ <ant__!~ant@host-195-31-129-205.business.telecomitalia.it> has joined #yocto | 13:40 | |
| dvorkindmitry | may I set PACKAGE_FEED_ARCHS in the machine config, not in distro (I have MC: configuration)? | 13:42 |
| JPEW | RP: I just send the oe-core patch to add the command line compression tools, which should allow the bitbake patch to add the compression classes to be added also | 13:43 |
| override | has anyone here setup docker on osx and be able to mount the usb port for a dev boards? | 13:44 |
| RP | JPEW: cool, thanks. I should queue some tests | 13:44 |
| RP | JPEW: although I guess we'll need a new buildtools first and upgrades to the workers (and docs updates) | 13:44 |
| JPEW | RP: Ya, probably | 13:44 |
| *** angolini <angolini!uid62003@id-62003.brockwell.irccloud.com> has joined #yocto | 13:46 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto | 13:56 | |
| manuel1985 | This is totally offtopic, but I had registered manuel1985 on NickServ on Freenode. Now NickServ tells me that username is no longer registered. I was using it at least once a week. Did other peoples nicknames get unregistered as wel? | 14:08 |
| LetoThe2nd | manuel1985: freenode is dead. thats it. | 14:09 |
| JPEW | RP: Ok, I verified that pzstd output is the same regardless of the number of threads used, so that's good. I think I misunderstood the way it does parallel compression | 14:10 |
| zeddii | manuel1985: yah. they did that to everyone (as near as I could tell). I didn't even bother re-registering mine | 14:10 |
| *** Neur0mante <Neur0mante!~Neur0mant@host-80-21-103-84.business.telecomitalia.it> has quit IRC (Ping timeout: 246 seconds) | 14:12 | |
| manuel1985 | zeddii? wtf? Seriously? I was under their impression their new owner would like to keep the freenodes market value = user count high (for whatever he intends to do with Freenode), and that runs totally contrary to that. Must have lost his mind. | 14:12 |
| manuel1985 | Didn't re-register either. In the meantime, all channels I attend have higher user count on libera.chat than on Freenode. Not going to sabotage that by staing on Freenode. | 14:13 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:14 | |
| kanavin | manuel1985, you would do well to read this https://lwn.net/Articles/857140/ | 14:16 |
| kanavin | zeddii, ^^^ | 14:16 |
| * zeddii is aware | 14:16 | |
| yates_home | is there a way to clean all the state info for a specific recipe? | 14:17 |
| JPEW | yates_home: `bitbake -c cleanall <RECIPE>` | 14:17 |
| yates_home | JPEW: cool, thanks! | 14:18 |
| qschulz | -c cleansstate if you don't want to remove the sources from the DLDIR | 14:20 |
| yates_home | aha. | 14:20 |
| yates_home | too late, but i guess this recipe's source wasn't that big. then again, i'm lucky to have a 1 Gbps pipe up/dn | 14:21 |
| qschulz | show-off :) | 14:22 |
| yates_home | :) yah! | 14:22 |
| yates_home | we had the good fortune to be a special test neighborhood for Ting out of Canada (i live in the US) | 14:23 |
| yates_home | otherwise i'd still be on Centurylink's 8 Mbps dn/ 0.8 Mbps up... | 14:24 |
| RP | JPEW: great, that matches what I thought/hoped! :) | 14:27 |
| qschulz | JPEW: re: SSH_AUTH_SOCK on pyrex... I think it's an issue with a check on the host key of the git server | 14:28 |
| JPEW | qschulz: Ah, that makes sense | 14:29 |
| JPEW | qschulz: We bind mount ~/.ssh into the container locally to fix that | 14:29 |
| qschulz | JPEW: yeah... trying to avoid that specifically | 14:30 |
| qschulz | though... I could mount the ssh_known_hosts :) | 14:30 |
| *** champagneg <champagneg!~champagne@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 14:30 | |
| JPEW | qschulz: Ya, people get nervous about bind mounting .ssh into a random container | 14:30 |
| kanavin | RP, JPEW I was slightly worried that changing rpm to use zstd would also cause non-reproducibility | 14:31 |
| JPEW | qschulz: FAQ covers this actually: https://github.com/garmin/pyrex#faq | 14:31 |
| kanavin | I have a WIP patch for that | 14:31 |
| kanavin | (waiting for rpm 4.17 release) | 14:31 |
| JPEW | kanavin: Nice. Does it use parallel compression? | 14:31 |
| kanavin | JPEW: yes | 14:32 |
| qschulz | JPEW: are you RTFM'ing me 😱 | 14:32 |
| qschulz | (you would be right :) ) | 14:32 |
| kanavin | JPEW: it does not use parallel decompression, but even then it's very quick - I'm actually unsure how much pzstd would help here | 14:32 |
| JPEW | kanavin, RP: Although I think there might be repro issues if different distros have different default compression levels... I wasn't sure if I should be explicitly forcing a compression level instead of letting is use the default | 14:33 |
| kanavin | JPEW: rpm can set both compression level and number of threads to use explicitly | 14:33 |
| kanavin | for zstd | 14:34 |
| kanavin | JPEW, RP setting the compression level explicitly is important, as there is a tradeoff between compression speed vs artefact size to be made | 14:35 |
| JPEW | kanavin: Ok, I'll rework my patch to do that.... I was leaning that way anyhow | 14:36 |
| kanavin | JPEW, but on the other hand, the lower levels are *very* quck | 14:36 |
| kanavin | an order of magnitude faster than e.g. xz | 14:36 |
| kanavin | try on a large data set, several gigs or so! | 14:36 |
| JPEW | kanavin: Ya. I'm warming up to zstd as one of the best general purpose compressors. It has quite a wide range of speed/size tradeoff | 14:37 |
| kanavin | JPEW, I think we should use zstd throughout yocto | 14:37 |
| JPEW | kanavin: Almost as fast as lz4 on the one hand, but can get really small if you take the time | 14:38 |
| kanavin | sstate, packages, and the SDKs | 14:38 |
| JPEW | Someone was working on zstd for sstate | 14:38 |
| kanavin | with disk storage and network speeds growing much quicker than CPU speeds, I think it's better to opt towards large file sizes and faster builds/installs | 14:40 |
| JPEW | kanavin: Ya, that's what my goto has been lz4 in the past | 14:40 |
| kanavin | installing an SDK in 10 seconds instead of 2 minutes is awesome (yes, I verified) | 14:40 |
| kanavin | making do_populate_sdk complete in half the time is great too (verified that one as well) | 14:41 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 14:47 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 14:47 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-04-184-148-236-79.dsl.bell.ca> has joined #yocto | 14:50 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 14:51 | |
| *** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Ping timeout: 252 seconds) | 14:54 | |
| *** sgw <sgw!~swold_loc@user/sgw> has joined #yocto | 14:55 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 14:56 | |
| *** ant__ <ant__!~ant@host-195-31-129-205.business.telecomitalia.it> has quit IRC (Ping timeout: 245 seconds) | 14:57 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-14-249.ssp.dialog.net.pl> has joined #yocto | 15:00 | |
| yates_home | ok i finally got my QA problems fixed | 15:00 |
| yates_home | it was NOT just matter of setting FILES_${PN} | 15:01 |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Remote host closed the connection) | 15:01 | |
| yates_home | thanks rburton et al. for your help | 15:01 |
| qschulz | yates_home: well, what was it then :) | 15:08 |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has quit IRC (Remote host closed the connection) | 15:15 | |
| * RP has been playing making a "defval" override namespace which the += =+ and = operators operate within, a weakval namespace for ??= and seeing if that could be used as a migration pathway to improve the syntax consistency | 15:20 | |
| fray | witht he names spaces it would eval weak then def (or def and if defined not weak) right? | 15:23 |
| RP | fray: def would override weak, yes | 15:23 |
| RP | the names are just for the experiment. Sadly this thing is far from simple and doesn't even pass parsing | 15:23 |
| JPEW | RP: So, `FOO += "bar"` is syntactic sugar for `FOO_defval_append = " bar"` ? | 15:25 |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 15:30 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.200> has quit IRC (Quit: Client closed) | 15:34 | |
| RP | JPEW: yes, exactly | 15:34 |
| RP | the trouble is I think the code needs to handle XXX_append = and XX_append_YYY = as not defval :) | 15:35 |
| RP | There is some idea in my mind trying to escape here but the code isn't working and I think I'm losing track of the original objective :/ | 15:36 |
| RP | Taking this to a second level of crazy, there could be a defval-recipe, defval-bbclass, defval-conf or similar so the context of the expressions becomes controlled by overrides too | 15:37 |
| JPEW | I think I'm oversimplifying this, but does that make defval and weakval weaker overrides? | 15:37 |
| RP | JPEW: effectivelu | 15:37 |
| JPEW | So there's essentially no such thing a "bare" variable (one with no overrides) | 15:38 |
| RP | JPEW: in that model, correct | 15:38 |
| JPEW | RP: I don't understand the comment about XXX_append and XXX_append_YYY | 15:39 |
| RP | It struck me that we were always fighting for the right ordering with ?= = and ??= and yet we have an extensible ordering model with overrides | 15:39 |
| JPEW | RP: Ya, I was (naively?) thinking you could add "defval" and "weakval" to overrides and make the parse translate += et. al. to other syntax as a simple test | 15:40 |
| JPEW | add to OVERRIDES that is | 15:40 |
| RP | JPEW: that is exactly what my test code does! :) | 15:40 |
| RP | JPEW: XXX_append becomes XXX_append_defval in my code | 15:41 |
| JPEW | When you do "XXX_append += " or on purpose? | 15:41 |
| RP | then worry about what happens to OVERRIDES_append as I didn't inject the default OVERRIDES as OVERRIDES_defval | 15:41 |
| RP | JPEW: I made it happen on any = operator which is now clearly a bad choice | 15:42 |
| RP | (ignoring flags) | 15:42 |
| JPEW | Ah, ya. I would have not expected it to apply to any operator.... but I can see how teasing out when it should apply to defval and when it should not would be difficult | 15:43 |
| RP | JPEW: I think I have a better idea now! | 15:43 |
| JPEW | Presumably, you want `FOO = "bar"` => `FOO_defval = "bar"`, but `FOO_append = "bar"` should not become `FOO_append_defval = "bar"`? | 15:44 |
| RP | JPEW: right | 15:45 |
| RP | I think the other problem is where I'm intercepting this, i.e. in the ast rather than in setVar where some knowledge of what is going on is lost | 15:45 |
| JPEW | RP: Ya, I kinda like it there better though, if += is it really supposed to be just a syntatic sugar | 15:47 |
| RP | Also, FOO_override = bar shouldn't become FOO_override_defval and that is probably the deal breaker as we don't know all overrides in advance | 15:47 |
| JPEW | RP: Right... I suppose you'd have to use the "this might be an override?" logic of lower case vs upper case? | 15:48 |
| RP | JPEW: for processing at this level it becomes totally impractical | 15:48 |
| JPEW | for what reason? | 15:49 |
| RP | JPEW: we normally defer this to getVar time but with these code changes you'd have to inject all possible combinations in and then determine later | 15:50 |
| JPEW | RP: becomes some overrides are overrides and some are operators? | 15:52 |
| JPEW | And the parsing code can't really tell which is which? | 15:53 |
| RP | JPEW: effectively, yes | 15:55 |
| *** manuel_ <manuel_!~manuel198@62.99.131.178> has joined #yocto | 15:55 | |
| *** manuel_ <manuel_!~manuel198@62.99.131.178> has quit IRC (Client Quit) | 15:55 | |
| RP | I wish we could require a change to the metadata to mark overides | 15:56 |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Ping timeout: 255 seconds) | 15:57 | |
| JPEW | RP: Or use something other than "_" to separate overrides | 15:58 |
| JPEW | Something dedicated | 15:58 |
| RP | JPEW: right, that is what I mean by mark | 16:00 |
| JPEW | RP: Ah, ok. | 16:00 |
| RP | well, one possible result of the idea | 16:00 |
| fray | at one of the YP meetings we'd talked about ":" or "::" but that got shot down.. "we don't want to look like...." | 16:01 |
| RP | do_install{native} = "xxx" ? | 16:02 |
| RP | gets fun with do_install_native_append_poky_pn-lttng = "" though | 16:03 |
| fray | my nit-picking worry about {} it looks a lot like [] ... | 16:03 |
| fray | but ya, the multiple overrides with operators mixed in is a big issue | 16:04 |
| *** zpfvo <zpfvo!~fvo@i5E86ACB8.versanet.de> has quit IRC (Quit: Leaving.) | 16:04 | |
| RP | do_install{native} += {poky} {pn-lttng} = "" | 16:04 |
| RP | not good :) | 16:04 |
| fray | that looks like a parsing nightmare | 16:04 |
| RP | fray: probably easier than what we have today! | 16:05 |
| fray | I was referring to machine and human parsing | 16:06 |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has joined #yocto | 16:09 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 16:19 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:20 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 255 seconds) | 16:26 | |
| *** nerdboy <nerdboy!~nerdboy@107.127.25.226> has joined #yocto | 16:29 | |
| *** champagneg <champagneg!~champagne@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC (Quit: WeeChat 2.3) | 16:31 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Client Quit) | 16:32 | |
| *** nerdboy <nerdboy!~nerdboy@107.127.25.226> has joined #yocto | 16:33 | |
| *** gchamp <gchamp!~champagne@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 16:35 | |
| *** frieder <frieder!~frieder@mue-88-130-69-235.dsl.tropolys.de> has quit IRC (Remote host closed the connection) | 16:40 | |
| *** v2d <v2d!~v2d@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Ping timeout: 246 seconds) | 16:53 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 255 seconds) | 17:00 | |
| yates_home | qschulz: sorry, just saw your query. give me a few and i'll post it | 17:09 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 17:14 | |
| yates_home | qschulz: http://www.digitalsignallabs.com/downloads/mainline-kernel-toolchain-build.pdf | 17:14 |
| *** nerdboy <nerdboy!~nerdboy@107.127.25.226> has joined #yocto | 17:21 | |
| yates_home | is the process by which the output from one recipe is separated into multiple packages called "package splitting" | 17:22 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 17:22 | |
| yates_home | ? | 17:22 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 17:23 | |
| yates_home | i do not know why it is not stated in the docs or the bitbake qa check error output that you might need to use something other than FILES_${PN} if the recipe is "packaged-split". | 17:23 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 17:25 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-135-066-231.93.135.pool.telefonica.de> has joined #yocto | 17:26 | |
| yates_home | or have i mis-identified the issue(s)? | 17:27 |
| yates_home | what i have now "works" at least | 17:28 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 17:28 | |
| yates_home | rburton: i was able to get that machine_dict info from the binutils | 17:34 |
| JPEW | RP: I was thinking something like: FOO.native.append | 17:35 |
| kergoth | RP: Can we avoid even the possibility of the difference between _override_append and _append_override in your work on this? That's a long standing annoyance that we should be able to get rid of by changing to this method of lazy evaluation, in theory | 17:36 |
| * kergoth back from 3 week road trip vacation, 4 days of driving 8 hours to get there, and then again to get home :) | 17:36 | |
| kergoth | I'm sore now | 17:36 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Ping timeout: 252 seconds) | 17:43 | |
| RP | kergoth: that kind of trip sounds painful! | 17:45 |
| RP | JPEW: hmm, possible | 17:45 |
| RP | kergoth: those two cases mean two different things and we have code which can use either. We could certainly block one of them at the parser level if we wanted | 17:46 |
| JPEW | I think a table describing the behavior would be helpful.... I can't keep the straight: https://www.openembedded.org/wiki/Proposed_New_Bitbake_Syntax | 17:54 |
| JPEW | *keep is straight | 17:54 |
| RP | JPEW: I don't think we're in a position to write something like that yet :/ | 17:55 |
| RP | (since what I have doesn't really work) | 17:55 |
| JPEW | Ya, I wasn't trying to be official... just trying to understand the conversation (if the Wiki isn't a good spot, somewhere else would be fine) | 17:56 |
| RP | My hope was to be able to move to a more consistent model where things are all deferred rather than the current mix of deferred an immediate | 17:57 |
| RP | JPEW: I tweaked that table for how it needs to operate | 17:59 |
| JPEW | RP: Ah, I see why that is really complicated | 18:00 |
| kergoth | I think "Append "bar" to value of FOO_o if o is in OVERRIDES | 18:00 |
| kergoth | " should be FOO, not FOO_o, yes? | 18:00 |
| RP | kergoth: yes, correct | 18:01 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 18:01 | |
| JPEW | kergoth: I think so. I'll fix it | 18:01 |
| kergoth | I'd love to see an override syntax so FOO{o} is just another set of defval, just a conditional one, and FOO{o} += is no different than FOO_append_o.. but that'd likely be a later extra unless the new syntax is required otherwise. FOO_o_append vs FOO_append_o is a common source of confusion. but could only fix that with a new syntax since it'd change the semantics :) | 18:02 |
| kergoth | probably not worth doing now unless we already break to a new opt-in syntax | 18:03 |
| kergoth | I wish things weren't always so complicated :) | 18:04 |
| kergoth | hard to make any changes without unforeseen consequences | 18:04 |
| RP | kergoth: it might be worth hacking the parser to warn on FOO_o_append and see how many cases there are, see if we could just remove them all | 18:04 |
| JPEW | RP, kergoth: Is the idea that `FOO_o += "bar"` is preferred over `FOO_o_append = "bar"`? | 18:05 |
| kergoth | could be a good idea regardless | 18:05 |
| *** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has quit IRC (Ping timeout: 252 seconds) | 18:05 | |
| RP | JPEW: the idea is that appending to an overridden variable is likely user error on the most part | 18:06 |
| kergoth | if every operation is deferred, _append/_prepend would be redundant except that they'd have to happen last for compatibility, yeah? | 18:06 |
| kergoth | I feel like it's harder to wrap your head around "FOO_o = 'bar'" collapses later since we had to deal with ordering than to make it an operation against FOO right away, but we can't do that without knowing the overrides up front | 18:06 |
| kergoth | s/collapses/collapsing/ | 18:06 |
| RP | kergoth: the idea would be to make some of the operations effectively redundant and hence simpler, yes | 18:07 |
| RP | I'm struggling to spot <override>_append usage in OE-Core but one I did spot: meta/recipes-support/gmp/gmp_6.2.1.bb:EXTRA_OECONF_mipsarchr6_append | 18:11 |
| * RP suspects that line is just plain wrong | 18:12 | |
| JPEW | Maybe in that case, but I'm a little skeptical that FOO_o_append is always a bug | 18:16 |
| RP | JPEW: It isn't always but can you find real world use? | 18:16 |
| JPEW | Probably not with append, but probably with += | 18:16 |
| JPEW | *Challenge Accepted!* | 18:17 |
| RP | += is a totally different thing | 18:17 |
| RP | this is one of the problems :/ | 18:17 |
| JPEW | different because it is immediate? | 18:18 |
| RP | it only applies to the base non overridden value and it can be "unset" | 18:18 |
| kergoth | I think just because there's a real world use doesn't necessarily justify the existence of it, there are often other approaches that'd do | 18:19 |
| RP | kergoth: I'm just trying to see if there is actually any! | 18:19 |
| JPEW | OK, what's the difference between `FOO_o_append = " bar"` and `FOO_o += "bar"` | 18:19 |
| kergoth | that's a good first step, yes :) | 18:19 |
| RP | JPEW: in the new world or currently? | 18:20 |
| JPEW | Both | 18:20 |
| * JPEW I should probably try it instead of asking | 18:20 | |
| RP | JPEW: the issue is that FOO_o_append persists indefinitely whilst the latter is unset by FOO_o = "y" | 18:20 |
| JPEW | RP: Ah, right. And in the new world? | 18:21 |
| RP | JPEW: implementation of defvar dependent | 18:21 |
| RP | The question is whether we're trying to get the existing metadata to parse correctly or not | 18:22 |
| * JPEW updates the stable with my understanding | 18:23 | |
| JPEW | Ugh I cannot type today. I updated the *table* | 18:23 |
| RP | I was hoping we could move to a deferred model and then update syntax to adapt and simplify but I'm starting to think we probably have to break the metadata :( | 18:23 |
| * RP wondered where the ponies came from :) | 18:23 | |
| paulg | I was holding out for unicorns. | 18:24 |
| kergoth | Hmm, it is tempting to just drop support for _append/_prepend with the switchover and sidestep the issues, but then again, if we're going to break format compatibility, it'd be worth thinking about any other long standing issues with the format while we're at it | 18:25 |
| RP | JPEW: tweaked it | 18:26 |
| kergoth | I feel like the user's intention behind FOO_o +=, FOO_o_append, and FOO_append_o are all really the same, just the mechanism and implementation details vary in ways that tend to confuse, even if those of us who understand those details are able to leverage them in various ways. | 18:26 |
| RP | kergoth: agreed. I suspect we need to look case by case at changes though | 18:26 |
| JPEW | kergoth: It depends I think. If it is purely syntax changes, we might be able to implement a new parse, but keep the datastore etc. | 18:27 |
| RP | kergoth: right, exactly :/ | 18:27 |
| JPEW | RP: FOO_o_defvar makes my head hurt :) | 18:27 |
| RP | JPEW: you should see what this sample code did to the metadata | 18:28 |
| RP | I think this is going to go beyond syntax changes, I'm not sure we can avoid that :( | 18:29 |
| RP | kergoth: but basically you're right, we need to simplify the X ways of doing this into something simpler | 18:29 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Ping timeout: 255 seconds) | 18:30 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 18:31 | |
| kergoth | Hey, I wonder if this would be better or worse thant he proposed {} approach: `FOO = "bar" if o` or `FOO = "bar" if o in OVERRIDES`. it'd align with the ability to define an override if block | 18:31 |
| kergoth | s/approach/syntax/ | 18:31 |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 252 seconds) | 18:32 | |
| kergoth | proposed is a strong word for what's essentially brainstorming, but just a random other idea :) | 18:32 |
| RP | kergoth: if idea of multiple overrides variables makes my head hurt | 18:32 |
| kergoth | it is common for new users to go 'why isn't this just an if statement?' after all :) | 18:32 |
| kergoth | yeah, i'd say probably avoid that complecation. just 'if a' or 'if a and b' | 18:33 |
| * kergoth shrugs | 18:33 | |
| RP | its definitely food for thought | 18:33 |
| RP | JPEW: can you change proposed to brainstorming on that wiki page title just so that people don't get confused without the context here? | 18:35 |
| kergoth | That's a good idea, make it clear it's not an official proposal | 18:35 |
| JPEW | RP: sure! | 18:35 |
| JPEW | https://www.openembedded.org/wiki/New_Bitbake_Syntax_Brainstorm | 18:36 |
| paulg | RP, zeddii - seen any reports about qemu stalling on kernel reboot? I just reproduced it on vanilla yocto, using slightly older v5.10.43 ; can still get to qemu console, so qemu isn't completely borked. ; using the Ubuntu qemu binary and identical cmdline+images and the issue goes away. | 18:37 |
| RP | paulg: we've seen stall issues, some of them at poweroff | 18:38 |
| kergoth | RP: are you going to keep the behavior where FOO = "bar" would blow away existing pending +=/=+, or change those semantics such that `FOO = "bar"` updates the defvar and doesn't clear pending operations of any kind, but add your previously proposed command to do that explicitly, so that intention is explicit and clear? I rather like the latter | 18:39 |
| RP | paulg: I think I closed the bugs blaming the rcu stall | 18:40 |
| kergoth | if the latter, could we avoid the need for ??= at all? | 18:40 |
| paulg | nothing like that AFAIK ; perfectly normal shutdown ; last msgs seen is... | 18:40 |
| paulg | [ 35.643863] systemd-shutdown[1]: Rebooting. | 18:40 |
| paulg | [ 35.656070] reboot: Restarting system | 18:40 |
| paulg | [ 35.656780] reboot: machine restart | 18:40 |
| * kergoth ponders | 18:40 | |
| paulg | and then it just sits there sulking and pining for the fijords. | 18:40 |
| RP | kergoth: I'm really tempted by the latter too, I like the idea a lot. I just worry about how we migrate | 18:40 |
| kergoth | Hmm, can we check the current metadata to figure out where we rely on that behavior? | 18:41 |
| RP | paulg: does sound like some of the shutdown issues we've seen but it was never reproducible | 18:41 |
| kergoth | probably could in theory.. | 18:41 |
| RP | kergoth: probably in theory but I suspect we rely on that a lot | 18:41 |
| RP | kergoth: I found even the quilt-native recipe does fun stuff with overrides | 18:42 |
| RP | well, append and ordering | 18:42 |
| RP | kergoth: it wants to keep the do_configure_prepend and do_configure_append but change do_configure only for class-native :) | 18:42 |
| paulg | "shutdown -h now" works fine, and "runqemu nographic" falls out the bottom as expected. | 18:43 |
| kergoth | oof | 18:43 |
| RP | kergoth: its amazing how much encode the behaviours into the metadata :( | 18:44 |
| RP | paulg: hmm, don't know I'm afraid | 18:44 |
| kergoth | It really is. I wish we could more directly state what the recipe wants without having to always delve into the *how* of what bitbake is doing | 18:44 |
| paulg | RP, thanks -- I'll continue looking at it ; see if I can figure it out. | 18:45 |
| kergoth | That's part of why I've wondered about a python-based plugin mechanism. interact with actual python apis to change behavior when needed, outside the limitations of the format, so the actual metadata can focus on the what, not the how | 18:46 |
| JPEW | kergoth: It might useful to show what you would want to the syntax to actually look like | 18:46 |
| JPEW | kergoth: Having worked in a build system where you can "do whatever you want" with python (waf) I do not recommend it | 18:47 |
| JPEW | (maybe that's not what you had in mind, though) | 18:48 |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 18:49 | |
| kergoth | Eh, that's part of the issue, I don't think anyone knows exactly what we'd like to see, just what we don't like about what we do now :) | 18:49 |
| RP | What could work might be a new immediate directive which says "parse this file from here using this parser version" | 18:50 |
| RP | which would then allow us, file by file to move to a new format, assuming we can put things into the datastore in a way which is backwards compatible | 18:50 |
| kergoth | Yeah, I thought about that too. Then we can avoid the need for a different extension or hard break, but it'd complecate the parsing *and* metadata processing | 18:51 |
| kergoth | probably better than the alternatives, though | 18:51 |
| RP | it would also allow us to change the meaning of operators | 18:51 |
| JPEW | RP: Would a new extension be easier (".bb2")? | 18:51 |
| RP | JPEW: what is worrying me is things like inheriting classes and inc files | 18:51 |
| RP | this way you say explicitly which parser to use for a file and the way the parser works, it could probably be quite happy with that | 18:51 |
| JPEW | Ah, right | 18:52 |
| RP | e.g. if you want to use an OE-Core bbclass in v2 with metadata in a layer using v1 | 18:52 |
| JPEW | In the regard, I think it pretty much has to be a purely syntatical change... you can't change the datastore too much and still have it work correctly | 18:52 |
| kergoth | How will operations be applied when they're mixed and matched? What happens if a recipe inherits a class that uses the old syntax, or vice versa? | 18:52 |
| RP | kergoth: directive in the class would switch to the new version | 18:53 |
| RP | so basically the parser would change state for each file to v1 until told otherwise | 18:53 |
| RP | JPEW: I think you could do more than syntactical change with this | 18:53 |
| RP | e.g. in v2, += and _append could be the same | 18:54 |
| *** bunk <bunk!~bunk@debian/bunk> has quit IRC (Ping timeout: 246 seconds) | 18:54 | |
| JPEW | RP: Right, but that's changing how the AST behaves, not how the datastore is used? | 18:54 |
| RP | so the way it maps to the datastore would be dependent on the mode the parser was in | 18:54 |
| RP | JPEW: the behaviour of the datastore isn't really the problem | 18:54 |
| RP | the problem is wanting to simplfy the syntax | 18:55 |
| JPEW | Right, ya. That's what I was meaning by "syntatical changes"... you use the same datastore and populate it differently. Perhaps the wrong word | 18:55 |
| RP | It does depend on where you look at it from :) | 18:56 |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 18:56 | |
| *** bunk <bunk!~bunk@debian/bunk> has joined #yocto | 18:57 | |
| kergoth | RP: defaulting each file to v1 until explicitly opting in does sound like it'd work well. i imagine in the long term we'd switch the default to avoid needing extra boilerplate in every file indefinitely though :) | 18:58 |
| RP | kergoth: or use the file extension too maybe? | 18:59 |
| kergoth | could be worth considering the .conf vs .inc/.bb/.bbclass divide too, either now or later. the difference seems silly in retrospect. also '.conf' doesn't imply bitbake directly, as an extension | 18:59 |
| *** nerdboy <nerdboy!~nerdboy@107.127.25.227> has joined #yocto | 18:59 | |
| RP | kergoth: I do think we could make better use of that distinction at times... | 18:59 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 19:02 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 19:02 | |
| *** camus1 is now known as camus | 19:05 | |
| *** Guest46 <Guest46!~Guest46@cpe90-146-128-173.liwest.at> has joined #yocto | 19:09 | |
| *** Guest46 <Guest46!~Guest46@cpe90-146-128-173.liwest.at> has quit IRC (Client Quit) | 19:10 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 268 seconds) | 19:50 | |
| LetoThe2nd | is there any trick/shortcut to run -c testimage on a slirp connection? | 19:56 |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 20:05 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 258 seconds) | 20:07 | |
| *** camus1 is now known as camus | 20:08 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 20:11 | |
| *** amitk_ <amitk_!~amit@103.208.69.180> has joined #yocto | 20:32 | |
| *** florian_kc is now known as florian | 20:33 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-135-066-231.93.135.pool.telefonica.de> has joined #yocto | 20:35 | |
| *** amitk <amitk!~amit@103.208.69.46> has quit IRC (Ping timeout: 255 seconds) | 20:35 | |
| *** florian <florian!~florian@dynamic-093-135-066-231.93.135.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 20:38 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 20:40 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Quit: Leaving) | 20:42 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 20:44 | |
| *** florian <florian!~florian@dynamic-093-135-066-231.93.135.pool.telefonica.de> has joined #yocto | 20:49 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-135-066-231.93.135.pool.telefonica.de> has quit IRC (Ping timeout: 255 seconds) | 20:51 | |
| *** nerdboy <nerdboy!~nerdboy@107.127.25.226> has joined #yocto | 20:52 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 21:00 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 268 seconds) | 21:00 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 21:12 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 272 seconds) | 21:13 | |
| *** camus1 is now known as camus | 21:13 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 21:29 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 265 seconds) | 21:31 | |
| *** nerdboy <nerdboy!~nerdboy@107.127.25.225> has joined #yocto | 21:32 | |
| *** camus1 is now known as camus | 21:32 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-14-249.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 21:33 | |
| *** hpsy <hpsy!~hpsy@85.203.15.7> has quit IRC (Ping timeout: 255 seconds) | 21:35 | |
| splatch | qschulz: out of curiosity, do you know a recipe with swupdate + grub and switchable bzimage as this is root cause of my issue. The bootloader uses bzimage which is shipped with initial install (4.19). I found an example of tanowrt which does it by using two additional parititions and switching of bzimage partition together with rootfs. I traced also homeassistant which rely on rauc+buildroot and does | 21:38 |
| splatch | dynamic remounting. Finding something in between would be very helpful. | 21:38 |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC (Ping timeout: 252 seconds) | 21:44 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 245 seconds) | 21:52 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 258 seconds) | 21:55 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 21:56 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 21:59 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 22:03 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 22:39 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 22:42 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 22:42 | |
| *** nerdboy <nerdboy!~nerdboy@107.127.25.226> has joined #yocto | 22:52 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 265 seconds) | 23:02 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 23:22 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 23:23 | |
| *** camus1 is now known as camus | 23:24 | |
| *** mckoan_ <mckoan_!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto | 23:27 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-135-066-231.93.135.pool.telefonica.de> has joined #yocto | 23:27 | |
| *** nerdboy <nerdboy!~nerdboy@107.127.25.227> has joined #yocto | 23:28 | |
| *** mckoan|away <mckoan|away!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC (Ping timeout: 258 seconds) | 23:28 | |
| *** florian <florian!~florian@dynamic-093-135-066-231.93.135.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 23:31 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-135-066-231.93.135.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 23:47 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!