| RP | Marex: not sure how well/tested this is in practise but I'm fairly sure it could be made to work | 00:00 |
|---|---|---|
| Marex | RP: doesn't linux-yocto and linux-yocto-rt already have a different namespace ? | 00:00 |
| Marex | RP: all right, I will put it on the list of things to investigate, thanks! | 00:00 |
| RP | Marex: the module output names may or may not be, not sure | 00:00 |
| RP | Marex: you're right, PN is already fine there | 00:01 |
| Marex | RP: I will take a look, thanks! | 00:02 |
| RP | kanavin_: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1307 is odd :/ | 00:14 |
| RP | (python2.7 needed by piglit?) | 00:14 |
| RP | That was in a build with py2 removal so it shouldn't be there? | 00:14 |
| RP | ah, that was a ross/next build | 00:16 |
| RP | mine is the much redder build :( | 00:17 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 00:29 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 00:43 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 01:09 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 01:36 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 01:36 | |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto | 01:51 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has quit IRC | 01:57 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has joined #yocto | 01:59 | |
| *** tz <tz!~tz@orange.tzarc.io> has quit IRC | 03:41 | |
| *** tz <tz!~tz@orange.tzarc.io> has joined #yocto | 03:45 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 05:40 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 05:45 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 05:58 | |
| *** toner <toner!~ink@107-199-78-50.lightspeed.mtryca.sbcglobal.net> has quit IRC | 05:59 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:21 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 06:41 | |
| *** xtron <xtron!~xtron@110.93.212.98> has joined #yocto | 06:43 | |
| *** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has joined #yocto | 07:03 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 07:10 | |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 07:26 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:36 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto | 07:37 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:42 | |
| *** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-klczutozytbzuauq> has joined #yocto | 07:43 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto | 07:46 | |
| ThomasD13 | I've created a linux-raspberrypi-rt_%.bbappend file, to add a configuration fragment and a patch to the kernel sources: https://pastebin.com/HKpy2VbU | 07:49 |
| *** Saur <Saur!pkj@nat/axis/x-qewlovcmryuamlgx> has quit IRC | 07:49 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 07:50 | |
| ThomasD13 | When I build a image with yocto, the patch and configuration fragment got applied to the kernel. However, when I build the eSDK, and build a image with that eSDK, the patch and fragment got NOT applied to the kernel source. | 07:50 |
| *** Saur <Saur!pkj@nat/axis/x-ttvqjligxffmcicx> has joined #yocto | 07:51 | |
| ThomasD13 | Have I done something wrong with that bbappend-file? | 07:51 |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 07:52 | |
| *** mckoan|away is now known as mckoan | 07:53 | |
| yocti | New news from stackoverflow: bitbake fails at the simplest recipe <https://stackoverflow.com/questions/50015145/bitbake-fails-at-the-simplest-recipe> | 07:58 |
| wertigon | Hmm, thud doesn't seem to have CLANGSDK, but it does have NATIVESDKCLANG | 08:08 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 08:12 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 08:19 | |
| wertigon | Looks like thud is SOL, our only option for now is to build the SDK with layers disabled, but at least I know it will be fixed in the future. | 08:23 |
| *** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-nfrqepxxbhoouxkr> has joined #yocto | 08:27 | |
| ThomasD13 | I think that cause the missing patching of kernel sources in eSDK: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/scripts/lib/devtool/standard.py?id=7a6a5dcf9c5cefaccd2e4b0741bfba88eb8125d1 | 08:37 |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 08:38 | |
| ThomasD13 | Can someone explain me, why this has been changed again? Since it was explicit added (http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112242.html) | 08:38 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 08:52 | |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 09:03 | |
| Ad0 | I see that most yocto build guides put IMAGE_INSTALL_append in local.conf. but in a custom distro layer, where should this reside? | 09:08 |
| LetoThe2nd | Ad0: no | 09:09 |
| LetoThe2nd | they should reside in an image recipe | 09:09 |
| Ad0 | right | 09:09 |
| LetoThe2nd | Ad0: https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj - video #2 | 09:09 |
| Ad0 | does he do it "the right way" := | 09:10 |
| LetoThe2nd | Ad0: he does. | 09:10 |
| Ad0 | awesome | 09:10 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:11 | |
| Ad0 | https://github.com/rossburton/customdistro/blob/master/meta-custom/recipes-example/images/customimage.bb | 09:12 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-ygdifdfwnqedrywn> has joined #yocto | 09:15 | |
| *** goliath <goliath!~goliath@nat001-WLTU1.uibk.ac.at> has joined #yocto | 09:15 | |
| LetoThe2nd | Ad0: to go totally nitpicking, in that case i would rather have used IMAGE_INSTALL_append instead of CORE_IMAGE_EXTRA_INSTALL. but both should work fine in that context. | 09:16 |
| Ad0 | thanks | 09:16 |
| Ad0 | "There's many ways to skin a cat | 09:17 |
| Ad0 | " | 09:17 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:18 | |
| qschulz | Ad0: you're asking LetoThe2nd if what LetoThe2nd said in that video is "the right way" :D | 09:19 |
| Ad0 | hahaha :) I had no idea. very cool LetoThe2nd , I will watch them in full | 09:19 |
| LetoThe2nd | qschulz: now you owe me a beer for giving the joke away! :P | 09:20 |
| qschulz | LetoThe2nd: damn it. | 09:29 |
| Ad0 | haha | 09:31 |
| wertigon | rburton: Your CLANGSDK="" fix works for zeus but unfortunately not thud, but it's ok, I'll just disable the relevant layers for now when building the SDK, and then use your fix once ti upgrades to Zeus :) | 09:33 |
| wertigon | Thank you for all help provided yesterday, it managed to solve my issues! | 09:34 |
| LetoThe2nd | but acutally a good reminder, have to announce the next session | 09:36 |
| *** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has quit IRC | 09:41 | |
| *** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has joined #yocto | 09:43 | |
| wertigon | Ok, one tiny problem left; we need arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/8.2.0/as.exe for our mingw package | 09:44 |
| wertigon | I assume I can just add it as a package somewhere, just wondering which package? | 09:44 |
| LetoThe2nd | wertigon: to me it rather sounds like a packaging problem. shouldn't as be part of the gcc packge? | 09:50 |
| wertigon | LetoThe2nd: That's what I figured as well. I'll rebuild the entire SDK using populate_sdk (used meta-toolchain earlier) and mingw, then we shall see if there are more bugs... :) | 09:53 |
| rburton | wertigon: probably trivial to backport the fix from meta-clang's zeus branch | 09:54 |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 09:57 | |
| wertigon | rburton: Probably, I'll do a quick look at the git log if it's in a single or a couple of commits there | 09:57 |
| wertigon | rburton: Though thud is already slowly being phased out in most projects, that's the price you pay being on the bleeding edge and at the same time working with realtime environments :D | 09:58 |
| *** JaMa <JaMa!~martin@109.238.218.228> has joined #yocto | 10:01 | |
| wertigon | rburton: Yes, ccfdb47cc4991a seems to be the ticket | 10:01 |
| Ad0 | I have an XPS 15 with 4 cores. I have to get a different computer for this | 10:03 |
| LetoThe2nd | Ad0: depends. | 10:03 |
| Ad0 | why does bitbake add layers with a full home path as default instead of a relative path to a root variable? | 10:05 |
| Ad0 | or it seems like it in the videos | 10:05 |
| LetoThe2nd | Ad0: the bblayers entries are usually absolute, yes. | 10:06 |
| wertigon | Tried cherrypicking SDK now; hopefully it will work, and that makes my life much easier | 10:09 |
| wertigon | rburton: Cherry pick didn't work :( | 10:09 |
| wertigon | rburton: Trying again with CLANGSDK in local.conf (had it in my image conf first) | 10:11 |
| rburton | yeah its not a image variable | 10:11 |
| rburton | should be, but isn't | 10:11 |
| wertigon | Ok, it works in my local.conf | 10:12 |
| LetoThe2nd | wertigon: remember, remember: whenever you want to affect something that is *not* in the vey file you are looking at, then it hast to go in a .conf, not a .bb | 10:12 |
| LetoThe2nd | now aloud, everybody together: "conf data is global, recipe data is local"! | 10:13 |
| wertigon | Or rather, I get past one error but not another one; | 10:13 |
| wertigon | * Solver encountered 1 problem(s): * Problem 1/1: * - nothing provides clang-cross-canadian-arm needed by packagegroup-cross-canadian-sitara-1.0-r0.x86_64-nativesdk-mingw32 * * Solution 1: * - do not ask to install a package providing packagegroup-cross-canadian-sitara | 10:13 |
| wertigon | :D | 10:13 |
| wertigon | Oh, so it should be able to go into a layer.conf then? | 10:14 |
| LetoThe2nd | it should be. i totally despise hiding stuff in a layer.conf, but there are fringe cases where it can be helpfuil. just make very, very clear in your layer documentation that you stuck something in there. | 10:16 |
| wertigon | Yeah, I understand... The way we have things setup here, we have our own custom layer that pulls in everything else | 10:16 |
| wertigon | So I say it's pretty o.k. to let our custom layer do config shenanigans like that :) | 10:17 |
| LetoThe2nd | wertigon: just think of your coworker or future self who has to debug and understand it in 2 or 3 years time. | 10:18 |
| *** goliath <goliath!~goliath@nat001-WLTU1.uibk.ac.at> has quit IRC | 10:18 | |
| wertigon | True. | 10:18 |
| wertigon | I'll let the zeus backporting be for now; seems to be a rabbit hole that goes deeper than I had hoped | 10:19 |
| LetoThe2nd | and *nobody* looks inside a layer.conf, unless being either totally crazy/confused/desperate, or being pointed there by the docs. | 10:19 |
| wertigon | LetoThe2nd: granted, maybe distro.conf then | 10:20 |
| LetoThe2nd | wertigon: yes, thats a WAY better place. | 10:20 |
| wertigon | Ok, added it to the proper place now | 10:29 |
| wertigon | Now I just gotta run a populate_sdk, and then everything should work :D | 10:30 |
| rburton | wertigon: this should be in your distro layer | 10:53 |
| rburton | layer.conf is only useful for setting defaults, ie meta-intel uses layer.conf to set preferred provider for zlib as it ships an alternative | 10:54 |
| kanavin_ | RP: I reproduced the piglit issue, looking into it. | 11:09 |
| kanavin_ | RP: piglit hardcodes a list of suitable python versions, we only need to update to latest revision to have python 3.8 included into the list | 11:13 |
| kanavin_ | patch on the way | 11:13 |
| RP | kanavin_: ah, that explains it thanks! | 11:13 |
| kanavin_ | RP: the host contamination thing might be tricker as I have not seen it locally, but I'll try | 11:14 |
| RP | kanavin_: I think rburton understands that one? | 11:14 |
| kanavin_ | RP: I have not seen an indication from him that he does? | 11:14 |
| RP | kanavin_: I'm not sure which is why I'm asking him | 11:15 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 11:19 | |
| kanavin_ | RP: patch for piglit sent | 11:22 |
| rburton | no i haven't seen the host contamination either | 11:26 |
| kanavin_ | I am trying with x86 (32bit) MACHINE now, I was using x86-64 target before | 11:28 |
| kanavin_ | (as that's the target where it produced the warning?) | 11:28 |
| rburton | ok going to throw my next at the ab again but without py38 to get that bundle into master at least | 11:28 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 11:38 | |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:42 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 11:45 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 11:46 | |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:46 | |
| RP | kanavin_, rburton: FWIW that contamination usually occurs when something creates a file outside psuedo context. I suspect some of the python pgo code is causing a file to be generated out of context when pseudo isn't active? | 11:47 |
| rburton | nothing pgo touches should be installed. *should* | 11:48 |
| kanavin_ | RP: possibly, but I am still not seeing it :( | 11:48 |
| RP | rburton: gah, you beat me to starting a test build :) | 11:49 |
| rburton | mine should be fairly rapid | 11:49 |
| kanavin_ | ah! if bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', True, False, d) and d.getVar('BUILD_REPRODUCIBLE_BINARIES') != '1': | 11:49 |
| kanavin_ | d.setVar('PACKAGECONFIG_PGO', 'pgo') | 11:49 |
| rburton | hm thats an annoying thing about reproducible | 11:50 |
| rburton | because pgo is good on py | 11:50 |
| RP | Yes :( | 11:50 |
| RP | we need a nearly reproducible option :/ | 11:50 |
| RP | or pregenerated profiles I guess | 11:51 |
| RP | actually, there is a huge problem with the host compiler dependency and reproducibility when combined with hashequiv | 11:52 |
| RP | this arm/x86 host thing I'm chasing also applies with two x86 hosts with different native compilers | 11:53 |
| wertigon | rburton: Yep, added it to distro/mydistro.conf in my distro layer ^^ | 11:53 |
| * RP 's head starts to hurt | 11:53 | |
| wertigon | Hmmm, question; right now we are basing our distro on Poky and pull in TI stuff from the side; | 11:54 |
| wertigon | how hard would it be to remove poky from that equation? | 11:54 |
| rburton | easy | 11:54 |
| rburton | poky is basically nothing | 11:55 |
| RP | wertigon: there isn't a lot in poky so it wouldn't be hard but probably wouldn't change much | 11:55 |
| rburton | just copy/paste the bits in poky.conf that you care for | 11:55 |
| wertigon | Yeah, that's what I figured | 11:55 |
| rburton | i endorse people making their own distro so they don't get a surprise when e.g. poky switches init system | 11:55 |
| rburton | make your own distro and you control those changes | 11:55 |
| wertigon | It's pretty much poky.conf and build environment setup script right? | 11:55 |
| rburton | the setup script is oe-core's | 11:55 |
| wertigon | Ah, right | 11:56 |
| wertigon | We're coming up to a cleanup-period now | 11:56 |
| rburton | https://github.com/rossburton/customdistro <-- might be useful | 11:56 |
| wertigon | Ok :) | 11:56 |
| wertigon | Yeah, that's not really a lot of code | 11:59 |
| wertigon | And broken my grammar module seems | 12:01 |
| wertigon | :p | 12:01 |
| wertigon | Ok, but great - the less messy we can make this the better | 12:01 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 12:08 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 12:16 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 12:16 | |
| kanavin_ | rburton, RP with or without pgo, I am still not seeing the contamination warnings :-/ | 12:22 |
| yocti | New news from stackoverflow: What is the difference between PREMIRRORS and SOURCE_MIRROR_URL <https://stackoverflow.com/questions/46449301/what-is-the-difference-between-premirrors-and-source-mirror-url> | 12:29 |
| ThomasD13 | wertigon, you said that you switched away from arago. How hard is it, to pull the TI stuff in such a way, that everything works after? | 12:38 |
| wertigon | ThomasD13: We switched from Arago in order to have more control over our distribution, though the merge is not fully done yet - first step was to switch to poky with arago as a middle layer | 12:39 |
| ThomasD13 | Do you only need to add the specific TI layers? Or is more effort required? | 12:39 |
| wertigon | From what we can see, it's not that much extra effort, arago is like poky, a reference distro | 12:39 |
| wertigon | So you need to create your own distro layer pretty much, which is easier than it actually sounds like :) | 12:40 |
| wertigon | When done, we should only have the meta-processor-sdk and meta-ti layers left | 12:40 |
| ThomasD13 | wertigon, cool! I thought about the same the last few weeks. | 12:42 |
| LetoThe2nd | wertigon: exactly what we keep preaching here. making an individual application and distro layer is no magic at all! | 12:42 |
| ThomasD13 | How you do you handle the MACHINE definition for the TI recipes? Just defining in your own distro layer? | 12:42 |
| wertigon | We simply copied the machine definitions to our distro layer | 12:43 |
| wertigon | And referred them from there instead | 12:43 |
| ThomasD13 | okay, so you don't call bitbake with MACHINE=AM45xxx blabla | 12:43 |
| rburton | really the machine defintions should be in a separate layer, so you can use those without using their distro | 12:43 |
| wertigon | No, we still do that ;) but that's because we support multiple machines with this distro | 12:44 |
| ThomasD13 | alright, really cool stuff. Thanks wertigon ;) | 12:44 |
| wertigon | rburton: agree with you there :) | 12:44 |
| wertigon | rburton: When we started this project I wasn't around and the guys that were charged in bravely and completely blind XD | 12:46 |
| wertigon | So I'm starting to see how to straighten up the structure to make it more managable now :) | 12:47 |
| rburton | +1 :) | 12:47 |
| wertigon | Like with most software projects, if it works it isn't wrong per se, but at the same time it can be made so much better! :P | 12:49 |
| wertigon | Single-distro-layer-for-everything approach does tend to smell after a while... | 12:50 |
| LetoThe2nd | a "while"? | 12:51 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 12:51 | |
| LetoThe2nd | you mean like, 10 minutes, i presume? | 12:51 |
| wertigon | LetoThe2nd: Depends on how much you are trying to cram in there, how much you have been working on it, and how many other guys are involved :P | 12:52 |
| wertigon | But after 6 months the stench does tend to reach epic proportions | 12:53 |
| ThomasD13 | LetoThe2nd, did you record any videos that describe to setup/configure own distribution? | 12:53 |
| LetoThe2nd | ThomasD13: not as a focus, but #2, #7 and #8 each contain bits and pieces of it. certainly enough to get started. | 12:57 |
| ThomasD13 | okay | 12:57 |
| wertigon | ThomasD13: rburton sent this skeleton distro: https://github.com/rossburton/customdistro | 12:58 |
| wertigon | Don't know if that helps any, but picking through the code opened my eyes to how small a distro can be. :) | 12:59 |
| LetoThe2nd | wertigon: you can totally even build without a distro.... | 12:59 |
| LetoThe2nd | as i basically do in video #8 | 12:59 |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 13:02 | |
| ThomasD13 | thanks wertigon. I have to figure out what kind of stuff are normally specified in a "distribution". I think points like which kernel, which init system, etc... | 13:02 |
| ThomasD13 | I'm just little bit confused about the border between "Image" and "Distribution" | 13:03 |
| ThomasD13 | + which bootloader | 13:03 |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 13:05 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 13:10 | |
| qschulz | LetoThe2nd: it's time for your analogy :) ^^^^ | 13:18 |
| qschulz | ThomasD13: bootloader and kernel selection is machine specific. Init system selection is distribution specific | 13:19 |
| ThomasD13 | qschulz: okay, then I assume for example logging system is also distribution specific? | 13:20 |
| Ad0 | LetoThe2nd, your videos are awesome because you actually run into errors and show how to solve it | 13:20 |
| qschulz | ThomasD13: In my mind a good rule of thumb is, if anything requires recompiling 90% of your stuff and it changes "often", then it should be part of the distro. E.g. toolchain flags, toolchain, libc, init system, ... selection. | 13:24 |
| qschulz | If it's "just" one package to install in one binary and not the other, usually in an image it's fine | 13:25 |
| qschulz | but the line is still blurry between distros and images (we use poky so I didn't have much chance to get in-depth in that aspect) | 13:25 |
| qschulz | in my mind | 13:27 |
| ThomasD13 | qschulz, I'm relieved that also experts use a "rule of thumb" ;) thanks for your thoughts | 13:27 |
| qschulz | ThomasD13: not an expert, merely a contributor :) Grain of salt as always :) | 13:28 |
| GeneralStupid | Hi, how do i put uboot into a SPI flash. | 13:38 |
| GeneralStupid | i tried with dd but its not booting. | 13:38 |
| *** palate <palate!~palate@unaffiliated/palate> has joined #yocto | 13:39 | |
| qschulz | GeneralStupid: if it's a NAND, flash_erase the partition before writing and then use nandwrite | 13:40 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 13:42 | |
| GeneralStupid | qschulz: where do i find this tools? | 13:57 |
| GeneralStupid | are they part of uboot? | 13:58 |
| qschulz | no, those are Linux tools. mtd-utils I guess? | 14:05 |
| qschulz | http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/mtd/mtd-utils_git.bb | 14:05 |
| qschulz | in U-boot, nand erase or nand erase.part and nand write. Or can be sf command depending on the U-Boot version you're using and the SPI flash you have. I don't know much more, you can write to #u-boot | 14:07 |
| qschulz | ah wait.. IIRC, you're using some imx6 chip. You might have to use imx-kobs or kobs-ng from Linux to flash the SPI otherwise you're missing the DBBT and other fun stuff like this | 14:09 |
| qschulz | Refer to the documentation or vedor for this | 14:09 |
| GeneralStupid | qschulz: imx6 is true | 14:09 |
| GeneralStupid | so mtd-utils should work because its using the linux kernel drivers ? | 14:10 |
| qschulz | mtd-utils is used to write to nand flash, that's all I can say. I don't think you can dd to it like that, I don't know the reason behind (OOB data, bad block management, etc.). There's Google or #mtd for that, but I really don't know what's happening under the hood | 14:12 |
| qschulz | one thing for sure is that you need to erase parts of your NAND before writing to it | 14:13 |
| *** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC | 14:14 | |
| *** wertigon <wertigon!8addfa13@138.221.250.19> has quit IRC | 14:14 | |
| *** litb <litb!~jschaub@pd907fca9.dip0.t-ipconnect.de> has joined #yocto | 14:14 | |
| litb | hello folks! | 14:14 |
| litb | how can I mark a .bbappend file specific to a branch name? | 14:15 |
| litb | i.e i have a layer that's supposed to be compatible with warrior and zeus. and I have .bbappend files for versions that are not anymore available in zeus | 14:15 |
| qschulz | make separate branches | 14:15 |
| litb | so I want to mark those .bbappend files branch-specific | 14:15 |
| litb | hm | 14:15 |
| litb | no other way around? | 14:15 |
| qschulz | depend on what's done by the bbappend | 14:15 |
| litb | maybe make a .bbappend for 'foo_%.bbappend' and within, include 'foo_${PV}.inc' ? | 14:16 |
| litb | ah, that's a good idea, I think. but will it work? | 14:16 |
| qschulz | if that's applicable to every version in the same major number or for all versions to date, use % | 14:16 |
| qschulz | e.g. foo_3.%.bbappend | 14:17 |
| litb | will my include approach work aswell? | 14:17 |
| *** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has joined #yocto | 14:17 | |
| *** wertigon <wertigon!8addfa13@138.221.250.19> has joined #yocto | 14:17 | |
| litb | qschulz, hmm, I guess that the branch approach is cleaner, after all. | 14:17 |
| litb | thanks! | 14:18 |
| qschulz | litb: also, try to upstream it if you can and if it makes sense for the upstream project | 14:18 |
| qschulz | i.e. patch sent to foo maintainer or patch sent to YP if applicable to the recipe only | 14:19 |
| *** mckoan is now known as mckoan|away | 14:20 | |
| GeneralStupid | qschulz: i just dont get why uboot is not able to find my dtb ( which is present ) anymore :D i have to dig deeper into this stuff. | 14:33 |
| *** xtron <xtron!~xtron@110.93.212.98> has quit IRC | 14:35 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 14:37 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 14:38 | |
| qschulz | GeneralStupid: where is your dtb present? what do you mean by u-boot is unable to find the dtb? | 14:40 |
| wertigon | Right, why does it say "error: CreateProcess: no such file or directory" when I try to compile hello world on windows cmd.exe? | 14:41 |
| wertigon | that is, I run cmd.exe, go to my sdk folder, run the environment script and then type | 14:42 |
| wertigon | %CC% hello.c | 14:42 |
| JPEW | wertigon: What version (e.g. zeus, warrior, thud...)? | 14:43 |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 14:47 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC | 14:51 | |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC | 14:52 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto | 14:53 | |
| wertigon | thud | 14:55 |
| wertigon | I managed to get it to work with a native SDK on WSL, but I need to get it to work on Windows without WSL :P | 14:56 |
| * wertigon mutters about stupid stubborn corporate policies | 14:56 | |
| JPEW | wertigon: Hah, ya. It's designed to work w/o WSL :) | 14:56 |
| wertigon | JPEW: I mean, I managed to get an SDK built for Linux host to work on WSL | 14:57 |
| wertigon | Now I have built an SDK for Windows through mingw | 14:57 |
| wertigon | And... Error -_- | 14:58 |
| JPEW | wertigon: Right :) | 14:58 |
| wertigon | Hmmm | 14:59 |
| wertigon | Aaaaah | 14:59 |
| wertigon | I need to open a NEW command prompt | 14:59 |
| wertigon | since cmd.exe is shittyMcShits | 14:59 |
| wertigon | of command prompts | 14:59 |
| wertigon | :P | 14:59 |
| JPEW | wertigon: Indeed. Do you know the exact problem? | 15:00 |
| wertigon | ... | 15:00 |
| wertigon | set is not permanent :P | 15:00 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 15:01 | |
| RP | JPEW: realised more problems in runqueue, testing a revised version | 15:01 |
| JPEW | RP: Ok, is that on master-next? | 15:02 |
| RP | JPEW: yes | 15:02 |
| GeneralStupid | qschulz: its on the SD card (mmcblk1p1) | 15:02 |
| RP | JPEW: basically I wasn't feeding the revised hash back to rehash based on it | 15:02 |
| RP | JPEW: I ended up shortcutting the whole thing to stop it flipping values back and forth | 15:03 |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC | 15:03 | |
| JPEW | RP: Ok. I still don't think you are reporting the correct thing to the hash server, I'm drafting a patch to fix it up. | 15:03 |
| RP | JPEW: I think my code may have a "bug" where it should look at all valid setscene tasks and not just covered ones though :/ | 15:03 |
| RP | JPEW: entirely possible, I'm getting very confused with it not | 15:04 |
| RP | now | 15:04 |
| RP | JPEW: the runqueue change is right but the hashserve side may not be | 15:04 |
| wertigon | Hmmm, %CC% shows quite a few brokennesses | 15:04 |
| JPEW | RP: Ok, I'll push my fixup on top of master-next so you can easily squash it in | 15:04 |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 15:04 | |
| JPEW | (on a contrib branch) | 15:04 |
| RP | JPEW: thanks | 15:05 |
| wertigon | It has a lot of references to non-existent directories like xxxxxxxxxx.../yyyyyyyy... | 15:05 |
| JPEW | wertigon: Not sure I follow, can you post more detail output? | 15:05 |
| wertigon | Sure, hang on | 15:06 |
| JPEW | RP: I think I came up with better argument names: wanted_unihash and current_unihash | 15:06 |
| RP | JPEW: yes, I like that | 15:07 |
| wertigon | JPEW: pastebin.com/dAc8A3Fs | 15:08 |
| JPEW | wertigon: Hah, I thought xxxxx.../yyyy... was some attempt to hide paths, not that you were being literal ;) | 15:08 |
| wertigon | No, quite literal in this case :P | 15:09 |
| RP | wertigon: I thought you were masking it too! Interesting. I wonder if gcc is doing that internally? :/ | 15:09 |
| wertigon | I think it is something that bitbake / meta-mingw does, because I see similar things there | 15:10 |
| JPEW | I think it's trying to posion the paths so that you have to provide the valid ones on the command line | 15:11 |
| JPEW | The ones provided at configure time can't be known, so they are set to be invalid | 15:11 |
| wertigon | Ok | 15:12 |
| wertigon | Any way I can fix that? | 15:12 |
| JPEW | wertigon: I'm not sure thats the problem | 15:13 |
| wertigon | aha | 15:13 |
| JPEW | Can you try manually running the assembler command it's trying to invoke? | 15:14 |
| JPEW | c:/users/sepeeks2/sdk/sysroots/x86_64-spark-mingw32/usr/bin/arm-oe-linux-gnueabi/../../libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/8.2.0/as.exe | 15:14 |
| wertigon | yes | 15:15 |
| JPEW | Does it work? | 15:15 |
| wertigon | The system cannot execute the specified program | 15:16 |
| JPEW | Ok, the assembler is broken then :) | 15:16 |
| JPEW | That sounds familiar.... | 15:16 |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 15:17 | |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto | 15:17 | |
| wertigon | Argh... So close to get mingw to work, yet so far -_- | 15:18 |
| JPEW | wertigon: Ya, sorry. The newer releases work a lot better because we added automated AB testing | 15:18 |
| JPEW | You might try backporting 7697cef ("mingw-w64-{headers,runtime,winpthreads}: Upgrade 5.0.3 -> 6.0.0") to thud | 15:19 |
| wertigon | ... It has been blocked by Windows since the program is "downloaded" | 15:19 |
| JPEW | Oh, wait | 15:19 |
| wertigon | Is what the error message seems to mean | 15:19 |
| JPEW | Do you have the latest thud? | 15:19 |
| wertigon | WFT :P | 15:19 |
| wertigon | Yeah, pretty much | 15:20 |
| JPEW | Incluing the GCCPIE fix in meta-mingw? | 15:20 |
| wertigon | Yeah, I seem to have that | 15:20 |
| wertigon | 6556cde16f... | 15:20 |
| JPEW | OK. Well, maybe some scanner is blocking it then | 15:21 |
| wertigon | Let's try scanning it for threats with my antivirus | 15:24 |
| JPEW | RP: Hmm, I notice that the new logic only updates the task taskhash if the unihash was reported as equivalent... is there a reason for that? | 15:24 |
| JPEW | wertigon: Do you have some directory that is blacklisted by your various scanners? | 15:25 |
| JPEW | We have to have one and put our SDKs in it or things get broken | 15:25 |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 15:26 | |
| wertigon | JPEW: I think it's as you say | 15:27 |
| wertigon | It's a rights permissions issue | 15:27 |
| wertigon | great :) | 15:27 |
| wertigon | Ok, so basically I'm trying to run a program that is not trusted | 15:28 |
| wertigon | Woohoo yay go Windows! :D | 15:29 |
| wertigon | Will need to double check this tomorrow, have a nice evening! :) | 15:29 |
| roussinm | I'm going to resstart a topic from yesterday, why IMAGE_NAME is an hard assignment? Same for IMAGE_LINK_NAME, the only way we found to override is to patch poky on our side or to addtask to our recipe and modify it for each of our images. | 15:33 |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 15:41 | |
| kergoth | roussinm: hard assignment where? if it's set in image.bbclass, just define it *after* the inherit line in the recipe, not before | 15:47 |
| kergoth | inherits occur *exactly there*. order matters. | 15:47 |
| kergoth | also, even if that didn't work, you could use an override | 15:47 |
| *** thierryE <thierryE!sid286446@gateway/web/irccloud.com/x-qvnjfbfdtmzbmewz> has joined #yocto | 15:49 | |
| roussinm | kergoth: The hard assignment is in bitbake.conf | 15:50 |
| kergoth | then any recipe can override it, as it can any configuration variable. if you want to override it in a distro or osmething, use overrides | 15:51 |
| roussinm | kergoth: So I could do this in theory : IMAGE_NAME_mymachine = "MY_IMAGE_name" | 15:52 |
| roussinm | We don't want it at the recipe level, but at distro level. So it would be inside our distro configuration file. | 15:53 |
| RP | JPEW: if it couldn't report it I'm not sure what should happen :/ | 15:55 |
| sjolley_ | YPTM: Monthly Project Meeting Tuesday Dec. 3rd at 8am PDT (https://zoom.us/j/990892712) | 15:55 |
| sjolley_ | YPTM: Stephen joined | 15:55 |
| litb | hmm, in zeus there appears to be no recipes-depends.dot file generated by "bitbake -g" | 15:56 |
| JPEW | YPTM: Joshua Watt here | 15:56 |
| litb | how can I generate that file which is needed by the oe-depends-dot tool? | 15:57 |
| litb | I wanna look why some recipe is being built | 15:57 |
| kergoth | roussinm: yes, or _yourdistro, since it's in your distro. of course, globally overriding an image name across all images is asking for pain unless you include the image basename | 15:57 |
| kergoth | litb: bitbake -g yourtarget | 15:57 |
| litb | kergoth, i did that. i did bitbake -g and specified some "-native" recipe | 15:57 |
| litb | but there is no recipes-depends.dot created | 15:57 |
| kergoth | use task-depends.dot | 15:58 |
| kergoth | recipe-depends.dot is no longer generated | 15:58 |
| litb | ah thanks. we tried that I think with oe-depends-dot. was that tool updated? | 15:58 |
| kergoth | you'll have to specify e.g. yourrecipe.do_populate_sysroot or yourrecipe.do_build or whatever instead of yourrecipe | 15:58 |
| kergoth | the tool doesn't need to change | 15:58 |
| kergoth | it works fine with either .dot file | 15:58 |
| litb | ah thanks! | 15:58 |
| kergoth | but the content includes the task names | 15:58 |
| kergoth | np | 15:58 |
| kergoth | it's a bit of a pain to use at this point, actually. do_build tends to get sucked in only by the image or whatever due to recrdeptask, which isn't super useful, and it doesn't fully recurse when using the other tasks, | 15:59 |
| kergoth | e.g. specifying yourrecipe.do_compile will just say yourrecipe.do_install brought it in, but won't continue past that | 15:59 |
| * kergoth was messing with it a couple days ago | 15:59 | |
| kergoth | still a lot better than nothing, but you'll have to fiddle with it | 16:00 |
| RP | YPTM: Richard has joined | 16:00 |
| smurray | YPTM: Scott Murray has joined | 16:00 |
| qschulz | GeneralStupid: what are the commands you're running and what exactly is the error? You might need to select your card first if you have multiple mmc devices on your device (use mmc command) | 16:01 |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 16:02 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 16:03 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 16:04 | |
| vmeson | YPTM: Randy MacLeod has joined. | 16:05 |
| moto-timo | YPTM: moto-timo has joined | 16:07 |
| roussinm | kergoth: Thank you! We don't have to patch poky anymore! | 16:08 |
| kergoth | np | 16:08 |
| tlwoerner | YPTM: tlwoerner in on | 16:10 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:16 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 16:16 | |
| litb | kergoth, hm, i see | 16:28 |
| litb | kergoth, i used do_populate_sysroot, which works because DEPENDS establishes that requirement | 16:28 |
| vmeson | FYI: mark's email (which I haven't read yet. ;-) ) http://lists.openembedded.org/pipermail/openembedded-architecture/2019-December/001709.html | 16:29 |
| litb | ah i see, you noted that aswell | 16:29 |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 16:31 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:35 | |
| vmeson | paulbarker: patchtest reviewer/owner: Li, Changqing <changqing.li@windriver.com> | 16:40 |
| vmeson | s/owner/maintainer/ I suppose. | 16:41 |
| paulbarker | vmeson: Thanks, I'll send an email today or tomorrow morning | 16:45 |
| vmeson | paulbarker: super. I look forward to eventually be able to locally check patches! | 16:46 |
| paulbarker | vmeson: That's exactly what I want. I got a weird email from patchtest and couldn't reproduce the issue locally without first fixing patchtest | 16:47 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 16:48 | |
| * moto-timo very interested in seeing this work :) | 16:48 | |
| dreyna | YP tech meeting minutes here: https://docs.google.com/document/d/1Y5IIuE-z0Ykdl-DwuzUJh52flOZuhN_TSAfw2tdU9pg | 16:48 |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC | 16:49 | |
| JPEW | RP: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/hash-equiv-fixup&id=c4aa1ff11035b67d18fdbcbdf8dc691a96fb3d7e | 16:50 |
| JPEW | kergoth: I've release a beta build for Pyrex: https://github.com/garmin/pyrex/releases/tag/v1.0.0-beta1 . Any feedback you have would be appreciated | 16:54 |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 16:56 | |
| RP | JPEW: hmm, yes. So I'm not reporting enough data | 16:56 |
| RP | JPEW: not quite sure your runququeue change if logic is quite correct but I can see the hashserve piece | 16:56 |
| JPEW | RP: Ya maybe not | 16:57 |
| RP | (newuni == origuni) needs to set remapped = True effectively | 16:57 |
| JPEW | Oh, ya, that would make more sense | 16:58 |
| RP | and I think we can actually drop that second if eventually and the rehashes var but one step at a time | 16:58 |
| kergoth | JPEW: sure, i'll play with it | 16:58 |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 16:58 | |
| JPEW | RP: I was more interested in not reporting the hash to the server if it didn't change :) | 16:58 |
| paulbarker | moto-timo: Did you say you have GitLab CI set up for meta-python2? Is that on a public repo? | 16:59 |
| JPEW | RP: Drop the "if not remapped" ? | 16:59 |
| RP | JPEW: right, that makes sense, its just the effect on the rest of the code | 16:59 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 16:59 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 16:59 | |
| RP | JPEW: no, we need that, we just need to tweak the newuni == origuni case | 17:00 |
| JPEW | ok | 17:00 |
| yocti | New news from stackoverflow: Edit which file /etc/resolv.conf is linked to at boot time <https://stackoverflow.com/questions/59161823/edit-which-file-etc-resolv-conf-is-linked-to-at-boot-time> | 17:00 |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 17:04 | |
| *** vineela <vineela!~vtummala@134.134.137.75> has joined #yocto | 17:07 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:24 | |
| *** zwelch <zwelch!~zwelch@fluffy.superlucidity.net> has quit IRC | 17:27 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 17:30 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 17:38 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 17:40 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 17:43 | |
| roussinm | kergoth: When using overrides, it is possible to use excludes? i.e IMAGE_NAME_mydistro[vardepsexclude] += "DATETIME" | 17:43 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:49 | |
| *** guerinoni <guerinoni!~guerinoni@95.238.42.152> has joined #yocto | 17:50 | |
| RP | JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/544 is one of the better runs we've ever had with hash equiv - only one mystery selftest failure so far that looks hash equiv related | 18:05 |
| RP | JPEW: I think I should try your patch :) | 18:05 |
| JPEW | RP: Ya, that's really good. | 18:06 |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 18:11 | |
| *** litb <litb!~jschaub@pd907fca9.dip0.t-ipconnect.de> has quit IRC | 18:13 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 18:17 | |
| *** nemgti-og <nemgti-og!nemgti-og@gateway/vpn/protonvpn/nemgti-og> has joined #yocto | 18:18 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:51a5:502e:8fc:9836> has quit IRC | 18:31 | |
| RP | JPEW: stacked another patch of mine on top of yours in -next :) | 18:38 |
| RP | JPEW: torn between stopping the current build (to restart the hashserv) and letting it finish | 18:38 |
| RP | guess I'll stop it and move on | 18:39 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 18:48 | |
| *** guerinoni <guerinoni!~guerinoni@95.238.42.152> has quit IRC | 18:57 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 19:02 | |
| fullstop | I'm coming from a buildroot background and I initially found yocto/bitbake to be very cumbersome and painful. After using it for a bit, I've come to appreciate what it does and how it can be leveraged to my advantage.. so I wanted to send my thanks to everyone who has worked on it. | 19:04 |
| fullstop | buildroot gets things done quickly and it's easy to work with.. but yocto does it "right" and slaps my hand when I fall out of line. | 19:05 |
| *** denix <denix!~denix@pool-100-15-86-127.washdc.fios.verizon.net> has quit IRC | 19:16 | |
| RP | fullstop: thanks. Out of interest is there anything you think we could/should improve? You've a useful experience of both systems there! :) | 19:27 |
| tgamblin | There was someone asking for a menuconfig-like interface for the tools, on one of LetoThe2nd's Twitch streams... seems like a fun project, but probably not a priority | 19:31 |
| RP | tgamblin: a lot of our config doesn't lend itself to menus either | 19:31 |
| fullstop | RP: My ultimate goal is a build system which can faithfully recreate a filesystem image, but most of my time has been spent writing recipes. Understanding the magic there was more difficult than the buildroot syntax. | 19:32 |
| fullstop | Finding that everything builds in tmp was unexpected. | 19:32 |
| moto-timo | paulbarker: I was waiting for git.oe.org to be up, but now my gitlab is public: https://gitlab.com/moto-timo/meta-python2 | 19:33 |
| moto-timo | paulbarker: it is running on a docker gitlab-runner on a machine at my house | 19:33 |
| RP | fullstop: that naming is bad and would probably be good to change but invasive on the docs :/ | 19:34 |
| moto-timo | paulbarker: we can also set it up on gitlab.com/openembedded... I was going to ask once it was public | 19:34 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 19:34 | |
| fullstop | Speaking of docs.. | 19:34 |
| fullstop | google LOVES to drop you in in 1.8 | 19:34 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-ygdifdfwnqedrywn> has quit IRC | 19:34 | |
| RP | fullstop: the recipe syntax sounds like a problem, anything specific or just in general? | 19:34 |
| moto-timo | google is getting somewhat better at picking latest, but yes 1.8 seems to be its favorite | 19:35 |
| RP | I wonder why google does that, I've noticed it too :/ | 19:35 |
| RP | perhaps time for more invasive redirects... | 19:35 |
| fullstop | Having a large banner at the top of 1.8 with a link to the latest might be helpful. | 19:35 |
| moto-timo | make scott can embedd google ads in the docs (someone kick me) | 19:35 |
| moto-timo | ^maybe | 19:36 |
| fullstop | Python does something where you can select the release at the top. | 19:36 |
| moto-timo | python builds with sphinx, we use docbook | 19:36 |
| RP | fullstop: it does have a link, https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html - its just broken :/ | 19:37 |
| RP | halstead: any thoughts on any of this? | 19:37 |
| fullstop | Finding stuff like pkg_postinst_ontarget_${PN} took some time. I knew what I wanted to do but had to track down the exact name of the target. | 19:37 |
| RP | fullstop: yes, a release selector would be ideal now you mention it | 19:37 |
| halstead | RP, We've tried some tricks to make Google put the newest docs at the top. They were mildly effective. | 19:38 |
| RP | halstead: the links to latest doc seem broken, not sure where we need to fix that? | 19:38 |
| halstead | moto-timo, Was git.oe.org down for you? | 19:39 |
| kergoth | roussinm: vardepsexclude applies to a variable, they won't move from the override version of the variable to the main one. so no. if you need to exclude it conditionally, you'd need to use inline python. in this case you can likely just apply it unconditionally, though. | 19:39 |
| moto-timo | halstead: no. I just meant I was waiting for it to be public and live | 19:39 |
| moto-timo | halstead: zero issues with git.oe.org so far :) | 19:39 |
| halstead | moto-timo, It up and live the way you want now correct? | 19:40 |
| moto-timo | halstead: it is working FANTASTIC | 19:40 |
| * moto-timo owes halstead a beverage | 19:40 | |
| moto-timo | armpit: check out the logo on https://gitlab.com/moto-timo/meta-python2 in your honor | 19:41 |
| halstead | RP, Latest and current URLs work. Trying to see why they aren't listed on the website. | 19:41 |
| RP | halstead: look at the link at the top of the 1.8 doc I linked to though | 19:41 |
| RP | halstead: sorry, I think I misread that | 19:42 |
| RP | fullstop: thanks, we do appreciate the feedback. It does help influence future development | 19:43 |
| moto-timo | fullstop: I also started with buildroot, but I had 5 products already in my queue and 10 on the horizon and knew it wouldn't scale (and drive me crazy) | 19:43 |
| halstead | RP, I see it linking back to the 1.8 manual. I can change that in the static files. | 19:44 |
| bluelightning | moto-timo: should I add meta-python2 to the layer index now? | 19:44 |
| moto-timo | me notices the absense of armpit | 19:44 |
| RP | halstead: right, pointing at current or latest would be much better | 19:44 |
| moto-timo | bluelightning: yes, an email was on my todo list :) | 19:44 |
| RP | halstead: we could change that in the docs themselves too, I'm not sure where its coming from as I've not looked | 19:44 |
| moto-timo | bluelightning: or I can test my login and see if I can add it? | 19:45 |
| bluelightning | moto-timo: sure, give it a try | 19:45 |
| fullstop | moto-timo: I dealt with one platform which has been living for about a decade. I have found the need to share recipes / layers across three platforms now, which is where yocto shines. | 19:46 |
| fullstop | RP: thanks! | 19:47 |
| kergoth | fullstop: we'd definitely appreciate any input on the issues. the project has its usability issues, it'd difficult to address many of them without sacrificing the flexibility that's core to the project, though | 19:47 |
| * kergoth ponders | 19:47 | |
| fullstop | Oh, one other thing that bugs me but will never be changed... ${sbindir} vs ${WORKDIR}. The casing. | 19:48 |
| nemgti-og | Hey there. I am new to Yocto and have two questions: 1. /leave | 19:49 |
| nemgti-og | Sorry for that last message :D | 19:50 |
| kergoth | ah, yes, that's inconsistent. the lowercase target path vars align with autoconf configure arguments, which is probably why it's that way.. | 19:51 |
| kergoth | there's a lot of history dragging along.. :) | 19:51 |
| tgamblin | RP: sent the patch for the oeqa skip tests issue, but forgot to put the bug link in the commit message. Let me know if you need a v2 | 19:52 |
| fullstop | I'm sure. :-) | 19:56 |
| RP | tgamblin: hmm, you're fixing it in the particular test rather than something more generic :/ | 19:59 |
| RP | tgamblin: what happens if some other bit of classSetup fails? | 19:59 |
| fullstop | I see that the link at the top of documentation now points to latest instead of 1.8. \o/ | 20:00 |
| RP | fullstop: we have halstead to thank for that I suspect :) | 20:00 |
| fullstop | thanks, halstead! | 20:00 |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 20:01 | |
| halstead | :) I've edited it in place since old docs don't get rebuilt. | 20:01 |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 20:02 | |
| halstead | Still lots of spots to track down. And I think the wording is off now. Since the link is to the latest overall not the latest for that release. | 20:02 |
| *** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has quit IRC | 20:04 | |
| tgamblin | RP: That should be the only case, no? There are only two classes that I see that inherit that particular version of setUpClass from OEScriptTests, and the second (OEListPackageconfigTests) doesn't seem affected. Unless I am misunderstanding all of the inheritance going on... | 20:06 |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 20:06 | |
| moto-timo | bluelightning: layer submitted... it autofilled the cgit info, so I hope that was correct? | 20:14 |
| fray | I publiushed it | 20:14 |
| moto-timo | :) | 20:14 |
| bluelightning | ah that's why I can't see it :D | 20:15 |
| bluelightning | good job people :) | 20:15 |
| moto-timo | lol | 20:15 |
| moto-timo | thank you fray and bluelightning :) | 20:15 |
| fray | I happened to have been logged into the layerindex when the email showed up.. :) | 20:15 |
| tgamblin | RP: I'll just poke around a bit more and see if I can get more generic with the fix | 20:16 |
| fray | bluelightning / rburton I found out there were a bunch of CVEs we missed in the triage.. they somehow got flagged as 'New-Reserved'.. so I'm moving them to New so we can triage them.. :( | 20:16 |
| bluelightning | fray: ok, how many? | 20:17 |
| fray | not sure.. guessing a few hundred.. :( | 20:17 |
| fray | I'm having to find and move them by hand.. started searching almost 21k new-reerved.. | 20:17 |
| fray | I'm down to "page 622 of 25 per page" | 20:18 |
| kergoth | JPEW: having issues passing args to pyrex-init-build-env, they seem to be passed to pyrex.py rather than the PYREX_OEINIT script, at least that's the error i'm getting. | 20:18 |
| bluelightning | fray: it says 406 now I load it | 20:18 |
| fray | I've not yet done the match to see how many pages.. | 20:18 |
| fray | wow.. that is more then I expected | 20:18 |
| kergoth | JPEW: seeing a pyrex.py usage error about the bitbake path being paseed to oe-init-build-env | 20:18 |
| bluelightning | fray: oh well, we'll get there | 20:18 |
| fray | numerically I'm up to CVE-2019-12521 ... | 20:18 |
| fray | (dreyna is going to get a 'negative' search implemented in the future so we can do something like "-RESERVED" and select everything WITHOUT reserved in the name) | 20:19 |
| bluelightning | that would be useful | 20:20 |
| *** hpsy <hpsy!~hpsy@85.203.15.88> has joined #yocto | 20:20 | |
| bluelightning | though I didn't come across too many of those in the triage I did, maybe most of them were already gone | 20:20 |
| fray | theoretically alof the 'New-Reserved' should start with "** RESERVED ** This candidate has been ...." | 20:20 |
| bluelightning | hmm actually the number is 444 | 20:22 |
| fray | I'm still adding ones.. :P | 20:22 |
| bluelightning | ah, I see | 20:22 |
| fray | up to CVE-2019-13641 now | 20:22 |
| fray | up to CVE-2019-15103 | 20:28 |
| yocti | New news from stackoverflow: How to install scipy on yocto warrior <https://stackoverflow.com/questions/59164784/how-to-install-scipy-on-yocto-warrior> | 20:31 |
| *** armpit <armpit!~armpit@45.19.219.178> has joined #yocto | 20:33 | |
| fray | up to CVE-2019-16157 ugh | 20:36 |
| Ad0 | I guess 4096 MB RAM isn't enough :P | 20:42 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 20:42 | |
| RP | tgamblin: https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/524/steps/8/logs/step2d shows there is another class with the same issue. My concern is there are other setUpClass methods so what if those fail? If these really are so problematic and can't be fixed, should we remove them entirely? | 20:46 |
| fray | ...and done.. yikes.. I moved 867 items that had gotten hidden.. :( | 20:48 |
| Ad0 | is there a way to clean the code for one specific package? | 20:53 |
| fray | bitbake -c clean .. cleansstate .. cleanall recipe | 20:54 |
| fray | choose one of the three cleans.. documented in the YP manual.. | 20:54 |
| Ad0 | I guess I have to find the recipe | 20:54 |
| nemgti-og | Hello. I am trying to build a layer from genivi (i.e. meta-ivi). It compains that it cannot find java on some directory under my build directory. Am I correct in my assumption, that I have to get a meta-java layer and simple added by means of the bitbake add-layer command? And does the order in which such layer are added matter? I mean, is it important to add them in a specific order? | 20:55 |
| tgamblin | RP: Right. Will do a little more digging | 20:55 |
| fray | it will be looking for the layers through dependencies (most likely) | 20:57 |
| fray | you need to make sure conf/bblayers.conf has all ofthe dependencies in it | 20:57 |
| Ad0 | fray, thanks! that did the job with bitbake-layers show-recipes .. bitbake -c clean ... | 20:58 |
| nemgti-og | hey fray thanks. Right, but the order in which those dependencies are listed in conf/bblayers.conf is irrelevant? | 20:58 |
| RP | bug 13667 could be 'fun' | 20:59 |
| yocti | Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13667 normal, Undecided, ---, richard.purdie, NEW , pid recycling problems in bitbake? | 20:59 |
| fray | order only matters when there is a conflict (two recipes providing the same thing) | 20:59 |
| fray | what is wrong w/ pid recycling? | 21:00 |
| RP | fray: I think its happening faster than the UI code can respond to events | 21:00 |
| fray | ohh old pids get stored in the task list? | 21:00 |
| fray | gotcha.. | 21:00 |
| RP | fray: its using pids to id tasks | 21:00 |
| RP | fray: we're cycling back to the same pids in around 5s | 21:01 |
| RP | well, myabe 22s | 21:01 |
| fray | which host system type? | 21:01 |
| fray | (and how many cores) | 21:01 |
| RP | fray: centos7 | 21:01 |
| nemgti-og | Thank you fray! | 21:01 |
| RP | 48 core | 21:02 |
| fray | Hmm.. similar (or smaller) to the systems I've been using and I've not seen that... wonder why it's repeating so quickly | 21:02 |
| kergoth | do we need to assign per-task uuids and use them in the events or something? | 21:02 |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 21:03 | |
| RP | heh, thought that bug would be impossible but with that log info, it makes sense and we could plan a fix | 21:04 |
| *** Azoff <Azoff!foobar@unaffiliated/azoff> has quit IRC | 21:04 | |
| RP | Sure we've seen it before but never understood why | 21:05 |
| fray | ya... per-task uuids is likely the only answer.. (not necessarily a 'full uuid, could just be a 64-bit number assigned by bitbake itself) | 21:05 |
| khem | RP:https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/144 | 21:06 |
| khem | some more unihash stuff | 21:07 |
| RP | khem: that one has been fixed | 21:07 |
| khem | ok cool. | 21:08 |
| khem | lets see | 21:08 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 21:08 | |
| *** jhar <jhar!~har@c-75-70-112-20.hsd1.co.comcast.net> has joined #yocto | 21:09 | |
| moto-timo | armpit: check out the logo on https://gitlab.com/moto-timo/meta-python2 in your honor | 21:14 |
| armpit | moto-timo, very nice | 21:15 |
| RP | khem: we've had a few iterations since then, its actually coming together a bit now | 21:24 |
| RP | fray: the reasons for using pids made sense at the time ;-) | 21:25 |
| RP | fray: that was a decade ago | 21:25 |
| fray | ya, pids are easy and you don't have to transmit them to both sides, since they already know them | 21:25 |
| RP | fray: well, we didn't have task ids back then, everything in runqueue was an index | 21:26 |
| fray | makes sense | 21:26 |
| RP | we've subsequently learnt that was stupid | 21:26 |
| fray | lol | 21:26 |
| RP | fray: now I know what python does behind the scenes, we work with it differently | 21:27 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 21:31 | |
| *** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-klczutozytbzuauq> has quit IRC | 21:35 | |
| *** armpit <armpit!~armpit@45.19.219.178> has quit IRC | 21:35 | |
| *** JaMa <JaMa!~martin@109.238.218.228> has quit IRC | 21:46 | |
| JPEW | kergoth: Hmm, OK | 21:48 |
| __angelo | hi, building a bsp just pulled, my_package requires libjpeg.so.62, but no providers found in RDEPENDS_my_package | 21:50 |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 21:51 | |
| JPEW | kergoth: What sort of arguments are you passing? I tried '. pyrex-init-build-env foo' and it seemed to drop me in the correct build directory | 21:56 |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto | 21:57 | |
| kergoth | JPEW: the first argument is fine | 22:03 |
| kergoth | . pyrex-init-build-env build.foo /path/to/bitbake -> /path/to/bitbake invalid argument | 22:03 |
| kergoth | oe-init-build-env accepts two args, and other inits might behave differently, it'd be ideal to pass it through as is | 22:04 |
| JPEW | kergoth: ah! ok | 22:04 |
| rburton | RP: hm i think my selftest hung. | 22:04 |
| rburton | or its actually taking 10+ hours | 22:04 |
| RP | rburton: it will be taking 10 hours | 22:05 |
| rburton | whhhhyyy | 22:05 |
| RP | rburton: wish I knew. Probably involves the NAS | 22:05 |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 22:07 | |
| RP | rburton: FWIW that worker is very laggy. Its the one we saw the pid roll on | 22:10 |
| rburton | hm | 22:10 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 22:10 | |
| RP | rburton: there is an ltp build running there the controller doesn't know about | 22:11 |
| rburton | nice | 22:13 |
| RP | rburton: I'll kill the bits I can tell shouldn't be there | 22:14 |
| RP | rburton: its runqemus that get left behind, something wrong with the cleanup | 22:15 |
| *** sven^ <sven^!~quassel@unaffiliated/sven/x-8293843> has quit IRC | 22:15 | |
| RP | rburton: I think its so lagged as its got a lot of file deletion going on in the background | 22:17 |
| JPEW | kergoth: Fixed | 22:20 |
| kergoth | JPEW: thanks, i'll give it another go | 22:20 |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 22:22 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 22:26 | |
| RP | rburton: the worker is lagged on deletion btw. Yes I know about rm_work | 22:42 |
| RP | rburton: specifically deletion of the parallel build dirs in selftest whilst running a build and having background deletion to do as well | 22:42 |
| RP | rburton: oe-selftest has actually finished but its not flushed its console | 22:43 |
| rburton | heh | 22:43 |
| fray | ok.. starting to get it | 22:56 |
| fray | oops | 22:56 |
| RP | fray: starting to get yocto? :) | 23:18 |
| fray | na.. baremetal configurations using YP builder | 23:18 |
| RP | its more fun to speculate ;-) | 23:19 |
| RP | JPEW: some failures in the current -next build with all our changes but not from hashequiv as yet | 23:20 |
| *** nemgti-og <nemgti-og!nemgti-og@gateway/vpn/protonvpn/nemgti-og> has quit IRC | 23:33 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 23:39 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 23:55 | |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 23:58 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!