**** BEGIN LOGGING AT Thu Jan 19 03:00:01 2017 Jan 19 08:13:04 good morning Jan 19 08:13:14 hey Jan 19 09:06:35 morning Jan 19 09:23:35 I've asked this before, so sorry about that. I have an old HW that *has* to run linux-omap 2.6.39 (no device tree), systemd 204, and libgles-omap3 4.05.00.03. Been running Dylan for some years. Is there any hope of getting this to run on newer release? Jan 19 09:23:59 Seem to recall that systemd > 204 demands kernel >= 3 Jan 19 09:27:12 tasslehoff: yeah, systemd has some requisites like that IIRC. my feeling says that either it would include massive rework of your image or massive backporting. Jan 19 09:27:31 tasslehoff: if you can't touch the existing kernel, could you maybe kexec a newer one? Jan 19 09:27:35 tasslehoff: sounds like something oma4 ;-) Jan 19 09:28:21 tasslehoff: my suggesting, however ugly, would be to cherry-pick and backport the things from newer releases that are relevant for you. Jan 19 09:34:42 LetoThe2nd: even worse. omap3 :) Jan 19 09:34:54 tasslehoff: lovely. Jan 19 09:35:26 Jin^eLD: the kernel requirement is because I haven't found another one that goes to deep sleep on this hw. Jan 19 09:36:39 The aim is to get a newer Qt, but for that to happen I need GCC >= 4.9. Perhaps there is a way I can make that happen in Dylan. Jan 19 09:37:06 tasslehoff: yeah i'd just backport gcc. that should give you too much headaches Jan 19 09:37:16 *shoulnd't Jan 19 09:37:20 Tried moving meta-linaro to dizzy, but that introduced a bunch of dependencies as well. Jan 19 09:37:51 LetoThe2nd: That would involve changes in meta-linaro and openembedded-core ? Jan 19 09:38:36 tasslehoff: hopefully only core. maybe it could even be a seperate layer that brings the gcc, which you then select through PREFERRED_VERSION Jan 19 09:44:16 LetoThe2nd: I use angstrom, and see that the PREFERRED_VERSION for _arm is linaro-4.7 Jan 19 09:44:27 koen: remember if I must/should use that in 4.7? Jan 19 09:44:31 eh, in dylan Jan 19 09:49:48 tasslehoff: i at least remember having done the opposite, building krogoth with 5.something. Jan 19 09:49:56 tasslehoff: so my gut feeling says "doable" Jan 19 10:22:28 tasslehoff: it should be easy to just copy over the 4.9 recipes to the dylan branch Jan 19 10:26:21 koen: both for linaro and core? started with linaro, and that required a bunch of stuff from core. another issue I'm tackling is eglibc->glibc :) Jan 19 10:27:20 for/from linaro Jan 19 10:27:33 I recently updated the gcc recipes to require less from oe-core Jan 19 10:27:45 maybe that makes it easier to transplant Jan 19 10:28:07 koen: ah. which branch should I take the linaro-recipes from? Jan 19 10:28:20 I used dizzy, and that required a lot. Jan 19 10:31:35 try master Jan 19 10:31:51 iirc I started with 5.2 Jan 19 10:35:59 koen: thanks. I wonder how many recipes will break because of the compiler change :) Jan 19 10:46:55 JaMa, ping Jan 19 10:55:33 pong Jan 19 10:57:31 hello Jan 19 10:58:03 about openssl, what are the plans? keep 1.0.2 LTS? Jan 19 11:05:03 ant_work: instead of upgrading to 1.1? i suspect so, 1.1 is a pita Jan 19 11:06:09 I think the status is like discussed here: https://github.com/OpenPLi/openpli-oe-core/tree/master-next Jan 19 11:06:40 argh.. Jan 19 11:06:43 here: http://lists.openembedded.org/pipermail/openembedded-core/2016-October/127316.html Jan 19 11:07:09 (I'm seeing how I can hel the OpnePLI guys to clean the mess of their layers...) Jan 19 11:16:04 ant_work: I don't know Jan 19 12:20:55 fray, ./setup/setup.sh: line 200: python: command not found Jan 19 12:20:55 OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python v3. Jan 19 12:20:55 Please upgrade your python v2. Jan 19 12:22:33 bad error but the message is true: you still need py2 to build oe Jan 19 12:22:46 ok Jan 19 12:23:01 I am amused that py3 to py2 is a downgrade :) Jan 19 12:23:03 at least, its safe to have py2 as plenty of things depend on it. last time i tried there were quite a few failures without py2 on the host. Jan 19 12:23:16 yeah if python isn't found it should tell you to install py2 Jan 19 12:23:20 file a bug :) Jan 19 12:52:20 I think that's reusing the same error message for no python and python pointing to python3 (like some blasphemous distros do) Jan 19 12:52:30 *cough*arch*cough* Jan 19 13:47:44 Mixing and matching Dylan and Dizzy, I get: Nothing RPROVIDES 'packagegroup-cross-canadian-arm' Jan 19 14:10:39 tasslehoff: don't mix and match dylan and dizzy? Jan 19 14:10:59 if you want to pull a newer toolchain to a previous release, be *very careful* obviously Jan 19 14:23:16 rburton: yeah. it hurt so much that I'll try to move to dizzy one more time. if that doesn't go well we'll stay at dylan for that old piece of ... hardware Jan 19 15:05:42 damn it jethro isn't building on F25 due to: Jan 19 15:05:57 | /home/balister/echo-ridge/build/tmp-glibc/work/x86_64-linux/pkgconfig-native/0.28+gitAUTOINC+40342dd0ea-r0/git/glib/glib/glibintl.h:37:42: warning: statement with no effect [-Wunused-value] Jan 19 15:05:58 | #define bindtextdomain(Domain,Directory) (Domain) Jan 19 15:06:01 liek things Jan 19 15:07:28 perhaps try a container Jan 19 15:07:29 ? Jan 19 15:07:53 trying to run unmaintained releases of OE/YP on latest Fedora is a path to madness Jan 19 15:07:56 I know Jan 19 15:08:06 #fml Jan 19 15:08:42 I was surprised at how easy it is to spin up a container with an Debian userspace and persistent container storage to do builds in Jan 19 15:09:43 if it were (almost) anyone else I'd mention the poky containers :-) Jan 19 15:09:59 gnuradio are using docker for stuff, so I sort of need to learn that way Jan 19 15:12:07 the poky containers are docker but with a lot of stuff already setup. I did it by hand and was running a bunch of different OS userspaces to test build failures in not too much time Jan 19 15:12:32 of course the docker cli is such that I can't remember all the options I had to pass and what they mean without looking in my history Jan 19 15:21:40 cbrake, has a blog post also Jan 19 15:21:45 and the mender guys use it Jan 19 15:31:34 indeed Jan 19 15:48:19 Crofton|work: you're the cmake maintainer now, right? can you review 'cmake.bbclass: enable usage of ccache' Jan 19 15:51:04 lol Jan 19 15:51:14 I don't know much about ccache Jan 19 15:51:19 I sort of looked at it Jan 19 15:51:35 I can feed it to a build that uses cmake :) Jan 19 15:52:40 sgw_: I'm guessing we might need to depend on an x64 multilib / toolchain to build the 64-bit bootloader-level and kernel-level components, the way meta-fsl-ppc has done, or always ensure that the bits needed for bare metal 64-bit builds are built, even when targeting x32 Jan 19 15:52:43 bit of a mess, really Jan 19 15:52:49 hmm Jan 19 15:53:18 * kergoth gets more caffeine Jan 19 15:54:54 but is nop unless you add ccahce bbclass Jan 19 16:07:45 kergoth: yeah, not the cleanest, I will have to review the meta-fsl-ppc stuff, I know x32 kind got bit rotted a little Jan 19 16:10:31 I think we don't have a good general purpose solution for depending on a particular multilib or toolchain for one recipe, but I think for this particular case it'd be a good idea to include the bits needed to target bare metal with x64 even in an x32 toolchain, all the time, given the use cases we need to satisfy Jan 19 16:10:50 meta-fsl-ppc alters DEPENDS and TARGET_PREFIX to use a different toolchain than the tcmode specified, which is terribly ugly Jan 19 16:11:20 better to just use multilibs to handle that, if that's the approach we want to take Jan 19 16:17:34 It's been a few years since I have looked at multilib, but that sounds right, I will take a look Jan 19 16:19:13 i'll kick off a test build with an internal toolchain here too, to check sanity Jan 19 16:20:02 kergoth: so did you actually build a kernel from meta-intel with x32? All your fixes are in OE-Core and I tried your meta-intel patch but fail to find a kernel, which is strange because MACHINE is intel-corei7-64, but every kernel recipe fails from "not in COMPATIBLE_MACHINE" Jan 19 16:38:56 sgw_: i just tested it a few minutes ago using oe-core master, meta-intel master + the aforementioned patch, only oe-core and meta-intel in bblayers, machine=intel-corei7-64. bitbake -e virtual/kernel works fine, as does a build Jan 19 16:38:57 MACHINE=intel-corei7-64 bitbake -e virtual/kernel | grep -E '^(DEFAULTTUNE|MACHINE|MACHINEOVERRIDES)=' Jan 19 16:38:57 MACHINEOVERRIDES="corei7-64-intel-common:corei7-64-x32-intel-common:intel-x86-common:intel-corei7-64" Jan 19 16:41:34 admittedly didn't do a full build now, just the -e sanity test. did successfully build around the time that i submitted the patches, though Jan 19 16:41:44 afk Jan 19 17:06:43 apart from qtcreator and eclipse, what are the IDE people are using? Jan 19 17:06:58 (I'm mainly doing kernel development so I don't know) Jan 19 17:07:27 emacs! Jan 19 17:13:02 abelloni_: anjuta, geany, Dev-C++ Jan 19 17:17:41 kergoth: turned out to be something in my build, I will try to figure out what caused it. Jan 19 17:55:15 Does vim count as an IDE? Jan 19 17:57:25 * darknighte hates when IRC silently disconnects Jan 19 18:01:20 mckoan|away: surely noone is using anjuta these days Jan 19 18:22:48 I saw a patch was "in mut". What does that mean? Jan 19 18:25:38 kc8apf: rburton's master-under-test branch. it's where they go before they hit master-next, generally Jan 19 18:26:42 kc8apf: git branch ross/mut on poky-contrib. i sweep up patches for review and testing. if they pass then i'll send the branch to RP for master-next and then master. Jan 19 18:28:01 ah, ok Jan 19 18:29:25 patches in mut may be removed if they break the autobuilder, etc etc Jan 19 18:29:29 so dont base anything on it Jan 19 19:11:02 cbrake, are you answerinf docker questions? Jan 19 21:04:37 * cbrake returns Jan 19 21:05:04 Crofton|work: sure -- I'm not a docker guru, but do use it Jan 19 21:05:43 I'm making slow progress Jan 19 21:05:58 having trouble with uid being sane a Jan 19 21:06:14 Crofton|work: rewitt has done some work with this FYI Jan 19 21:06:35 hmm, I see he's not in this channel Jan 19 21:06:41 anyway you've seen our containers I take it? Jan 19 21:06:46 no Jan 19 21:06:54 tryin gto get jethro to build in F23 container Jan 19 21:07:07 I'm going from knowing almost nothing to being angry in a day Jan 19 21:07:20 but my anger is getting focused Jan 19 21:10:47 need to beat some more on the uid issue Jan 19 21:11:46 pretty sure Randy solved that Jan 19 21:20:41 Crofton|work: so your host uid must not be 1000? Jan 19 21:21:32 it is Jan 19 21:21:40 I need to puzzle some Jan 19 21:22:29 with the cbrake/oe-build, the build user has a UID of 1000, so everything worked out Jan 19 21:23:08 well, I'm a fedora guy so translating and working out mechanics :) **** ENDING LOGGING AT Fri Jan 20 03:00:02 2017