**** BEGIN LOGGING AT Thu Mar 12 02:59:57 2020 Mar 12 09:32:28 mornin Mar 12 09:50:06 Jin^eLD: what about ttyAMAx (where x in 0-3)? Mar 12 09:53:49 hrw: uhm... I am not yet following :) I think the tinker board has only three uarts, but I am not understanding what you are trying to tell me? Mar 12 09:54:18 there was night discussion about some arm and serial ports Mar 12 09:54:33 I was just suprised to see ttyS2 instead of ttyAMA2 there Mar 12 09:54:39 hrw: ah Mar 12 09:54:50 hrw: it was about meta-rockchip and ASUS tinker board Mar 12 09:55:08 I understood you were referencing that discussion but I did not understand what you were trying to tell me Mar 12 09:55:25 let me google up on the AMA stuff Mar 12 09:56:19 not sure if tinker provides a ttyAMA at all Mar 12 09:56:20 anyway naming of serial ports is a mess Mar 12 09:57:08 well that too, I just remember tlwoerner telling me that he picked the same tty port for kernel/userspace as the one used for u-boot (which makes sense) and i was wondering why Armbian did it differently Mar 12 09:57:26 and then I figured out that time can not be set at all in a stock meta-rockchip build Mar 12 09:57:46 tlwoerner promsied to have a look and his board and will confirm or deny that, that'll be interesting to compare Mar 12 09:58:38 but from what I found out so far it seems that when you build the clock related things into the kernel (I took armbians defconfig as a reference) then I get an error when booting Mar 12 09:58:44 and seems to be related to ttyS2 Mar 12 09:58:50 so something is fishy there Mar 12 09:59:02 well, the whole tinker board is super fishy if you ask me... but it is what it is :) Mar 12 10:00:21 I do not remember when last time I had to deal with SBC Mar 12 10:01:00 maybe I am wrong... but its the only clue I have so far and I struggle to find an explanation why date -s would not be able to set anything Mar 12 10:05:07 Jin^eLD: new date setting gone after reboot? Mar 12 10:05:32 LetoThe2nd: not after reboot - immediately after setting, you can't read it back Mar 12 10:05:59 https://paste.ee/p/bHDWd Mar 12 10:06:19 you do a date -s, it prints you that it set it, then you check with date again and still see 1970 Mar 12 10:06:25 Jin^eLD: ah, thought you might be missing hwclock -w Mar 12 10:07:11 that would have been nice, but unfortuntely its something werd, to be honest I have never experienced that on any of the boxes I have been working with in all those years... Mar 12 10:15:40 well... the RK808 does include an RTC, so that's what you'll need for saving the time, but from the datasheet, it's programmed via i2c, so i don't see (easily) why it would collide with ttyS2 Mar 12 10:15:53 maybe someone on #linux-rockchip could help? Mar 12 10:21:07 the rtc driver does not, but there is another clk driver (not sure if related? - armbian enables it) Mar 12 10:21:14 and when I enabled that one - there I had the collision Mar 12 10:21:22 rtc-rk808 gave me /dev/rtc but did not help Mar 12 10:21:34 tlwoerner: were you able to check on your device if date -s works? Mar 12 10:21:49 not yet Mar 12 10:41:41 I'll wait for your results first then and do some further debugging tonight, after that #linux-rockchip might indeed be a good idea Mar 12 14:18:31 I know there is "bitbake core-image-minimal -c populate_sdk", but is there a more "lightweight" toolchain if I only need the cross-compiler and target glibc/libstdc++ ? Mar 12 14:19:03 kroon: i think meta-toolchain or something alike. Mar 12 14:19:55 LetoThe2nd, yeah, let me try that Mar 12 14:35:19 meta-toolchain or meta-toolchain-sdk Mar 12 17:00:57 For anyone needing a break: https://sfconservancy.org/blog/2020/mar/12/virtualchat/ Mar 12 17:27:30 for anyone considering to buy AMD 3990X for OE builds: https://www.youtube.com/watch?v=VQa6r6Ci1jg but he didn't say much about 3990x nor sent me the pull request with detailed results yet Mar 12 17:37:33 JaMa: lot of threads == lot of memory sticks (to fill memory channels) + lot of memory + lot of nvme storage. then you can start thinking what next? Mar 12 17:42:26 I used 2x28x4 system. aarch64 one. 2 cpus, 28 cores per cpu, 4 threads per core. 256GB ram, ssd storage. build of single distro package done in tmpfs were not making it even busy Mar 12 17:44:33 hrw: depends on what kind of OE builds you're doing Mar 12 17:44:47 yeah Mar 12 17:44:52 I still have too many jenkins jobs which take 5+ hours on dual socket xeons Mar 12 17:45:04 ouch Mar 12 17:45:06 and even 3970x is faster for them Mar 12 17:45:32 3970X is great for OE builds for reasonable price (much faster than older dual socket Xeons), 3990X is significantly faster but for most people might not be worth double the price Mar 12 17:45:36 where are the times when I moved to single core athlon64 because of OE Mar 12 17:45:36 I'm even more interested in comparing 3990X with single socket 7702P which is only slightly faster, but isn't limited to 256G ram and with 8 memory channels and ECC might be faster and more reliable for long-term build machine Mar 12 17:46:04 256GB memory limit? sounds sucky Mar 12 17:46:19 I got used to aarch64 servers with 1-2TB per socket limits Mar 12 17:46:27 yeah I've moved to 8 core AMD bulldozer from 4 core Phenom and was really happy for OE builds for quite some time Mar 12 17:46:50 but now even 80$ Ryzen 5 1600 AF is significantly faster than that :) Mar 12 17:47:25 I think for me it was Athlon XP -> Athlon64 -> Athlon64 x2 -> Core2Duo Q6600 -> i7-2600k. and then I stopped using OE for a while Mar 12 17:47:28 and the older Xeons we still have in CI aren't worth the power they use Mar 12 17:48:01 yep Mar 12 17:48:32 I have to remind my boss about server he wanted me to move onto... Mar 12 17:49:37 from 46c -> Xc where I forgot value of X. 32/2x32/64 Mar 12 18:59:32 * tlwoerner was just in a "you should use OE" conversation in another channel Mar 12 18:59:54 it's interesting that the overall feeling is that OE is only for distro people and not for developers Mar 12 19:01:25 OE is most definitely for "developers", especially those developers who need to handle multiple boards/architectures or whose concern is for the life of a piece of software rather than just being focused on only 1 board (for example) Mar 12 19:04:32 what does "distro people" decode to? that's not quite clear to me Mar 12 19:06:13 tlwoerner what I've seen is people confuse what they are trying to do.. Mar 12 19:06:35 For -application- developers, OE (traditionally speaking) is far to complex and heavy.. but an SDK or eSDK can work great. Mar 12 19:06:57 for an integration person, OS developer, OS optimizer, etc.. OE can't be beat.. it will let you do whatever you need to get the job done.. Mar 12 19:07:38 What I see is a continuum of workflows.. binary distro (application developer focused) -> eSDK (application developer/some OS customization) -> full OE (OS customization/integration experience) Mar 12 19:08:16 that workflow also allows someone to grow in their knowledge as they need more capabilities fromt he system Mar 12 19:10:47 some developers are lucky to only have to focus on one board, one product. but any developer who has to switch boards/architectures regularly has to use something like OE, or go insane ;-) Mar 12 19:11:14 and the trend is that boards come and go in months, not decades (like they used to) Mar 12 19:45:19 I concur. It's *extra* important when you have to deal with bespoke hardware solutions Mar 12 19:46:23 We currently have 29 machines to maintain. I couldn't imagine doing that with anything else in a sane manner Mar 12 19:46:35 sweet Mar 12 19:47:01 "OE for developers" <- new focus for advocacy Mar 12 19:47:18 or a talk at a conference/meetup Mar 12 19:47:28 I'll have to work it into my talk Mar 12 19:47:32 "OE *is* for developers" Mar 12 19:47:36 If we even have a conference :( Mar 12 19:47:46 that was my next question Mar 12 19:47:57 virtual conference! Mar 12 19:48:21 I want a conference where everyone gets a telepresence robot to drive around! Mar 12 19:48:22 schedule something with LetoThe2nd and do it on twitch Mar 12 20:01:01 JPEW: what's the title of your talk? i've given talks circling around that idea a couple times, i have some material/slides/examples you might be interested in Mar 12 20:07:36 tlwoerner: Not that specifically, I'm doing "hash equivalence and reproducible builds" Mar 12 20:07:53 I try to have some "get involved" slides at the end of all my talks though Mar 12 20:17:50 JPEW: pfft, that's not for developers ;-) Mar 12 20:17:56 lol Mar 12 20:57:25 tlwoerner: there are different types of developers, e.g. application developers, system developers, kernel/firmware developers Mar 12 20:57:53 OE does not fit into all developer stories Mar 12 20:58:36 its a good system builder and hence the notion that its a distro builder Mar 12 20:59:08 and perhaps its good framework for building tools and workflows for application developers too but as such its not there Mar 12 20:59:42 look at Android Developer Studio e.g. thats an application development environemnt or Xcode for that matter Mar 12 20:59:51 OE doesnt have anything like that Mar 12 21:00:20 I think a lot boils down the the willingness to learn; I often had cases were people would just ask me to generate an external toolchain, because they were used to that and it was easier for them to compile their stuff that way Mar 12 21:00:46 I personally always appreciated that OE took care of all those tons of compile flags and options and what not and that I could simply devshell into my project and focus on the actual code Mar 12 21:01:24 I would not say its about willingness to learn, build systems should be invisible and OE is not invisible Mar 12 21:01:48 and application developers are experts in different areas not build systems Mar 12 21:01:51 but then again - took me some time to get to that level and I guess it was also somewhat easier for me, because I started learning OE before bothering to learn to use an external toolchain :) I think that might have been 14+ years ago Mar 12 21:02:25 ratio of system devs to app devs is almost 1 to 10 Mar 12 21:02:47 khem: well, if someone sets up the OE part for you (and usually you have a guy who takes care of the distro), then the app dev does not need to know that much, except for sourcing some environment and a few bitbake commands Mar 12 21:03:16 the fact that there are no chromium or firefox developers using OE speaks volumes that there is something amiss Mar 12 21:03:17 so willingness to learn is a par tof it, because "its not what I am used to, so its scary" Mar 12 21:03:47 right, try to compile that stuff even without OE, you probably grow some grey hair instantly ,) Mar 12 21:03:55 I am saying you can have willingness to learn but what does that buy me to learn a complex build system Mar 12 21:04:56 chromium has 35 million lines of code Mar 12 21:04:59 question is if you as a dev need to learn all of it? I was usually tasked with taking care of the internal distro and everyoen could just pull and build it "out of the box", so the number of stuff you'd really have to "learn" in order to use it for development was actually quite low Mar 12 21:05:24 a browser developer has enough at hand to deal with Mar 12 21:05:25 and if someone ran into trouble I'd help, but still a lot of guys did not even want to try Mar 12 21:05:57 i.e. "gimme my toolchain and leave me alone" Mar 12 21:06:32 also look from their point of view Mar 12 21:08:20 Jin^eLD: you are assuming a lot here on behalf of app devs Mar 12 21:08:42 they need to modify code and apps build infra at same time Mar 12 21:09:14 so If I was doing that I would prefer to have contained env where I Can easily do those changes Mar 12 21:09:27 perhaps OE still misses the mark Mar 12 21:10:43 well, from what I've seen a dev usually works on some application, not on tons of them at the same time Mar 12 21:10:59 and there OE is a self contained environment - you get all dependent projects that others are working on Mar 12 21:11:01 and can focus on your own Mar 12 21:11:27 but yes, I was one of the very few who preferred to cross compile in oe's devshell when developing/testing something for the target Mar 12 21:11:59 these days a lot of stuff is anyway platform independent, so most simply do their x86 builds and jenkins cross compiles Mar 12 21:12:24 at least that was my personal experience, can't judge if this is the situation for the majority or not Mar 12 21:14:10 argh, just compile WebKit! Mar 12 21:15:02 I have interacted with vast set of developers and every different developer type has different needs Mar 12 21:15:25 so when you say OE for developers then qualify it Mar 12 21:22:03 someone in a different channel was complaining about how hard it is to do cross-development because of having to create images and get all the fiddly bits right (i.e. bootloader, image layout, etc) plus then having to setup and use a cross-compiler without host contamination, finding the right headers, etc Mar 12 21:22:12 so i said "give oe a try" Mar 12 21:22:31 and someone else immediately poo-pooed the idea claiming oe was only for distro people Mar 12 21:22:56 which prompted my comment that, in many ways, oe *is* for developers... they might just not know that (yet) Mar 12 21:23:46 it's unfortunate that oe isn't more widely known or used, and what it is known for is (allegedly) that it is not for developers (a statement with which i disagree) Mar 12 21:24:37 i'm not saying it's everyone's magic solution to all their problems, but i think it would help more people if they gave it a try, and it's sad that the idea of even trying it is shot down as being the wrong tool Mar 12 21:27:10 and anytime i offered a point as to why oe would be worth trying, the other person shot down each idea saying it didn't apply to him (while ignoring the case that it might apply for others) because he only has to deal with one board and doesn't build anything other than mesa Mar 12 21:32:27 heh, we build bleeding mesa all the time to test panfrost... it works really well Mar 12 21:37:24 JPEW: awesome! (and thanks to you) Mar 12 21:41:32 tlwoerner: I still think that all those pseudo-arguments against trying originate in the fact that people are easily scared by something that appears big and complex, because they just "need one package to compile" or whatever Mar 12 21:42:00 i.e. oh why should I even try that huge thing, it seems so complicated, I'll continue the way I am used to Mar 12 21:42:14 Jin^eLD: agreed, people working with bleeding edge computers and electronics are surprisingly adverse to learning new things ;-) Mar 12 21:42:43 I have to admit that I am also very conservative in the stuff I use or ways how I want things to be Mar 12 21:43:02 nothing scarier than a distro upgrade when you find out your font is no longer supported or something like that :> Mar 12 21:43:36 so I can kind of do understand why someone might hesitate to even try Mar 12 21:46:13 tlwoerner: well, there is one more point of course - who are those people? someone who is really interested, or someone who just does his job and is used to his tools and runs off then the workday is over Mar 12 21:46:23 one always needs personal motivation to learn new stuff :) Mar 12 21:47:11 "i pressed F7 in eclipse and it didn't compile, so i checked the code in anyway and went home" lol Mar 12 21:48:10 don't laugh but that's exactly what I mean :) Mar 12 21:49:38 oh i know, i think we've all been there, we all know "that" type of developer, haha lol Mar 12 21:49:48 Well, my 1 TB of sstate cache is full, so I'm going to clean it and go home so I can build tomorrow :) Mar 12 21:50:00 JPEW: =) Mar 12 21:50:24 * tlwoerner thinks JPEW needs larger disks Mar 12 22:08:45 8TB drives, at least Mar 12 22:08:54 preferrably a server full of them Mar 12 23:57:30 tlwoerner: I am playing devil's advocate here, the usecase developer in other channel mentioned is very common Mar 12 23:59:48 if I am mesa developers, I just want to touch mesa everything else should be static and I would like the edit-compile-load-debug cycle to be as short as possible Mar 13 00:00:28 something like devtool is what you can pitch for such usecase Mar 13 00:01:39 sstate is good for reproducing builds but for mesa developer it is useless Mar 13 00:01:53 so think in their shoes Mar 13 00:04:47 always building image is a sub-optimal solution where you can easily replace 1 or 2 packages in entire rootfs Mar 13 00:05:12 what we need is well written templates that people can follow **** ENDING LOGGING AT Fri Mar 13 03:00:43 2020