| 02:05.33 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 03:15.24 | *** join/#oe ecloud (quassel@nat/qt/x-lupxhdyqeomhkgev) |
| 03:30.05 | *** join/#oe falk0n (~falk0n@a109-49-149-83.cpe.netcabo.pt) |
| 03:58.08 | khem | armpit: mali is not working in xu4 ? |
| 03:58.20 | khem | armpit: is that a regression |
| 03:59.08 | armpit | it never worked |
| 03:59.26 | armpit | in later kernels I should say |
| 03:59.39 | armpit | the device tree is not upstream |
| 04:00.31 | armpit | 4.18 |
| 04:18.24 | khem | armpit: yeah I think we can get it going soon |
| 04:19.07 | khem | we should keep hardkernel 4.14 recipes |
| 04:23.11 | armpit | that is such a painful thought |
| 04:26.19 | khem | 4.14 is LTS |
| 04:30.55 | *** join/#oe baali (~baali@117.208.124.116) |
| 04:32.31 | armpit | 4.19 will be the next one and no sign hardkernel is moving there.. |
| 04:33.16 | armpit | like I provide support on this layer |
| 04:35.14 | armpit | khem, are you suggesting the default should be 4.14 ? |
| 04:39.23 | khem | armpit: I think there should be an option to use linux-hardkernel_4.14 |
| 04:39.42 | khem | I am not hard bound to have it default |
| 07:12.07 | *** join/#oe infobot (ibot@208.53.50.136) |
| 07:12.07 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
| 07:57.38 | *** join/#oe rburton (~textual@35.106.2.81.in-addr.arpa) |
| 14:50.13 | *** join/#oe infobot (ibot@208.53.50.136) |
| 14:50.13 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
| 14:50.21 | *** join/#oe joseppc (~josep@linaro/joseppc) |
| 14:55.30 | khem | yes this seems a good idea |
| 15:09.10 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 15:10.39 | *** join/#oe rcw (~rcw@128.224.252.2) |
| 15:12.08 | *** join/#oe baali (~baali@117.212.16.66) |
| 15:15.14 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 15:16.02 | *** join/#oe cpriouzeau (~cpriouzea@164.129.115.76) |
| 15:31.24 | *** join/#oe tnovotny (~tnovotny@176.74.132.138) |
| 15:34.13 | *** join/#oe Crofton_ (~Crofton@wsip-24-234-76-211.lv.lv.cox.net) |
| 15:44.58 | *** join/#oe vmeson (~rmacleod@24-52-238-240.cable.teksavvy.com) |
| 15:56.38 | smurray | khem: how are things these days with mixing c++ libraries linked against libstdc++ with ones built with clang and linked against libc++, does that work? |
| 15:57.17 | smurray | khem: the libc++ page is a little vague |
| 15:57.55 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 16:10.48 | *** join/#oe heeen (heeen@endboss.org) |
| 16:11.13 | heeen | I am looking for the opcontrol binary, it was not isntalled by the oprofile package |
| 16:12.00 | heeen | or something else that allows me to profile an app by sampling stack traces |
| 16:16.29 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 16:37.32 | tlwoerner | armpit: khem: i've been trying to get this class added to oe-core so all BSPs can use it, but nobody merged it :-( |
| 16:37.50 | tlwoerner | some people said "i want to think about it more" but nothing happened |
| 16:37.59 | tlwoerner | http://lists.openembedded.org/pipermail/openembedded-architecture/2017-July/000662.html |
| 16:38.15 | tlwoerner | http://lists.openembedded.org/pipermail/openembedded-core/2017-July/139974.html |
| 16:40.54 | rburton | heeen: use perf instead? |
| 16:49.06 | Crofton_ | perf ++ |
| 17:04.16 | tlwoerner | is there a way to make a recipe version dependent on a kernel? armin suggested RDEPENDS but i can't find the magic incantation |
| 17:04.48 | tlwoerner | oops, that should have read... |
| 17:04.59 | tlwoerner | is there a way to make a recipe version-dependent on a kernel |
| 17:05.14 | tlwoerner | i.e. this recipe needs a kernel >= 4.15 |
| 17:06.12 | tlwoerner | RDEPENDS_${PN} = "kernel (>= 4.15)" |
| 17:06.34 | tlwoerner | but it doesn't seem to work (with rpi anyway) -> what's the package name for virtual/kernel? |
| 17:10.45 | *** join/#oe Bunio_FH (~bunio@84.red-213-0-2.staticip.rima-tde.net) |
| 17:13.41 | Jin^eLD | hmm, is meta-freescale a replacement for meta-fsl-arm or are they both supposed to coexist? |
| 17:17.37 | tlwoerner | Jin^eLD: yes, meta-freescale is a replacement for meta-fsl-arm |
| 17:17.54 | tlwoerner | meta-fsl-arm hasn't seen a commit since Oct 2016 |
| 17:22.31 | *** join/#oe infobot (ibot@208.53.50.136) |
| 17:22.31 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
| 17:22.44 | Jin^eLD | wow, nice, was not aware of that either, but then again - I am just now in the process of updating for 2.0.2 to 2.5.1, so I missed quite a lot ;) |
| 18:05.34 | *** join/#oe cpriouzeau (~cpriouzea@164.129.115.76) |
| 18:24.50 | *** join/#oe JPEW (cc4da337@gateway/web/freenode/ip.204.77.163.55) |
| 18:26.12 | *** join/#oe ao2 (~ao2@host218-139-dynamic.27-79-r.retail.telecomitalia.it) |
| 18:34.10 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 19:22.03 | Jin^eLD | hmm, can I somehow enforce a prbump when using prserv? I'm trying to recover from something... |
| 19:25.59 | Jin^eLD | ok never mind, I think I can do it via bitbake-prserv-tool |
| 19:28.59 | kergoth | khem: https://github.com/VSCodium/vscodium |
| 19:32.13 | Jin^eLD | for prserv... the checksum of which task is being stored? |
| 19:37.01 | Jin^eLD | and how does the import work? I can't import anything that I exported, I get ParserError: not a BitBake file |
| 19:37.08 | Jin^eLD | any hints? |
| 19:37.32 | Jin^eLD | curently looking at this documentation https://wiki.yoctoproject.org/wiki/PR_Service |
| 19:39.26 | Jin^eLD | ok, sorry for bothering ;) thx to google... its supposed to have a .conf extension... |
| 19:41.12 | Jin^eLD | but which task exactly is being checksumed, that I did not figure out yet |
| 19:56.33 | JaMa | Jin^eLD: e.g. these 2 from prserv.sqlite PRMAIN_nohist tables: |
| 19:56.34 | JaMa | linux-yocto-4.18.5+gitAUTOINC+7341720391_71799edb8a-r0|qemux86|93759b759b6f9d151f8d0863e7221475|4 |
| 19:56.37 | JaMa | linux-yocto-4.18.5+gitAUTOINC+7341720391_71799edb8a-r0|qemux86|8763994acab1e22e8770ddcc0706bf83|5 |
| 19:56.44 | JaMa | match with do_package and do_deploy tasks in linux-yocto |
| 19:56.57 | JaMa | 4.18.5+gitAUTOINC+7341720391_71799edb8a-r0.do_package.93759b759b6f9d151f8d0863e7221475 |
| 19:57.05 | JaMa | 4.18.5+gitAUTOINC+7341720391_71799edb8a-r0.do_deploy.8763994acab1e22e8770ddcc0706bf83.qemux86 |
| 19:59.40 | Jin^eLD | ah, do_package and do_deploy.. thank you |
| 20:00.01 | JaMa | linux-yocto isn't best example and you can change the key with PRAUTOINX variable |
| 20:01.10 | Jin^eLD | I somehow ran into a problem with recipe XX is trying to install files into a shared area when those files already exist. |
| 20:01.34 | Jin^eLD | so now fighting my way around but trying to keep the feed updateable (i.e. need to prevent PR going back in case I clean something) |
| 20:02.51 | JaMa | and this is your only problem with PRserv? then you're lucky :) |
| 20:04.07 | Jin^eLD | well, we are finally switching to rootfs-based updates, i.e. flashing whole image instead of rolling opkg updates |
| 20:04.18 | Jin^eLD | so hopefully prserv won't be such an issue any longer... |
| 20:04.39 | JaMa | that's what we do as well (not ideal, but better than fighting with PRserv) |
| 20:04.46 | Jin^eLD | one OE core with PR_INC control over .bbappends and each package having a fixed PR it worked fine |
| 20:04.56 | Jin^eLD | s/one/on/ |
| 20:05.11 | Jin^eLD | yeah, both have pros and cons, opkg update was at times faster due to the smaller diff |
| 20:05.31 | Jin^eLD | but the newer opkg versions in yocto proved to have a lot of issues |
| 20:05.42 | Jin^eLD | and then the prserv stuff was not easy to handle as well |
| 20:05.54 | JaMa | did you report those opkg issues? |
| 20:06.14 | Jin^eLD | we were on an older opkg branch because we were using libopkg which got dropped in the later version |
| 20:06.23 | Jin^eLD | so - our own fault for using old stuff |
| 20:06.37 | JaMa | I don't have much issues with opkg, but with PRserv every opkg update was almost as slow as reflash of whole rootfs |
| 20:06.54 | JaMa | e.g. small update in zlib causes almost everything to rebuilt with different PRAUTO |
| 20:07.07 | JaMa | and then upgrading *everything* with opkg is much slower than reflash |
| 20:07.31 | Jin^eLD | we were stuck on quite a buggy opkg branch, so was also no point to report anything because we were on a too old version and we could not switch to the new one because we had tools depending on libopkg |
| 20:07.42 | JaMa | + opkg upgrade everything usually fails because of lack of disk space on the target |
| 20:07.53 | JaMa | IC |
| 20:07.57 | Jin^eLD | yes, that I noticed, sometimes too many packages got rebuilt and then if you have 400 packages to update - then a reflash is faster |
| 20:08.44 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 20:08.46 | JaMa | and partial diff of rootfs might be even smaller/faster, because a fix in zlib usually doesn't change much in everything else which somehow depends on zlib |
| 20:08.56 | Jin^eLD | what do you use to flash images? swupdate? |
| 20:09.30 | JaMa | proprietary inhouse thing |
| 20:10.10 | kergoth | swupdate isn't bad if you set up a user data partition to persist stuff and ideally dual-partition so you're alternating the rootfs when you update |
| 20:10.16 | kergoth | has used it a bit |
| 20:10.56 | Jin^eLD | we came up with a rescue system and we use it for updates as well, but we decided against a pure data partition |
| 20:11.07 | Jin^eLD | so we backup configurations that need to be backed up |
| 20:11.19 | Jin^eLD | then reflash and restore the config |
| 20:11.30 | kergoth | nods, not a bad way to go |
| 20:12.10 | Jin^eLD | we were considering the alternation as well but not all of our targets have enough space to support that and we wanted to have maximum unification between the various platforms - easier maintenance |
| 20:12.58 | JaMa | we have 55 partitions for different usecases including sort of A/B for recovery |
| 20:13.32 | Jin^eLD | 55? wow... |
| 20:13.46 | Jin^eLD | must be fun to maintain :) |
| 20:14.47 | kergoth | aye. the safety of a/b is nice, but nto alwyas viable |
| 20:15.07 | Jin^eLD | btw I saw that NI did a better job than us getting the mulple kernel thing merged |
| 20:15.14 | Jin^eLD | :) |
| 20:34.05 | bluelightning | morning folks |
| 20:34.16 | bluelightning | Jin^eLD: yeah, it took quite a bit of wrangling but it's in :) |
| 20:34.43 | bluelightning | there's still some missing bootloader integration for completeness (platform-dependent though of course) |
| 20:36.29 | Jin^eLD | hi bluelightning |
| 20:37.54 | Jin^eLD | well, I remember it was quite an intrusive change, so no wonder it took a while to come up with something that wouldnt break everything :) |
| 21:06.43 | khem | smurray: mixing libc++ and libcstc++ are API compatible but not ABI compatible |
| 21:09.25 | khem | so you can load both libraries into a process but dont pass symbols across library boundary |
| 21:11.15 | Jin^eLD | nite |
| 21:12.06 | smurray | khem: hmm, |
| 21:12.31 | smurray | khem: okay. Iâll have to see if that works for this customerâs codebase |
| 21:12.43 | smurray | khem: thanks! |
| 23:35.35 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-wmizgnhjpjtsxhto) |