**** BEGIN LOGGING AT Thu Dec 12 02:59:58 2019
Dec 12 03:32:32 <tlwoerner> JPEW: w00t! wic :-D it's been on my list for a *long* time :-)
Dec 12 03:32:49 <JPEW> tlwoerner: Ya, me too ;)
Dec 12 03:33:09 <JPEW> wic all the things!
Dec 12 03:33:17 <tlwoerner> is it possible to reduce the duplication? can we pass the block device to wic for each MACHINE?
Dec 12 03:33:53 <tlwoerner> i can look into it, i just wanted to see if you knew one way or another
Dec 12 03:35:24 <JPEW> Not sure... I'm not really sure if the --ondisk actually matters
Dec 12 03:35:48 <JPEW> And, there might be another way to pass the kernel command line arguments (Bitbake variable?)
Dec 12 03:36:09 <tlwoerner> okay, i'll take it ('cause i'm so happy for the feature) and look at optimizing later :-)
Dec 12 03:37:57 <JPEW> tlwoerner: OK. I tested it on a tinkerboard, but thats all I have available
Dec 12 03:41:48 <tlwoerner> that's the only one that matters right now ;-) until i get around to adding some of the rk3399 boards...
Dec 12 03:42:28 <JPEW> tlwoerner: I really want to get a rockpi4
Dec 12 05:04:25 <tlwoerner> JPEW: sorry for taking so long to apply patches, but i do like to test and investigate :-)
Dec 12 06:03:16 <yocti> New news from stackoverflow: Segmentation Fault after updating PAHO MQTT to 1.3.1 <https://stackoverflow.com/questions/59298536/segmentation-fault-after-updating-paho-mqtt-to-1-3-1>
Dec 12 07:52:28 <stuom1> in recipe, what is the syntax for submodule license? I mean the part LICENSE_${PN}-something-something
Dec 12 07:53:18 <stuom1> for example I get note about unidentified license of node_modules/@polymer/app-layout/node_modules/@polymer/iron-media-query/node_modules/@polymer/polymer/LICENSE.txt
Dec 12 08:33:38 <yocti> New news from stackoverflow: Kernel selection using yocto <https://stackoverflow.com/questions/43731676/kernel-selection-using-yocto>
Dec 12 08:39:48 <wertigon> Hi, new day, new task, this time hopefully something easier;
Dec 12 08:39:57 <wertigon> I want a boot splash :P
Dec 12 08:40:36 <wertigon> Tried to find a relevant package but my google-fu failed me
Dec 12 08:40:42 <wertigon> So, any tips?
Dec 12 08:42:53 <LetoThe2nd> wertigon: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-features-image -> splash
Dec 12 08:51:59 <wertigon> Thanks, I knew I was missing something ^^
**** BEGIN LOGGING AT Thu Dec 12 08:55:52 2019
Dec 12 09:33:49 <yocti> New news from stackoverflow: Yocto tensorflow 2.0 <https://stackoverflow.com/questions/58502660/yocto-tensorflow-2-0>
Dec 12 09:36:21 <wertigon> Hmm, adding the psplash package and running does nothing, I'm suspecting I need to add the proper screen to display the image on
Dec 12 09:41:54 <wertigon> Or... No... Aaaah, I see
Dec 12 09:42:07 <wertigon> This is coded for init
Dec 12 09:42:25 <wertigon> so, I need to add this the systemd way
Dec 12 09:42:29 <wertigon> And it should work? :)
Dec 12 09:43:01 <wertigon> If I run the startup script manually it works fine (although wrong image but that is a different problem)
Dec 12 09:43:29 <LetoThe2nd> wertigon: i have not looked into the details, but a couple of days back ross said it should work for systemd too.
Dec 12 09:44:23 <wertigon> Yeah, it should... but thud branch could complicate stuff ^^
Dec 12 09:44:37 <wertigon> And so could meta-arago stuff
Dec 12 09:45:50 <wertigon> Sorry for being such a n00b at this btw, I really should know better now... -_-;;
Dec 12 09:47:06 <Domin1k> psplash does not work with systemd plymouth is a good alternative for psplash if you using systemd
Dec 12 09:47:42 <LetoThe2nd> Domin1k: ah yeah, it was you! :)
Dec 12 09:48:30 <wertigon> Domin1k, yeah
Dec 12 09:48:36 <Domin1k> LetoThe2nd: yes and i have plymouth running now.
Dec 12 09:48:56 <wertigon> It seems like there is a reference to psplash.service
Dec 12 09:49:03 <wertigon> But no such package is installed
Dec 12 09:49:11 <wertigon> Or file rather
Dec 12 09:49:38 <wertigon> psplash
Dec 12 09:49:50 <wertigon> *should* work with systemd as well
Dec 12 09:50:00 <wertigon> But you need to add the systemd service call for it
Dec 12 09:51:33 <wertigon> Atleast, if I read this correctly ;)
Dec 12 09:51:55 <Domin1k> OK. I still prefere plymouth because its "prettier" i like the glow theme
Dec 12 09:52:33 <wertigon> Domin1k: Yeah, I'll try Plymouth first, if it doesn't solve my problem at least I know what to look for ^^
Dec 12 09:54:14 <wertigon> Do I need to do something other than include the plymouth package? No preferred-provider?
Dec 12 09:54:30 <wertigon> (ofc, not including psplash too)
Dec 12 09:56:11 <Domin1k> Does someone now how i could use grub as bootloader for non EFI-Systems? I use wic and i can choose between the two source-plugins 1.bootimg-efi supporting grub-efi or systemd-boot and 2.bootimg-pcbios which uses syslinux. Why is there no support for the good old grub without efi?
Dec 12 09:56:41 <h-u> Hi, i try for some time to get apparmor working in yocto. I'm working usually on thud and until October there where some issues with the build. Now it builds in thud and in zeus, but it seems kernel flags and parameters are not set. Even if i add these and apparmor is startable the systemd scripts are missing. Any ideas how to proceed?
Dec 12 09:56:44 <Domin1k> SPLASH = "plymouth"
Dec 12 10:03:55 <yocti> New news from stackoverflow: Segmentation Fault after updating PAHO MQTT to 1.3.1 [closed] <https://stackoverflow.com/questions/59298536/segmentation-fault-after-updating-paho-mqtt-to-1-3-1>
Dec 12 10:07:25 <wertigon> Hmm, nothing provides dracut so it kills itself :'(
Dec 12 10:09:46 <wertigon> Ah, meta-initramfs
Dec 12 10:29:09 <wertigon> Hmm, since plymouth uses dracut I'm not sure I can use it... :(
Dec 12 10:30:27 <wertigon> Reason being, we've already been mucking around with our init ramfs and they may not be compatible
Dec 12 10:38:01 <wertigon> Hmm, seems to still be booting fine however
Dec 12 10:38:20 <wertigon> aaaand plymouth also fails, because noone wrote the damn service again XD
Dec 12 10:39:41 <wertigon> I think I will stick to psplash in that case :)
Dec 12 10:40:18 <wertigon> Just need to figure out how to write the systemd script, should be a pretty straightforward ordeal
Dec 12 10:48:35 <wertigon> Hmm, according to docs systemd and psplash has the problem that progress is not updated
Dec 12 11:02:30 <paulbarker> wertigon: I've just spotted your comments there. Are you looking to get psplash working with systemd? AGL has an implementation of that, let me find it
Dec 12 11:03:01 <wertigon> Found this now and testing :)
Dec 12 11:03:02 <wertigon> https://patchwork.openembedded.org/patch/107537/
Dec 12 11:03:35 <wertigon> If it doesn't work I shall head for lunch, so back in a bit :)
Dec 12 11:04:51 <paulbarker> wertigon: Have a look at the bbappend and files under https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=tree;f=meta-agl-profile-core/recipes-core/psplash;hb=refs/heads/master
Dec 12 11:35:35 <wertigon> paulbarker: I see, thanks :)
Dec 12 11:35:44 <wertigon> I think I understand
Dec 12 11:39:47 <wertigon> Ok, now I just need to make sure meta-arago doesn't overwrite my pretty splash image
Dec 12 11:40:19 <wertigon> And I need to make sure said splash image is in the proper format (currently .png)
Dec 12 12:01:54 <wertigon> what is the empty .appends.core for?
Dec 12 12:23:52 <GeneralStupid> Hi, how do i add a custom DTS? Do i need to modify the "make_dtb_boot_files" function?
Dec 12 12:29:28 <qschulz> GeneralStupid: one way is to patch the Linux kernel and add your DTS there. If you own the git repo or want/can fork it, commit there, bump SRCREV you're good to go. Another way is to do the same but create a patch with your changes and add it to SRC_URI. There might be a way to not modify the sources but I don't know it
Dec 12 12:30:58 <nacknick> Hey. I'm trying to replace "glibc" with "musl" (https://www.musl-libc.org/) - How should I do it correctly? I tried to do it by myself using Google with no success
Dec 12 12:33:26 <LetoThe2nd> nacknick: TCLIBC = "musl", basically.
Dec 12 12:33:42 <LetoThe2nd> nacknick: but please expect breakage instead of miracles :)
Dec 12 12:33:52 <GeneralStupid> qschulz: so more or less like u-boot?
Dec 12 12:34:45 <LetoThe2nd> nacknick: see https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-TCLIBC
Dec 12 12:38:59 <nacknick> LetoThe2nd: Thanks. I'll try
Dec 12 12:46:48 <wertigon> Awww
Dec 12 12:47:04 <wertigon> After trying to happily marry the .bb and .bbappend files
Dec 12 12:47:09 <wertigon> Everything fails :(
Dec 12 12:57:47 <h-u> Does anyone use apparmor?
Dec 12 13:05:27 <rburton> RP: 20191212101738/python3-native-3.8.0-r0/do_populate_sysroot:Elapsed time: 973.51 seconds20191212114645/python3-native-3.8.0-r0/do_populate_sysroot:Elapsed time: 24.36 seconds
Dec 12 13:05:31 <rburton> woop woop
Dec 12 13:08:38 <RP> rburton: nice! What was it?
Dec 12 13:09:27 <rburton> running chrtpath on every file in the native sysroot :)
Dec 12 13:09:38 <rburton> a quick 'is this an elf' check shortcircuits loads
Dec 12 13:10:06 <RP> rburton: why is it doing that? :/
Dec 12 13:10:19 <rburton> chrpath.bbclass is *very dumb*
Dec 12 13:10:32 <RP> rburton: it shouldn't be doing that :/
Dec 12 13:10:35 <kanavin> rburton, I was wondering too why it takes many minutes
Dec 12 13:10:53 <RP> rburton: doesn't this mean we have the problem elsewhere?
Dec 12 13:10:55 <rburton> i think it got worse when i fixed python's optimisation phase, as that doubled the number of files
Dec 12 13:10:59 <rburton> right, its native-wide
Dec 12 13:11:12 <rburton> going to run a comparion build and look at the buildstats
Dec 12 13:11:25 <rburton> python3 was just pathological
Dec 12 13:12:11 <rburton> also got a one-liner now to put timestamps in the log files...
Dec 12 13:29:24 <RP> rburton: that worked out quite hard last time I tried so curious what you did
Dec 12 13:29:41 <RP> (due to buffering in various places)
Dec 12 13:31:09 <RP> fire in the hole with rc7
Dec 12 13:37:04 <LetoThe2nd> RP: https://www.youtube.com/watch?v=hHAmUNCiq-g
Dec 12 13:38:46 <RP> LetoThe2nd: can't view that here but I got the idea :)
Dec 12 13:39:28 <LetoThe2nd> RP: rule #666 if exists, there is a metal version of it.
Dec 12 13:46:41 <RP> rburton: it blew up, badly
Dec 12 13:47:24 <JaMa> LetoThe2nd: how NSFW it is? it says that the video is unavailable here at home as well :)
Dec 12 13:48:04 <RP> JaMa: I think its geo copyright restrictions rather than NSFW
Dec 12 13:48:32 <LetoThe2nd> JaMa: actually not really NSFW. just a cheesy "horror" hard rock album cover and corresponding song.
Dec 12 13:49:09 <JaMa> https://www.youtube.com/watch?v=qKy-tG7jZRA this one does work
Dec 12 13:49:45 <LetoThe2nd> JaMa: blocked for me, but you obviously got the idea.
Dec 12 13:51:44 <JaMa> hehe, yes it has the same title and from the same channel, just 3y older version, maybe the same song with just updated audio/video quality
Dec 12 13:51:51 <LetoThe2nd> maybe
Dec 12 13:52:12 <LetoThe2nd> the album is like 15+x years old, IIRC
Dec 12 13:53:19 <wertigon> There we go, new bb recipe that throws out init-v in favor of systemd <3
Dec 12 13:54:13 <wertigon> Now I have a fully functional system; now I just need to convince meta-arago to draw my custom splash screen
Dec 12 14:03:20 <rburton> wertigon: why did you need a recipe? it's just a variable.
Dec 12 14:04:35 <GeneralStupid> I always get this error bb.data_smart.ExpansionError: Failure expanding variable IMAGE_BOOT_FILES, expression was      zImage     ${@make_dtb_boot_files(d)}  which triggered exception AttributeError: 'NoneType' object has no attribute 'split'"
Dec 12 14:05:01 <georgem> Do I need to CC anyone in particular for meta-networking warrior patches (cherry-pick of one of my master patches)?
Dec 12 14:06:38 <wertigon> georgem: Only if pushing upstream :)
Dec 12 14:08:18 <georgem> wertigon: I already sent the patch upstream and it made it into master. Just wondering if I need to CC someone to get the warrior version in or just send it to the list.
Dec 12 14:09:36 <wertigon> The branch maintainer in that case
Dec 12 14:09:42 <wertigon> If any
Dec 12 14:09:58 <wertigon> But not sure about OpenEmbedded / Yocto command structure
Dec 12 14:09:59 <qschulz> GeneralStupid: KERNEL_DEVICETREE is not set
Dec 12 14:10:03 <georgem> right ... how do I find out who the branch maintainer for warrior meta-networking is? :)
Dec 12 14:10:38 <rburton> georgem: the patch will need to be sent for master and then rebased and sent for zeus, then warrior.  put the branch name in the subject, and CC armin
Dec 12 14:11:30 <georgem> rburton: I sent it for master in October and it made it in. I'll check if it made it in Zeus. And send for warrior and zeus if it needs it. Thanks.
Dec 12 14:11:43 <GeneralStupid> i did KERNEL_DEVICETREE := "imx6_myboard" in my machine...
Dec 12 14:12:19 <georgem> rburton: thanks. I couldn't remember if armin was stable maintain for meta-oe/meta-networking or just oe-core.
Dec 12 14:12:28 <georgem> maintainer*
Dec 12 14:14:03 <georgem> Looks like the patch made it into zeus so I'll just send it for warrior.
Dec 12 14:15:48 <qschulz> GeneralStupid: d.getVar returns None in your case
Dec 12 14:16:28 <qschulz> http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/conf/machine/include/utilities.inc#n17
Dec 12 14:16:57 <GeneralStupid> so how did i manage to break bitbake?
Dec 12 14:19:11 <qschulz> GeneralStupid: check that you don't have a typo in the variable name. I don't think you actually need :=, = should be the same (shouldn't change the outcome though). All machines have KERNEL_DEVICETREE with dtb at the end (but that check happens after)
Dec 12 14:20:38 <GeneralStupid> qschulz: oh fuck, i read that that it should be without extension... ;)
Dec 12 14:20:45 <GeneralStupid> qschulz: you see, iam an expert :D
Dec 12 14:24:57 <GeneralStupid> qschulz: now i create a dtb file in my kernel branch, add it to the specific makefile and it should work?
Dec 12 14:37:47 <qschulz> GeneralStupid: try and you'll see. I find it weird that getVar returns None. I don't know bitbake and the internals good enough to help on that one, but I'd guess most likely a typo in the variable
Dec 12 15:15:43 <GeneralStupid> qschulz: thank you. I think i can mange it from here :)
Dec 12 15:23:07 <GeneralStupid> qschulz: that worked. Grea
Dec 12 15:23:09 <GeneralStupid> great
Dec 12 16:05:02 <yocti> New news from stackoverflow: Zedboard: Kernal panic with undefined instruction and reboots <https://stackoverflow.com/questions/59308079/zedboard-kernal-panic-with-undefined-instruction-and-reboots>
Dec 12 16:16:40 <kergoth> Anyone know offhand if the oe python modules provide access to package file lists?
**** BEGIN LOGGING AT Thu Dec 12 16:39:13 2019
Dec 12 16:45:22 <kanavin> RP, rburton I have a big pile of recipe updates, should I send them, or is it better to wait some days (or maybe until after holidays) ?
Dec 12 16:45:54 <kanavin> specifically http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates
Dec 12 16:45:59 <kanavin> (and more is coming)
Dec 12 16:46:32 <kanavin> it's a bit quiet here at work, so I thought I'd address some of the more tricky updates, and hopefully bring the number of outdated ones down significantly
Dec 12 16:51:19 <RP> kanavin: Once we get M1 built we'll have cycles to test more again
Dec 12 16:51:49 <kanavin> RP: right, I just wasn't sure how close that is now
Dec 12 16:54:46 <RP> kanavin: We're on rc8 which is unheard of :(
Dec 12 16:55:17 <kanavin> RP: better that than give half-baked hashequiv to users
Dec 12 16:56:57 <RP> kanavin: I think in general it works ok, there are just some corner cases which are proving troublesome
Dec 12 16:57:12 <JPEW> RP: Did you decide to disable it
Dec 12 16:57:27 <kanavin> RP: right, locally I haven't seen any problems so far, other than the console spam :)
Dec 12 16:58:15 <RP> kanavin: I know the spam is annoying but we need it right now if it goes wrong :/
Dec 12 16:58:29 <kanavin> I thought so
Dec 12 16:58:33 <RP> JPEW: not yet but may have to
Dec 12 16:58:52 <JPEW> RP: Ya, seems like it might be the thing to do. Live to fight another day :)
Dec 12 16:59:00 <RP> JPEW: the world-alt build is going slowly but perhaps fast enough I'll let it complete and call rc8 ok
Dec 12 16:59:16 <JPEW> OK. Did the NFS changes help?
Dec 12 16:59:41 <RP> JPEW: your sstate change did, the NFS did a bit too
Dec 12 16:59:58 <RP> JPEW: there is some other problem in that code wrt performance
Dec 12 17:01:16 <JPEW> RP: Ya, for sure.
Dec 12 17:07:10 <JPEW> RP: Hmm, your revert suprises me. I was under the assumption that the taskhash would be sufficent for indexing and the tid was for convinence (per the TODO comment)
Dec 12 17:07:47 <JPEW> RP: Are there multiple tid's with the same taskhash?
Dec 12 17:29:42 <JPEW> Hmm, I though I could have one multiconfig .conf file add another a la BBMULTICONFIG += "other"
Dec 12 17:47:30 <khem> kanavin: send them now. if my job involves eating one frong, then I would like to eat it early :)
Dec 12 17:48:55 <kanavin> khem, sure, I need to rearrange them a bit first
Dec 12 17:49:54 <khem> RP: the go-native fix missed one fix, when we change machine from qemuarm to qemux86 it was caught but other machine transitions worked ok
Dec 12 18:05:26 <RP> JPEW: tids are unique, I think it breaks as the code added to get_taskhash doesn't check if the task is an sstate task or not, the conditions are different
Dec 12 18:05:37 <JPEW> Ah
Dec 12 18:05:43 <RP> JPEW: I suspect there are corner cases which break
Dec 12 18:05:59 <RP> JPEW: I have a local patch which might be better
Dec 12 18:06:36 <JPEW> Is the lookup of taskhash = self.taskhash[tid] part of the problem?
Dec 12 18:06:43 <JPEW> ^^ in get_unihash()
Dec 12 18:06:53 <RP> JPEW: not that I could see in the profile
Dec 12 18:07:03 <JPEW> RP: OK
Dec 12 18:08:07 <JPEW> RP: Can we make the unihash cache just use the taskhash as the key and leave the rest of the existing logic
Dec 12 18:08:21 <RP> JPEW: I'm testing something like https://www.youtube.com/watch?v=hHAmUNCiq-g
Dec 12 18:08:33 <RP> JPEW: heh
Dec 12 18:08:41 <JPEW> Wrong paste buffer :)
Dec 12 18:09:09 <RP> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=ff486bac1ea619fbc00909258c73b025ffb4af66
Dec 12 18:09:23 <RP> JPEW: indeed, broken sync between my local and remote buffers
Dec 12 18:09:51 <RP> JPEW: the above stores one unihash per task, fixing the TODO, at least in theory
Dec 12 18:10:30 <RP> JPEW: the hard part is not having any paths from the tids in the cache
Dec 12 18:13:36 <JPEW> RP: Hmm, so the taskhash isn't in the key anymore?
Dec 12 18:13:44 <JPEW> Ah, is that what bounds the cache size?
Dec 12 18:14:57 <kanavin> khem, there you go, just sent
Dec 12 18:18:02 <RP> JPEW: we only get one hash per tid which limits its size
Dec 12 18:19:41 <RP> JPEW: although sadly, with this applied, get_unihash is still slow :/
Dec 12 18:19:53 <RP> JPEW: I can share the profile, see if you can spot something I can't
Dec 12 18:21:15 <RP> JPEW: https://www.rpsys.net/wp/rp/profile.log.processed.gz
Dec 12 18:22:33 <RP> JPEW: the 50s+ in process_possible_migrations is too high (and this is with my above patch applied so it doesn't help)
Dec 12 18:24:17 <khem> kanavin:thanks
Dec 12 18:45:33 <RP> JPEW: Its the         if self.setscenetasks and tid not in self.setscenetasks:
Dec 12 18:45:45 <RP> JPEW: will investigate why
Dec 12 18:47:53 * RP tries changing it to a set
Dec 12 18:48:31 <JPEW> RP: Is it the process_pending_migrations() -> get_taskhash() -> get_unihash() chain that is slow?
Dec 12 18:48:40 <RP> JPEW: yes
Dec 12 18:49:08 <RP> JPEW: also the scenequeue_updatecounters()
Dec 12 18:49:14 <RP> not looked at that yet
Dec 12 18:49:36 <RP> sorry, I think I mean update_scenequeue_daya
Dec 12 18:52:07 <JPEW> Hmm, that one's going through eval() :(
Dec 12 18:54:31 <RP> JPEW: using a set() improves things *massively*
Dec 12 18:54:56 <RP> 237000 calls in 0.9s now
Dec 12 18:55:58 <RP> JPEW: we can fix that without all the other refactoring thankfully
Dec 12 18:58:14 <RP> JPEW: patch out :)
Dec 12 18:59:55 <JPEW> RP:Excellent!
Dec 12 19:00:09 <RP> which raises a question about what runqueue is doing with a list here as well, should fix that too...
Dec 12 19:01:17 <RP> I'm just going to try and let rc8 continue through to completion I think and worry about this for M2
Dec 12 19:13:45 <JPEW> RP: Sounds good
Dec 12 20:12:57 <denix> is there any way to "force" a layer to be compatible with oe-core LAYYERSERIES_COMPAT? I need a slightly older snapshot of that one layer, which was before zeus release - I manually marked it as compatible with zeus and it works. is there any way to do it globally in config?
Dec 12 20:28:15 <khem> denix not one I know of. Easy is fork and modify
Dec 12 20:28:46 <khem> with my distro hat on, I always would fork any layer I want to include in distro
Dec 12 20:31:03 <denix> khem: I was hoping to avoid forking. was wondering if there was a way to poke a variable from outside the layer. maybe RP can suggest something...
Dec 12 20:32:23 <bluelightning_> denix: you might be able to do LAYERSERIES_COMPAT_collectionname_forcevariable =
Dec 12 20:32:34 <bluelightning_> you'd have to try it though
Dec 12 20:32:44 <denix> bluelightning_: tried it, didn't seem to work
Dec 12 20:32:49 <bluelightning_> hmm
Dec 12 20:33:01 <khem> bluelightning_:this is parsing time
Dec 12 20:33:26 <khem> denix: inject via envsetup script if you have one
Dec 12 20:34:43 <denix> khem: e.g. patch the corresponding layer.conf during setup?
Dec 12 20:34:56 <bluelightning_> heh
Dec 12 20:35:06 <bluelightning_> there's always a way :)
Dec 12 20:35:42 <bluelightning_> on the other hand could the layer maintainer not just fix it properly?
Dec 12 20:36:10 <bluelightning_> (oh, maybe you need that particular older version, reading your message again)
Dec 12 20:36:22 <denix> bluelightning_: yeah, I need a specific commit
Dec 12 20:40:02 <khem> denix: well if you know then laws can be broken
Dec 12 20:41:50 <denix> right
Dec 12 20:41:59 <RP> denix: where did you try what bluelightning_ suggested?
Dec 12 20:43:17 <RP> denix: that would be the best idea I have as well, we didn't design this interface to be bypassed!
Dec 12 20:43:46 <denix> RP: I believe I put in local.conf
Dec 12 20:44:21 <denix> RP: some sort of I_KNOW_WHAT_IM_DOING=true bypass would be nice :)
Dec 12 20:45:05 <denix> yes, this is not standard and I take full responsibility to support it myself :)
Dec 12 20:45:09 <RP> denix: right, put it in an earlier layer, it needs to be parsed early
Dec 12 20:45:35 <RP> denix: bblayers.conf maybe?
Dec 12 20:46:07 <denix> RP: ok, I can try that
Dec 12 20:46:50 <RP> denix: I think the I_KNOW_WHAT_IM_DOING option is LAYERSERIES_CORENAMES = ""
Dec 12 20:47:23 <bluelightning_> yeah any override of this would need to be in bblayers.conf
Dec 12 20:48:21 <denix> RP: that would disable all compat checking, right?
Dec 12 20:48:30 <RP> denix: yes
Dec 12 20:48:48 <RP> denix: but you know what you're doing!
Dec 12 20:49:19 <denix> lol
Dec 12 20:50:35 <khem> RP you are handing him a chain saw
Dec 12 20:51:05 <RP> khem: heh :)
Dec 12 20:51:34 <RP> I would note that any of these things would invalidate YP Compat status and are not recommended in the slightest
Dec 12 20:52:22 <denix> understood
Dec 12 20:52:51 <khem> and voting rights in free country
Dec 12 20:54:55 <denix> btw, the layer in question is meta-browser - it has no branching/release strategy any more and master is now simply marked as compatible with "rocko sumo thud warrior"...
Dec 12 20:56:47 <denix> that was before zeus release, after that rocko and sumo were dropped and zeus added to the list. there's no way to easily pick a branch with needed version, as it's now a "rolling" layer
Dec 12 20:57:51 <fray> rolling layers can work, but in my experience introduce a lot of problem (bbappends)
Dec 12 20:59:24 <denix> RP, bluelightning_: so, adding LAYERSERIES_COMPAT_browser-layer_forcevariable = "zeus" to conf/bblayers.conf doesn't work
Dec 12 21:00:15 <RP> denix: try adding OVERRIDES = "forcevariable" too
Dec 12 21:00:39 <bluelightning_> evil :)
Dec 12 21:00:49 <RP> bluelightning_: totally
Dec 12 21:01:09 <bluelightning_> perhaps we need a gunpointvariable now too
Dec 12 21:01:11 <denix> heh, that works
Dec 12 21:01:48 <RP> denix: scary ;-)
Dec 12 21:03:45 <denix> RP: indeed. I'll see if I can resolve issues with the latest code, so I can finally up-pin browser layer. this should be a temp stopgap for now
Dec 12 21:08:18 <khem> denix: we dont branch because by the time building 2 versions of chromium for 6 machines finishes its already time for next yocto release :)
Dec 12 21:09:54 <khem> on a serious note, its partially driven by chromium being rolling release ubuntu solves it via using snaps for chromium
Dec 12 21:10:25 <RP> khem: and FWIW performance *sucks*
Dec 12 21:10:58 <khem> performance of what snaps ?
Dec 12 21:11:41 <RP> khem: yes
Dec 12 21:12:02 <RP> khem: the security audit piece means the browser lags horribly
Dec 12 21:12:03 <khem> yeah I dont use them as much, I do use flatpaks
Dec 12 21:12:45 <khem> a bit, but I think these technologies might bring back the mythical year of linux dekstops :)
Dec 12 21:14:15 <khem> I see quite a few commercial apps creating snaps/flatpaks e.g. adobe, spotify
Dec 12 21:14:36 <khem> oh i must eat something
Dec 12 21:14:41 <RP> khem: I can see them helping with that
**** BEGIN LOGGING AT Thu Dec 12 23:09:24 2019
**** ENDING LOGGING AT Fri Dec 13 02:59:58 2019