**** BEGIN LOGGING AT Sun Jan 12 02:59:58 2020
Jan 12 05:05:54 <khem> RP:no
Jan 12 05:06:14 <khem> this does not yet have mips fixes
Jan 12 05:06:25 <khem> I have yet to figure out whats going on
Jan 12 13:22:52 <bluelotus> hello everyone.
Jan 12 13:27:17 <bluelotus> i have rather a couple of questions if somebody is available from the project.
Jan 12 13:28:44 <LetoThe2nd> bluelotus: its sunday, so things are rather quiet. so go ahead and ask, but please stick around for at least some hours.
Jan 12 13:29:05 <LetoThe2nd> (actually its pure coincidence i had a peek just right now)
Jan 12 13:29:20 <bluelotus> yeah i know but i-m rather excited about a project of mine
Jan 12 13:29:52 <bluelotus> i have a unused nokia n900 that i bought and i wanted to ask about installing poky linux on the n900
Jan 12 13:30:07 <bluelotus> if that is possible and about the package management system
Jan 12 13:30:19 <bluelotus> i know it's a lot of question but i m patient
Jan 12 13:30:24 <LetoThe2nd> anyting is possible, its only software
Jan 12 13:30:58 <LetoThe2nd> but the first problem is probably kernel source
Jan 12 13:31:15 <LetoThe2nd> e.g. do you hae a known good working state and configuration?
Jan 12 13:31:49 <LetoThe2nd> plus, do you have a working procedure to boot anything other than what is already on the phone?
Jan 12 13:32:15 <bluelotus> currently it's running maemo but i find it obsolete and i was considering going with another distro with some up-to-date repos
Jan 12 13:32:34 <LetoThe2nd> thats no answer to none of my questions.
Jan 12 13:33:04 <bluelotus> it's plainly running maemo . just that.
Jan 12 13:33:24 <LetoThe2nd> AFAIK the n9xx were mostly on 2.6.32, which is like ancient. so getting that build together with a reasonably recent userland is like, super bummer
Jan 12 13:34:39 <bluelotus> 2.6.28-omap1
Jan 12 13:34:45 <bluelotus> states the uname command.
Jan 12 13:35:07 <LetoThe2nd> plus, yocto/openembedded uses a package management mechanism to create the images, but we do not offer package repositories. so if you want something like a distro where you can add things at will, then you are ill-served with poky anyways.
Jan 12 13:36:30 <bluelotus> sorry for not being precise with the question , the real question was if i could use yocto as a distro and use the n900 for a example as a web-server , but now it s more clearer to me.
Jan 12 13:36:36 <bluelotus> sorry for the noob questions.
Jan 12 13:36:43 <LetoThe2nd> technically you could.
Jan 12 13:37:07 <LetoThe2nd> practically, you are about 100 times better off putting your time to good use if you just get yourself a raspi
Jan 12 13:37:42 <LetoThe2nd> i'd roughly estimate 4-6 weeks senior engineer dev time until you got something booting on the n900.
Jan 12 13:38:31 <LetoThe2nd> whereas a poky image for the raspi you can get in a couple of hours, depending on your build machine. and a raspbian install in like 10 minutes
Jan 12 13:38:42 <bluelotus> i've seen some videos with guys installing kali and postmarketOS on the N900 but i dont need that much bloat . just something minimal
Jan 12 13:39:04 <LetoThe2nd> (i gotta run again. back in 6hr or so, but i think i conveyed the essence)
Jan 12 13:39:13 <bluelotus> thanks anyways
Jan 12 13:48:32 <dev1990_> is there a common MACHINE_OVERRIDE for arm and armeb ?
Jan 12 13:50:24 <dev1990_> or even for aarch64 and arm  and armeb, I'm searching for something like FOO_append_armfamillycpus = " bar"
Jan 12 14:34:29 <RP> dev1990_: there is an arm override and an armeb override
Jan 12 14:52:37 <dev1990_> RP: yes there is :)
Jan 12 14:52:51 <dev1990_> https://github.com/dev-0x7C6/meta-retro/blob/zeus/classes/retroarch-overrides.bbclass
Jan 12 14:53:36 <dev1990_> I decided to add arm_familly and arm32 and arm64 overrides for my package set
Jan 12 17:02:00 <dev1990_> Is there a reason why Yocto passing --sysroot and other machine flags via CXX/CC?
Jan 12 17:58:32 <LetoThe2nd> dev1990_: hum, because we're crosscompiling?
Jan 12 18:04:26 <dev1990_> LetoThe2nd: https://github.com/libretro/RetroArch/pull/9995
Jan 12 18:04:38 <dev1990_> take a look if you have time
Jan 12 18:05:41 <LetoThe2nd> dev1990_: ah so the question was about the *way* being passed, not they *why*
Jan 12 18:08:31 <LetoThe2nd> no idea then :(
Jan 12 18:08:40 <LetoThe2nd> maybe khem can comment?
Jan 12 18:14:17 <dev1990_> LetoThe2nd: the question is why :)
Jan 12 18:18:44 <dev1990_> I'll introduce the problem properly
Jan 12 18:20:16 <dev1990_> I'm porting RetroArch project to Yocto. RetroArch using buildsystem that mimic autotools.
Jan 12 18:21:37 <dev1990_> ok recipe is ready, go... and fail... ./configure script failed on checking if CXX and CC is valid compiler by trying to compile simple program
Jan 12 18:22:27 <dev1990_> I patched this script to use $CXX and $CC unquoted
Jan 12 18:23:33 <dev1990_> it worked, so I pushed merge request and patch was accepted
Jan 12 18:25:25 <dev1990_> but after sometime, there was a revert on my patch bacause using $CC and $CXX in plain script is unacceptable and there is user fault and --sysroot should be passed via CXXFLAGS CFLAGS
Jan 12 18:26:40 <dev1990_> and I show this not user error and Yocto is acctualy passing parameters via $CXX $CC
Jan 12 18:27:02 <dev1990_> I take argument that I should fix that in Yocto Project
Jan 12 18:27:31 <dev1990_> s/I take argument that I should fix that in Yocto Project/they told me to fix that in Yocto/g
Jan 12 18:27:47 * dev1990_ story of my daily life
Jan 12 18:28:02 <dev1990_> I dunno
Jan 12 18:55:19 <kergoth> dev1990_: they're wrong, multi-word CC is extremely common, even just for use of ccache without symlinks (CC="ccache gcc")
Jan 12 18:55:28 <kergoth> just patch it in the recipe and leave the patch in the layer
Jan 12 18:55:33 <kergoth> rather than pushing it upstream
Jan 12 19:07:43 <khem> dev1990_: there is no base override for arm like we have for mips called mipsarch
Jan 12 19:08:06 <khem> perhaps arm and aarch64 are as basic as possible
Jan 12 19:13:24 <khem> I will be fine if we had one for arm as well given the subarch families arm has
Jan 12 19:53:37 <kovalevsky> This probably is a really piece of cake answer, I have a distro image that contains several layers. In one of those layers I have a recipe. If I already issue "bitbake <distroname>". What would be the command to issue if I change something in the recipe and want to build again the distro?
Jan 12 19:54:47 <LetoThe2nd> kovalevsky: i guess you mean an image?
Jan 12 19:54:52 <LetoThe2nd> (not a distro)
Jan 12 19:54:58 <kovalevsky> To be more accurate, since I know the whole architecture is quite of complex. The change that I made to my recipe was within a local file.
Jan 12 19:56:52 <kovalevsky> I m not quite good when it come to use the right words since I am just getting started. When I exec bitbake <distroname> I mean, I grab this name from my conf/local.conf in the variable: DISTRO = "distroname"
Jan 12 19:57:12 <LetoThe2nd> kovalevsky: if the image depends in some form on the recipe, then just rebuild the images.
Jan 12 19:57:13 <kovalevsky> In that case, I am not sure if that's the proper name.
Jan 12 19:57:33 <LetoThe2nd> that "distroname" there is a DISTRO config. its not something you can build
Jan 12 19:58:11 <kovalevsky> @LetoThe2nd, what do you mean that I can not build?
Jan 12 19:58:36 <LetoThe2nd> bitbake distroname is not gonna work.
Jan 12 19:59:02 <LetoThe2nd> (to my knowledge, and if you don't have anything else in there that happens to be buildable and bear the same name)
Jan 12 19:59:31 <LetoThe2nd> kovalevsky: you can build images and packages, but not distributions.
Jan 12 20:00:27 <kovalevsky> So, I guess there may be an image name that match the distro name and that's why I am missing the right concept.
Jan 12 20:00:44 <LetoThe2nd> kovalevsky: yes, thats probably the case.
Jan 12 20:00:56 <kovalevsky> What I am trying to in a nutshell is generate a linux / gnu embedded distribution to be able to flash into an sd car and load into my embedded device.
Jan 12 20:01:13 <LetoThe2nd> kovalevsky: thats why its a good practise for images to have "image" in their name :)
Jan 12 20:02:03 <kovalevsky> @LetoThe2nd, I will bear that in mind and let the developer know about it. Hahaha.
Jan 12 20:02:20 <kovalevsky> Since it may be understood, I got the point.
Jan 12 20:02:56 <LetoThe2nd> building an image to flash into an embedded device is such a common usecase that we take it as given unless stated otherwise :)
Jan 12 20:03:02 <kovalevsky> In that sense, If I want to change the local file of a custom recipe that lives within a custom layer inside an image, then my options are rebuild the image and that's it?
Jan 12 20:03:21 <LetoThe2nd> kovalevsky: should be, yes.
Jan 12 20:03:51 <LetoThe2nd> kovalevsky: let me suggest for you to invest some time in https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj
Jan 12 20:04:20 <kovalevsky> @LetoThe2nd, all right then. I fell like my first years diving into the nitty-gritties when I was just starting off in Linux / GNU flavors desktop distros.
Jan 12 20:05:04 <kovalevsky> @LetoThe2nd, thanks a lot. I've already pass a couple of days this week watching the first three episodes.
Jan 12 20:05:21 <LetoThe2nd> :)
Jan 12 20:06:01 <kovalevsky> And it's so knolwedgeable and fun at the same time watching Josef with the beers
Jan 12 20:06:03 <kovalevsky> hahahaha
Jan 12 20:06:22 <kovalevsky> Ok, well, thanks for your help I will check this out and see if the results are as I expected.
Jan 12 20:06:30 <LetoThe2nd> have fun
Jan 12 20:22:24 <kovalevsky> @LetoThe2nd, it works.
Jan 12 20:22:38 <kovalevsky> I will keep having playing with it. Thanks.
Jan 12 20:23:06 <LetoThe2nd> enjoy!
Jan 12 20:23:28 <LetoThe2nd> and remember to follow on twitch, respectively youtube :)
Jan 12 20:24:19 <kovalevsky> For sure I will.
Jan 12 23:25:55 <RP> khem: we already have an arm override
Jan 12 23:26:28 <RP> dev1990_: the ccache gcc is the obvious reason CC needs to support multiple things
Jan 12 23:26:52 <RP> dev1990_: as kergoth mentioned. We put sysroot there as it if goes missing, bad things used to happen
Jan 12 23:27:15 <RP> It was more obvious if CC wasn't being used
Jan 12 23:29:14 <dev1990_> RP: please consider maintion it there: https://github.com/libretro/RetroArch/pull/9995
Jan 12 23:46:30 <khem> RP: yes as I said arm and aarch64, but I was mentioning was something thats common to all arm
Jan 12 23:46:58 <khem> like mipsarch is for all mips ( including 32 and 64 bit)
**** ENDING LOGGING AT Mon Jan 13 02:59:57 2020