| *** astlep5504018 <astlep5504018!~thelounge@107-136-136-210.lightspeed.nsvltn.sbcglobal.net> has quit IRC (Ping timeout: 252 seconds) | 00:09 | |
| *** mlaz <mlaz!~mlaz@dslb-088-075-092-043.088.075.pools.vodafone-ip.de> has joined #yocto | 00:13 | |
| *** mlaz <mlaz!~mlaz@dslb-088-075-092-043.088.075.pools.vodafone-ip.de> has quit IRC (Ping timeout: 260 seconds) | 00:22 | |
| khem | abelloni: I see you dropped "gdb pretty printer" patch for gcc-runtime any issues with it ? | 00:23 |
|---|---|---|
| *** astlep5504018 <astlep5504018!~thelounge@107-136-136-210.lightspeed.nsvltn.sbcglobal.net> has joined #yocto | 00:28 | |
| *** lexano <lexano!~lexano@174.119.69.134> has quit IRC (Ping timeout: 246 seconds) | 00:51 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 00:54 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 01:08 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 01:08 | |
| *** sakman <sakman!~Thunderbi@208.111.77.233> has quit IRC (Ping timeout: 268 seconds) | 01:12 | |
| *** davidinux <davidinux!~davidinux@45.11.80.93> has quit IRC (Ping timeout: 276 seconds) | 02:04 | |
| *** davidinux <davidinux!~davidinux@45.11.80.93> has joined #yocto | 02:04 | |
| *** xmn <xmn!~xmn@pool-108-46-142-76.nycmny.fios.verizon.net> has quit IRC (Ping timeout: 276 seconds) | 02:31 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 02:59 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 03:00 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:652f:6900:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 256 seconds) | 03:19 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:651e:7100:2ce:39ff:fecf:efcd> has joined #yocto | 03:21 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 03:26 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 03:27 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Ping timeout: 246 seconds) | 03:34 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 03:36 | |
| *** sakman <sakman!~Thunderbi@208.111.77.233> has joined #yocto | 03:48 | |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@ip-037-201-004-087.um10.pools.vodafone-ip.de> has quit IRC (Ping timeout: 264 seconds) | 04:05 | |
| *** amitk <amitk!~amit@58.84.62.55> has joined #yocto | 04:08 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 04:13 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 04:13 | |
| *** chep` <chep`!chep@gateway/vpn/airvpn/chep> has joined #yocto | 04:41 | |
| *** chep <chep!chep@gateway/vpn/airvpn/chep> has quit IRC (Ping timeout: 256 seconds) | 04:42 | |
| *** chep` is now known as chep | 04:42 | |
| *** alimon <alimon!~alimon@189.162.155.39> has joined #yocto | 04:54 | |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@ip-037-201-004-087.um10.pools.vodafone-ip.de> has joined #yocto | 05:02 | |
| *** khazakar <khazakar!uid144674@id-144674.ilkley.irccloud.com> has joined #yocto | 05:47 | |
| *** sakman <sakman!~Thunderbi@208.111.77.233> has quit IRC (Ping timeout: 260 seconds) | 06:01 | |
| *** linfax <linfax!~linfax@eumail.topcon.com> has joined #yocto | 07:46 | |
| *** rfuentess <rfuentess!~rfuentess@2a01:cb14:11e8:f400:3206:fad:80b:75b9> has joined #yocto | 07:47 | |
| *** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has joined #yocto | 07:57 | |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Quit: vladest) | 08:01 | |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto | 08:03 | |
| *** mckoan|away is now known as mckoan | 08:09 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:10 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:e805:bb00:ed7e:3e24:bbfe:e3fa> has joined #yocto | 08:43 | |
| RP | khem: to be clear, we still need that patch, we can't drop it | 08:44 |
| RP | I can't see any change in glibc master which avoids ldconfig which is the issue it avoids | 08:45 |
| *** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto | 09:01 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:40 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has joined #yocto | 09:44 | |
| *** brabander <brabander!~frank@186-153-172-081.dynamic.caiway.nl> has quit IRC (Ping timeout: 260 seconds) | 10:11 | |
| *** xmn <xmn!~xmn@108.46.142.76> has joined #yocto | 10:13 | |
| *** RobertBerger <RobertBerger!~rber|res@2001:871:20c:302b:99f:6a44:9acf:42fe> has joined #yocto | 10:22 | |
| *** rber|res <rber|res!~rber|res@089144197092.atnat0006.highway.a1.net> has quit IRC (Ping timeout: 255 seconds) | 10:25 | |
| *** RobertBerger <RobertBerger!~rber|res@2001:871:20c:302b:99f:6a44:9acf:42fe> has quit IRC (Quit: Leaving) | 10:31 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 268 seconds) | 10:33 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 10:34 | |
| *** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 11:00 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 11:11 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128046.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 11:17 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128046.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 276 seconds) | 11:38 | |
| *** Guest60 <Guest60!~Guest90@176.33.65.159> has joined #yocto | 11:40 | |
| Guest60 | hi everyone, let's say I want to work on a bug that is in bug triage, is build server support provided for this? | 11:41 |
| RP | Guest60: unfortunately no, the autobuilder is a limited resource | 11:48 |
| *** Guest60 <Guest60!~Guest90@176.33.65.159> has quit IRC (Quit: Client closed) | 11:50 | |
| *** reatmon <reatmon!sid538117@id-538117.helmsley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 12:03 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto | 12:17 | |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto | 12:34 | |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 12:45 | |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto | 12:45 | |
| *** lexano <lexano!~lexano@174.119.69.134> has joined #yocto | 13:02 | |
| jmd | When I do "source oe-init-build-env" I get an error: "Please set up python v2 as your default python interpreter" But it doesn't explain how to do that. | 13:24 |
| Xogium | huh, python 2 ? | 13:26 |
| jmd | That's what it says. | 13:26 |
| Xogium | which yocto version is that ? | 13:28 |
| jmd | I'm building from git | 13:28 |
| Xogium | I'm a bit baffled here because the oe-init-build-env thing is just a shell script. I don't get why it would need python 2, not to mention that python 2 is dead | 13:28 |
| jmd | Yeah. I was surprised too. | 13:29 |
| Xogium | which distro do you run this on ? | 13:29 |
| jmd | Debian | 13:30 |
| jmd | 12.4 | 13:30 |
| Xogium | fwiw I'm on ubuntu here and even with python being symlinked to python3 and not python2, the oe build env thing runs | 13:30 |
| Xogium | I'm on kirkstone, but still | 13:30 |
| Xogium | I was under the impression that all this oe script does is setting up shell env variables | 13:31 |
| jmd | The complete message is "Bitbake is not compatible with python v3\nPlease set up python v2 as your default python interpreter" | 13:31 |
| Xogium | so I really don't understand the deal with python 2 vs python 3 | 13:31 |
| Xogium | it must be something else printing this, because there is not one single error message refering to the python version in oe-build-env in itself | 13:32 |
| Xogium | ah | 13:32 |
| Xogium | what in the hell ? | 13:32 |
| Xogium | that also doesn't seem to make sense | 13:33 |
| RP | jmd: that is the latest release from master? I'd have thought we got rid of that message a long time ago | 13:33 |
| jmd | Xogium: I think you're mistaken. It's in line 34 of oe-buildenv-internal | 13:33 |
| Xogium | oh ! | 13:33 |
| Xogium | I missed this. I was checking only the oe-init-build-env ;p | 13:34 |
| RP | jmd: for me, line 37 is echo >&2 "BitBake requires Python 3.8.0 or later as 'python3' (scripts/install-buildtools can be used if needed)" | 13:34 |
| jmd | And I'm on the "jethro" branch. Not "master" (as per the getting started in structions on https://docs.yoctoproject.org | 13:34 |
| Xogium | ooh boy | 13:35 |
| RP | jmd: Not quite sure how you got to jethro but that is a very old release :( | 13:35 |
| JaMa | jmd: see https://wiki.yoctoproject.org/wiki/Releases | 13:35 |
| Xogium | like, *very* old | 13:35 |
| JaMa | jethro support ended in 2016 | 13:35 |
| jmd | https://docs.yoctoproject.org/2.0/yocto-project-qs/yocto-project-qs.html quite clearly says "git checkout jethro" | 13:36 |
| Xogium | which kind of explains why you're stuck with something that wants python 2, I guess | 13:36 |
| jmd | In at least 2 places. | 13:36 |
| RP | jmd: the 2.0 there is the issue, those are not recent docs | 13:36 |
| jmd | They are linked to from the main page. | 13:36 |
| RP | jmd: it does say at the top "This version of the project is now considered obsolete, please select and use a more recent version." | 13:36 |
| RP | jmd: where on the main page? | 13:37 |
| jmd | Okay I stand corrected it's not the main page. | 13:38 |
| Xogium | main page iirc always points to latest | 13:39 |
| jmd | It's the "Yocto Project Quick Start" page. | 13:39 |
| jmd | and the link says: "For the latest version of this manual associated with this Yocto Project release, see the Yocto Project Quick Start from the Yocto Project website. " | 13:40 |
| jmd | So that's how I found it. | 13:40 |
| jmd | Anyway, which instructions should I be following? | 13:40 |
| JaMa | do you have a link to this page? it's true that google for this returns https://docs.yoctoproject.org/2.4.2/yocto-project-qs/yocto-project-qs.html as first hit which is the old version | 13:41 |
| RP | jmd: I suspect you've followed an outdated link through google :( | 13:42 |
| RP | jmd: if there is anything we can fix from our side we will which is why we're asking questions to try and find out how you got here | 13:42 |
| RP | jmd: https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html is the most recent | 13:42 |
| jmd | Yeah I think I googled for "Yocto getting started" | 13:43 |
| JaMa | yes, that gives me https://docs.yoctoproject.org/2.0/yocto-project-qs/yocto-project-qs.html as first result (with the notice inside that you should switch to more recent one) | 13:45 |
| *** Omax <Omax!~m-6qlehn@185-107-13-229.static.kviknet.net> has quit IRC (Ping timeout: 260 seconds) | 13:51 | |
| *** Omax <Omax!~m-6qlehn@185-107-13-229.static.kviknet.net> has joined #yocto | 13:54 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 14:17 | |
| jmd | How do I change the Build Configuration ? | 14:23 |
| *** sakman <sakman!~Thunderbi@208.111.77.233> has joined #yocto | 14:24 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 250 seconds) | 14:28 | |
| *** arielmrmx <arielmrmx!~quassel@189.161.180.237> has quit IRC (Remote host closed the connection) | 14:40 | |
| *** arielmrmx <arielmrmx!~quassel@189.161.180.237> has joined #yocto | 14:41 | |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 14:45 | |
| derRichard | to build my kernel i need to set CROSS_COMPILE_COMPAT too, what is the variable for the 32bit target prefix when building a 64 program? | 14:46 |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has quit IRC (Remote host closed the connection) | 14:49 | |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto | 14:51 | |
| *** sakman <sakman!~Thunderbi@208.111.77.233> has quit IRC (Ping timeout: 256 seconds) | 14:56 | |
| *** sakman <sakman!~Thunderbi@142.169.16.76> has joined #yocto | 14:57 | |
| frosteyes | abelloni: noticed you included one of the kernel-devsrc patches (the one for gawk) in your contrib master-next, but not the other patch for make - https://lists.openembedded.org/g/openembedded-core/message/194590 | 14:58 |
| jmd | How do I start a bitbake server ? | 15:03 |
| *** linfax <linfax!~linfax@eumail.topcon.com> has quit IRC (Ping timeout: 255 seconds) | 15:07 | |
| frosteyes | jmd: I will recommend you start by reading and following the https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html | 15:07 |
| jmd | frosteyes: I will have a look. Thanks. | 15:11 |
| jmd | Oh. It's the page I've been following the whole day - just a different URL. | 15:12 |
| frosteyes | The latest version.. | 15:14 |
| frosteyes | Fitting for your system :) | 15:14 |
| frosteyes | And next - https://docs.yoctoproject.org/ | 15:15 |
| frosteyes | Expect a steep learning curve as a start, but it will pay off | 15:16 |
| jmd | Anyway, so far as I can see none of those mention how to start a bitbake server | 15:17 |
| frosteyes | The bitbake server is started as part of the bitbake command.. | 15:17 |
| jmd | And what if it doesn't? | 15:17 |
| jmd | Only certain commands seem to do it. | 15:18 |
| frosteyes | What are you trying to do? | 15:19 |
| jmd | run bitbake | 15:19 |
| frosteyes | okay.. First have you checked out nanbield | 15:20 |
| jmd | yes. | 15:20 |
| frosteyes | and checked with git status that nothing is changed in your working dir | 15:21 |
| frosteyes | Next - remove the build folder inside the poky folder | 15:21 |
| jmd | Well many things have changed. As per https://docs.yoctoproject.org/ they should | 15:21 |
| jmd | ok "build" removed | 15:22 |
| frosteyes | then start by source oe-init-build-env | 15:22 |
| Saur | sakoman, khem: Is it expected that glibc is three commits ahead on the nanbield branch compared to master? | 15:23 |
| frosteyes | a new build folder is created - and you should be able to run bitbake | 15:23 |
| jmd | frosteyes: Is it safe to do that when I've already done it? I seem to remember it causes issued. | 15:23 |
| jmd | s/issued/issues | 15:23 |
| frosteyes | we started on a fresh, when you removed the build folder and then created with source oe-init-build-env | 15:24 |
| frosteyes | So yes. | 15:24 |
| jmd | okay. | 15:24 |
| jmd | Then bitbake again? | 15:24 |
| frosteyes | Just try.. | 15:25 |
| jmd | Yep okay so the trick is when bitbake breaks, remove build and try again. | 15:25 |
| frosteyes | Not exactly.. But you had a very old build setup because you had been working on 2.0 | 15:26 |
| sakoman | Saur: I haven't merged that, just testing it in the -nut branch to see if there were any issues. It won't merge until master has the same | 15:26 |
| jmd | Maybe. I thought I started clean over though. | 15:27 |
| frosteyes | Also.. When switching from a very old release, you sometimes need to create a new terminal, when sourcing the new one.. | 15:27 |
| jmd | Maybe that was the problem then. | 15:28 |
| frosteyes | E.g. source oe-init-build-env export some variables.. | 15:28 |
| frosteyes | And they have changed over time.. | 15:28 |
| sakoman | Saur: thanks for watching though! I always appreciate feedback -- might keep me from doing something stupid :-) | 15:28 |
| frosteyes | So if you first source an old one,, They are exported.. and if they are not export in newer versions, it become a mix.. | 15:29 |
| jmd | Sometimes bitbake just blocks forever | 15:31 |
| Saur | sakoman: AFAICT, origin/master has SRCREV_glibc ?= "1e04dcec491bd8f48b5b74ce3e8414132578a645" and origin/nanbield has SRCREV_glibc ?= "44f757a6364a546359809d48c76b3debd26e77d4", where the latter SRCREV is three commits ahead of the former... | 15:31 |
| jmd | Oh and now it can't find the server again. | 15:32 |
| frosteyes | have you run "ctrl+c" or similar.. | 15:33 |
| khem | Saur: usually it should not but in context we are in process to upgrade to 2.39 on master so its not bad | 15:34 |
| frosteyes | Will be off, good luck - jmd | 15:34 |
| Saur | khem: Yeah, I expected something like that. I was just a bit surprised when I noticed. | 15:35 |
| sakoman | Saur: Sigh, you are correct, I thought you were referring to the glibc patch I have queued in -nut | 15:35 |
| khem | usually devs should send patch against master and a backport | 15:35 |
| khem | separately | 15:36 |
| Saur | sakoman: No worries. And as khem says, soon it will solve itself when master upgrades to 2.39. | 15:36 |
| khem | RP: yes I guess, I will adapt it on top | 15:36 |
| RP | khem: the glibc mips patch seemed to work FWIW | 15:37 |
| jmd | frosteyes: Yes I've been doing that rather a lot. | 15:38 |
| frosteyes | jmd: then this is your problem.. Some bitbake commands take siginificant time.. When you press ctrl+c the bitbake server might not get shutdown correct. This means it can not be started for the next command. So you need to control your process - think ps and look if something hanging.. Also it might be the bitbake.lock file and bitbake.sock is still present.. Preventing the next bitbake command. | 15:41 |
| *** jmd` <jmd`!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto | 15:44 | |
| *** jmd`` <jmd``!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto | 16:00 | |
| jmd` | Is there a way to make bitbake run deterministicly ? | 16:12 |
| rburton | in bitbake's defense, it's not non-deterministic | 16:12 |
| * rburton should stop looking at irc and finish his slides | 16:12 | |
| jmd` | Well every time I run it, it does something different. | 16:13 |
| rburton | its working towards the target you specify. there's usually a huge amount of routes to that target, so it can do lots in parallel. | 16:14 |
| rburton | if you say what your problem is, maybe someone can help with that | 16:14 |
| *** rfuentess <rfuentess!~rfuentess@2a01:cb14:11e8:f400:3206:fad:80b:75b9> has quit IRC (Remote host closed the connection) | 16:15 | |
| jmd` | rburton: My (current) problem is that every time I run bitbake (with the same parameters) and without me changing anything int the filesystem, it gives different errors. | 16:22 |
| *** jmd`` <jmd``!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has quit IRC (Remote host closed the connection) | 16:22 | |
| rburton | jmd`: its entirely possible that you just have lots of errors (maybe one root issue) and as bitbake stops when it first encounters an error and it will run tens of jobs at once, what one in particular fails first is random | 16:24 |
| rburton | but you've said nothing beyond "i run bitbake and it fails" so 🤷♂️ | 16:24 |
| rburton | pick one failing recipe, bitbake just that, fix it. | 16:25 |
| jmd` | rburton: Right. So how can I make it run one job at a time? | 16:25 |
| rburton | no need to do that. just bitbake the first one that fails | 16:26 |
| jmd` | Also I never said "i run bitbake and it fails". You are putting words into my mouth. | 16:26 |
| rburton | i paraphrased "I run bitbake and it gives different errors." | 16:26 |
| jmd` | rburton: But the "first" one is different each run. So concentrating on the one error is difficult. | 16:27 |
| rburton | but if you bitbake the first one that fails then only that one will fail | 16:27 |
| rburton | because by definition its dependencies have succeeded | 16:27 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 16:28 | |
| jmd` | That would seem not to be true. I am providing one target and I am getting 2 errors (and many warnings) from from different depdendencies. | 16:30 |
| rburton | so work up the dependency tree, pick an earlier recipe that is failing | 16:30 |
| rburton | if you bitbake foo and the recipe bar fails with errors, then bitbake bar | 16:31 |
| jmd` | okay. Now we're getting somewhere. So how do I find out the dependencies of foo? | 16:32 |
| rburton | just pick one of the recipes that actually errors, and bitbake that | 16:34 |
| jmd` | Yes. And how do I know which recipe is giving rise to an error? | 16:36 |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has quit IRC (Remote host closed the connection) | 16:36 | |
| neverpanic | jmd`: you can use bitbake -k to make it continue until it encountered all errors. | 16:36 |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Quit: WeeChat 4.2.1) | 16:37 | |
| neverpanic | That'll make it more deterministic, but you'll potentially see many many errors before it stops. | 16:37 |
| rburton | jmd`: the log tells you. "recipe foo fails in do_bar" | 16:37 |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto | 16:37 | |
| jmd` | neverpanic: Yes, and it'll still come in a different order each time. | 16:38 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:38 | |
| rburton | yes, because the order isn't relevant. if foo depends on A and B then it doesn't matter if bitbake builds A or B first, or if it builds them both at the exact same time. | 16:38 |
| neverpanic | Yes. That's just the nature of doing things in parallel. It would take a very long time if it didn't. | 16:38 |
| neverpanic | You could change it to use fewer (or even just 1) job, but the order could still be different, because topological sorting doesn't have a single unique solution. | 16:39 |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 16:39 | |
| jmd` | rburton: I understand that. However most dependency tools, for this very reason, have an option to disable parallel builds in order to make debugging simpler. | 16:39 |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has quit IRC (Remote host closed the connection) | 16:39 | |
| rburton | set BB_NUMBER_THREADS=1 then, it won't help for the reason said above. | 16:40 |
| rburton | the answer is to build the specific recipe that failed and pick the errors off one at a time, instead of trying to do them all at once. | 16:40 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 252 seconds) | 16:41 | |
| rburton | _maybe_ bitbake uses sorted sets to construct the task graph but I wouldn't rely on that. I _think_ python dicts are sorted by insertion order if you have a modern python so that would mean a bit more reliability. but this is the wrong solution to the problem. | 16:43 |
| jmd` | I'm not trying to do them all at once. | 16:43 |
| jmd` | I'm trying to do them one at a time. | 16:43 |
| jmd` | But that is very difficult because I can't cause the same recipe to run after I've applied a potential fix. | 16:44 |
| neverpanic | You can, just run bitbake $recipename | 16:44 |
| rburton | why can't you just bitbake that recipe? | 16:44 |
| jmd` | So I *think* it's fixed, only to discover 15 minutes later that my fix had not fixed the problem. | 16:45 |
| jmd` | rburton: Because I don't know which recipe is causing the problem. | 16:45 |
| rburton | but you said you just fixed a recipe | 16:45 |
| rburton | and every task failure says what recipe it was running in | 16:46 |
| jmd` | I don't see that. I just see a message like "ERROR: ParseError at Yocto/poky/meta-dmo/recipes-kernel/linux/linux-dmo.inc:46: Could not inherit file classes/fsl-vivante-kernel-driver-handler.bbclass" | 16:47 |
| rburton | parse errors happen before it even ran _any_ tasks | 16:47 |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto | 16:48 | |
| rburton | if you've a 15 minute cycle for a bitbake parse it sounds like you're testing-via-CI, so i suggest replicating the build infra locally so you can iterate in seconds | 16:50 |
| jmd` | I've no idea what that means, but I will try to googleing those terms. | 16:51 |
| Saur | jmd`: That class comes from meta-freescale. Do you have meta-freescale in BBLAYERS in your bblayers.conf file? | 16:51 |
| jmd` | On a completely different note, are the mass of warnings like "SRC_URI:append += is not a recommended operator combination, please replace it." something I'm doing wrong or are they just a fact of life/ | 16:52 |
| Saur | Or meta-fsl-arm apparently. | 16:52 |
| jmd` | Saur: no | 16:52 |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has quit IRC (Remote host closed the connection) | 16:53 | |
| Saur | Well, you need either of those layers to provide that class, or drop the recipe that inherits it, or the layer with the recipe that inherits it. | 16:54 |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 16:54 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 16:54 | |
| khem | RP: yes, I have the final patches for glibc 2.39 on ml yesterday, the mips patch is accepted upstream it will be applied soon | 16:54 |
| jmd` | Saur: What if I just drop the "inherits" line? | 16:55 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has quit IRC (Quit: alessioigor) | 16:55 | |
| rburton | jmd`: whoever wrote the recipes should fix that. :append += is a bad idiom and should be removed. | 16:55 |
| Saur | jmd`: The doubt the recipe would inherit the class without actually needing it... | 16:55 |
| Saur | I doubt* | 16:56 |
| jmd` | So should I file a bug? There are *many* of them. | 16:56 |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Remote host closed the connection) | 16:56 | |
| rburton | jmd`: potentially you've mixed incompatible versions of things, but file a bug with whoever provided those recipes yes. | 16:58 |
| Saur | Are you trying to use an old layer with a new OE Core? Those warnings are fairly new. | 16:58 |
| rburton | that's what i'm thinking, but the compat stuff stops really old mixing. | 16:58 |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #yocto | 17:00 | |
| jmd` | Saur: Yes, that's what I'm doing. | 17:02 |
| Saur | Well, then it is not a surprise that you get those warnings. Correcting the syntax for those appends is part of updating the layer to match current the OE OCre. | 17:03 |
| jmd` | Isn't systemd part of the OE core? | 17:04 |
| Saur | It is, if you have `systemd` enabled in DISTRO_FEATURES. | 17:05 |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto | 17:06 | |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has quit IRC (Remote host closed the connection) | 17:06 | |
| rburton | if you mixing layer versions then typically you get to keep the pieces when it breaks. they're versioned for a reason. | 17:06 |
| Saur | jmd`: Nowadays you typically set INIT_MANAGER = "systemd" in your distro and it will take care of the rest (see meta/conf/distro/include/init-manager-systemd.inc for what it actually does). | 17:07 |
| *** sakman <sakman!~Thunderbi@142.169.16.76> has quit IRC (Read error: Connection reset by peer) | 17:09 | |
| jmd` | rburton: and now I'm trying to glue the pieces back together. | 17:09 |
| rburton | those warnings are ignorable, it's a style thing mainly | 17:10 |
| jmd` | When I get "ERROR: ... inherits ... but doesn't set XXXXXX for package foo" how do I go about setting it? What's the syntax? | 17:11 |
| rburton | what's the actual error? | 17:11 |
| jmd` | mo-base-user_1.0.bb inherits useradd but doesn't set USERADD_PARAM, GROUPADD_PARAM or GROUPMEMS_PARAM for package dmo-base-user | 17:13 |
| rburton | if it doesn't set those variables then the class inherit is pointless, so remove it | 17:13 |
| rburton | that's "I was inherited but have nothing to do" | 17:14 |
| jmd` | Well I looks as if it does: USERADD_PARAM_${PN} = "--home ...... | 17:14 |
| jmd` | That's what is confusing me | 17:14 |
| Saur | jmd`: Old syntax, neds to be corrected. | 17:14 |
| Saur | Should be USERADD_PARAM:${PN} now. | 17:15 |
| rburton | is dmo-base-user something you wrote, or something you were given? | 17:15 |
| jmd` | Ahh | 17:15 |
| Saur | There is a script to fix that... | 17:15 |
| rburton | because i'd have expected most vendors to have fixed this long ago | 17:15 |
| jmd` | Does that also apply to RDEPENDS_${PN} too? | 17:16 |
| rburton | yes | 17:16 |
| rburton | if its your code then read the migration guide for the releases you're upgrading via to understand very important things like the syntax changes and variable renames | 17:16 |
| jmd` | No. For the record, it's not my code. | 17:16 |
| rburton | then i'd ask vendor for updated code as its clearly obsolete and there should be an updated release | 17:17 |
| jmd` | I will ask, but I won't hold my breath. | 17:17 |
| Saur | jmd`: Migrating an old layer is no small task. If it is not your layer, you most likely do not want to do it yourself... | 17:17 |
| Saur | For the record, there are a number of scripts/contrib/convert-* scripts that will help converting old layers to new standards. However, as rburton says, you really must read and understand the migration guides for all the versions you are going through when updating... | 17:19 |
| jmd` | Saur: You're absolutely right. Would you like to do it for me :) | 17:20 |
| jmd` | I will look up the migration guides. | 17:20 |
| Saur | Sorry, I already have my plate full managing our own layers. | 17:21 |
| jmd` | Yes I thought that might be the answer. | 17:24 |
| jmd` | Hah! Yesterday I got a message telling me to change all instances of 'git://' to 'https://' Today I get a message telling me to change them back again! | 17:26 |
| rburton | you misread the message | 17:28 |
| rburton | if you're fetching a git repo then the protocol in the url is always git:// | 17:28 |
| rburton | but you then have to specify what actual protocol to use in a protocol= argument | 17:28 |
| rburton | so git://github.com/foo/bar;protocol=https is a git clone of https://github.com/foo/bar | 17:29 |
| rburton | where as SRC_URI=https://github.com/foo/bar/ would get that url with wget, and not git | 17:29 |
| jmd` | Right. Thanks for the explanation. | 17:31 |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@ip-037-201-004-087.um10.pools.vodafone-ip.de> has quit IRC (Ping timeout: 264 seconds) | 17:32 | |
| rburton | the change was, iirc, that protocol is now mandatory | 17:32 |
| *** mckoan is now known as mckoan|away | 17:34 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Read error: Connection reset by peer) | 17:48 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 17:49 | |
| mischief | for some reason after i sent a patch mail yesterday with git-send-email thru gmail, i've stopped receiving incoming messages from openembedded-core@ :-( | 18:00 |
| jmd` | I don't understand this message "ERROR: No recipes in default available for: <big-long-list>" | 18:00 |
| jmd` | 18:00 | |
| Saur | jmd`: That means you have bbappend files with no matching bb files. | 18:11 |
| *** sakman <sakman!~Thunderbi@142.169.16.98> has joined #yocto | 18:11 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 18:13 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Quit: If you can't laugh at yourself, make fun of other people.) | 18:14 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-191-116.78.49.pool.telefonica.de> has joined #yocto | 18:15 | |
| *** DarkestFM <DarkestFM!~DarkestFM@173.161.35.14> has joined #yocto | 18:27 | |
| jmd` | Hmm. | 18:28 |
| DarkestFM | Hi im trying to patch the redis.conf in meta-openembedded/meta-oe/recipes-extended/redis/redis but there is also a redis.conf in the source, how do i get bitbake to recognize which file needs patched? | 18:29 |
| DarkestFM | when i use devtool it pulls the file from meta-oe into oe-local-files, modifying it and finishing devtool causes it to produce a full file instead of a patch | 18:33 |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Remote host closed the connection) | 18:37 | |
| *** sakman1 <sakman1!~Thunderbi@208.111.77.233> has joined #yocto | 18:40 | |
| *** sakman <sakman!~Thunderbi@142.169.16.98> has quit IRC (Ping timeout: 276 seconds) | 18:41 | |
| *** sakman <sakman!~Thunderbi@208.111.77.233> has joined #yocto | 18:43 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 18:44 | |
| *** sakman1 <sakman1!~Thunderbi@208.111.77.233> has quit IRC (Ping timeout: 252 seconds) | 18:44 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 18:44 | |
| Saur | DarkestFM: That's because you cannot patch a file provided by one layer in another layer, you replace it whole. | 18:45 |
| DarkestFM | Cool. Is that documented somewhere? | 18:50 |
| Saur | I don't know. I think it is mostly a consequence of do_patch working in ${S}, while the files included from the layer end up in ${WORKDIR}. | 18:52 |
| DarkestFM | Makes sense. | 18:53 |
| DarkestFM | Thanks for the clarification. | 18:57 |
| *** sakman <sakman!~Thunderbi@208.111.77.233> has quit IRC (Ping timeout: 268 seconds) | 19:01 | |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Remote host closed the connection) | 19:24 | |
| *** sakman <sakman!~Thunderbi@99.209.85.164> has joined #yocto | 19:37 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 19:46 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 19:46 | |
| jmd` | So if FILES:${PN}:append += "${sysconfdir}/X11/Xsession.d/" is bad, what should it be? | 20:01 |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto | 20:03 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128046.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 20:08 | |
| Saur | jmd`: FILES:${PN}:append = " ${sysconfdir}/X11/Xsession.d/" | 20:09 |
| Saur | Or in most cases for FILES:${PN}: FILES:${PN} += "${sysconfdir}/X11/Xsession.d/" | 20:10 |
| Saur | Note the space after the first quote in the first example. | 20:10 |
| jmd` | Right. So just remove :append | 20:11 |
| JaMa | Wrong. | 20:14 |
| JaMa | it will work in this case, but there might be other cases where the :append might be needed | 20:15 |
| jmd` | JaMa: but s/:append *+=/+=/g will be okay ?? | 20:15 |
| JaMa | not necessary | 20:18 |
| jmd` | do elaborate... | 20:20 |
| JaMa | read the docs about various operator and their differences, there are even some presentations about this topic as it's not simple and many newcomers are confused from different behavior of :append and += and =+ or .=/=. and it's better to learn early | 20:24 |
| *** prabhakar <prabhakar!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 240 seconds) | 20:30 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-191-116.78.49.pool.telefonica.de> has quit IRC (Ping timeout: 276 seconds) | 20:33 | |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@ip-037-201-004-087.um10.pools.vodafone-ip.de> has joined #yocto | 20:43 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 20:57 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 20:58 | |
| *** jpuhlman <jpuhlman!~jpuhlman@50.240.203.141> has quit IRC (Ping timeout: 256 seconds) | 21:06 | |
| *** jpuhlman <jpuhlman!~jpuhlman@50.240.203.141> has joined #yocto | 21:06 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128046.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 256 seconds) | 21:08 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 21:13 | |
| *** jmd` <jmd`!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has quit IRC (Remote host closed the connection) | 21:13 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-191-116.78.49.pool.telefonica.de> has joined #yocto | 21:38 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has quit IRC (Read error: Connection reset by peer) | 21:44 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has joined #yocto | 21:45 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has quit IRC (Read error: Connection reset by peer) | 21:50 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has joined #yocto | 21:52 | |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto | 21:54 | |
| *** jmd` <jmd`!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto | 22:00 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 22:01 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 22:20 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 22:21 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 22:35 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Remote host closed the connection) | 22:36 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 22:36 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 22:41 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 22:41 | |
| *** xmn <xmn!~xmn@108.46.142.76> has quit IRC (Ping timeout: 268 seconds) | 22:46 | |
| *** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has quit IRC (Remote host closed the connection) | 23:03 | |
| *** jmd` <jmd`!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has quit IRC (Remote host closed the connection) | 23:03 | |
| *** ajfriesen <ajfriesen!~ajfriesen@p5b27aaf5.dip0.t-ipconnect.de> has quit IRC (Read error: Connection reset by peer) | 23:05 | |
| *** ajfriesen <ajfriesen!~ajfriesen@p5b27aaf5.dip0.t-ipconnect.de> has joined #yocto | 23:06 | |
| *** ajfriesen <ajfriesen!~ajfriesen@p5b27aaf5.dip0.t-ipconnect.de> has quit IRC (Client Quit) | 23:08 | |
| *** sakman1 <sakman1!~Thunderbi@99.209.85.163> has joined #yocto | 23:13 | |
| *** ajfriesen <ajfriesen!~ajfriesen@p5b27aaf5.dip0.t-ipconnect.de> has joined #yocto | 23:13 | |
| *** sakman <sakman!~Thunderbi@99.209.85.164> has quit IRC (Ping timeout: 264 seconds) | 23:16 | |
| *** sakman1 is now known as sakman | 23:16 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 276 seconds) | 23:25 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has joined #yocto | 23:37 | |
| *** khazakar <khazakar!uid144674@id-144674.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 23:46 | |
| *** sakman <sakman!~Thunderbi@99.209.85.163> has quit IRC (Ping timeout: 260 seconds) | 23:49 | |
| *** jpuhlman <jpuhlman!~jpuhlman@50.240.203.141> has quit IRC (Read error: Connection reset by peer) | 23:50 | |
| *** jpuhlman- <jpuhlman-!~jpuhlman@50.240.203.141> has joined #yocto | 23:50 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-049-191-116.78.49.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 23:55 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!