**** BEGIN LOGGING AT Mon Jan 18 02:59:57 2021 Jan 18 04:59:17 i'm working with an ancient poky tree circa 2010 (squeezebox radio). i've got it building with a significantly newer codesourcery arm toolchain ("external-csl-toolchain") (2014) than the one it originally used (2010), but on some extra packages i'm building i've run into them detecting syscalls that the ancient kernel (2.6.26) doesn't support. Jan 18 04:59:47 is there a way to "hide" those syscalls (recvmmsg in this case, from chrony) without just patching out the configure script on affected packages? Jan 18 04:59:55 is this whole thing awful? :D Jan 18 05:01:01 fwiw, it all works, except chrony bugs out and per strace it just sits at 100% cpu trying to run recvmmsg and getting ENOSYS back. it's simple enough to patch the configure, just wondering if there's a better way to approach this. Jan 18 06:51:33 check which kernel headers were used and patch to use ancient ones in case it tries to use modern ones Jan 18 08:03:59 good morning Jan 18 08:04:47 morning Jan 18 12:17:48 is there any point sending a small patch (version bump) for meta-oe zeus branch? Jan 18 12:18:01 if so, where should it be sent? Jan 18 13:17:18 mru: https://wiki.yoctoproject.org/wiki/Releases says it's not yet EOL ("Community" maintainership) so go ahead Jan 18 13:17:39 You can send to the same mailing list as normal for meta-oe, just add "[zeus]" to the patch subject Jan 18 13:17:53 and which is the normal list? Jan 18 13:18:39 mru: https://git.openembedded.org/meta-openembedded/tree/meta-oe/README Jan 18 13:21:19 too obvious Jan 18 13:23:39 no list, just armin? Jan 18 13:51:31 mru: the matching layer list + CC the maintainer (Armin) Jan 18 13:52:22 mru: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded says to=openembedded-core@lists.openembedded.org Jan 18 14:32:43 paulbarker mru: I'm pretty sure the wiki page is out of date and zeus is no longer maintained. Jan 18 14:33:43 show me a wiki that isn't out of date Jan 18 14:34:43 +1 Jan 18 14:38:20 smurray: isnt zeus community maintained ? Jan 18 14:38:51 isn't that just a euphemism for unmaintained? Jan 18 14:38:52 also, Xilinx still uses zeus as the state-of-the-art for their meta-xilinx* layers Jan 18 14:39:17 marex: afaik maintenance stopped when gatesgarth released Jan 18 14:39:26 marex: no changes since Sept Jan 18 14:39:39 marex: https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/conf/layer.conf suggests Xilinx are a little more up to dat Jan 18 14:39:45 *up to date Jan 18 14:40:08 paulbarker: https://github.com/Xilinx/meta-xilinx/blob/rel-v2020.2/meta-xilinx-bsp/conf/layer.conf suggests that nope Jan 18 14:40:35 paulbarker: thats the official release which you MUST use if you want to get any support from Xilinx Jan 18 14:40:41 we'll be moving on from zeus in a bit, but for now we're stuck with some python2 dependencies Jan 18 14:40:50 marex: Damn. That's disappointing Jan 18 14:40:50 also, enjoy the Blue Monday Jan 18 14:41:07 paulbarker: dont get me started on xilinx, I beg you Jan 18 14:41:15 NXP are the same, stuck on zeus Jan 18 14:41:28 smurray: dont get me started on nxp I beg you Jan 18 14:42:28 smurray: with NXP, it simply makes sense to ignore the layers and build your own with mainline + a couple of backports Jan 18 14:46:58 marex: meta-freescale works well enough for AGL with some minor tweaking, but I definitely agree wrt e.g. meta-imx Jan 18 14:47:35 smurray: which SoC is used in there ? Jan 18 14:49:05 that outdated fork of poky, meta-qt5 etc in github/xilinx with custom patches grown into git history just breaks my heart Jan 18 14:49:16 marex: i.mx6q, i.mx8mq Jan 18 14:49:28 smurray: those should be usable with mainline + etnaviv Jan 18 14:49:46 smurray: the blob GPU driver is awful Jan 18 14:50:23 marex: we've had this discussion many times, AGL is on dunfell, and I am not in a position to just build my own BSP for it Jan 18 14:50:49 marex: we're defaulting to etnaviv on the i.mx8mq Jan 18 14:51:11 smurray: yeah Jan 18 14:54:08 smurray: its a real pity the display pipeline / pgc stuff on mx8m is so broken and NXP is blocking any attempts at fixing it Jan 18 14:54:33 and also the amount of upstreaming from NXP seems to have decreased a lot Jan 18 15:07:47 marex: it's definitely not a great sign Jan 18 15:39:24 smurray: no Jan 19 01:16:31 support from Xilnx? Serioussly? Official position is bonkers Jan 19 01:16:37 Yeah I'm cranky Jan 19 01:18:25 Crofton|cloud: that;s OK, I am still waiting for meta-xilinx-standalone sources Jan 19 01:21:41 We need to send our bar bills to zeddii and fray Jan 19 02:18:32 * zeddii doesn't actually work on those bits :D **** ENDING LOGGING AT Tue Jan 19 03:00:19 2021