| 00:27.25 | *** join/#oe tgamblin (~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com) |
| 00:36.51 | *** join/#oe JPEW (~JPEW@ec2-18-219-251-161.us-east-2.compute.amazonaws.com) |
| 00:40.58 | *** join/#oe JPEW (~JPEW@ec2-18-219-251-161.us-east-2.compute.amazonaws.com) |
| 01:12.44 | *** join/#oe JaMa (~martin@109.238.218.228) |
| 05:07.45 | *** join/#oe armpit (~armpit@2601:202:4180:a5c0:fd83:79d8:6b68:b6b6) |
| 06:45.32 | *** join/#oe AndersD (~AndersD@h-98-128-162-82.NA.cust.bahnhof.se) |
| 07:02.22 | *** join/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 07:36.01 | *** join/#oe frsc (~frsc@2003:a:e7a:6200:4475:5b7:3b7d:d914) |
| 07:36.26 | *** join/#oe yegorich (~yegorich@mail.visionsystems.de) |
| 07:43.29 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 08:04.27 | *** join/#oe ao2 (~ao2@95.239.147.221) |
| 08:56.01 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 08:59.21 | *** join/#oe leon-anavi (~Leon@78.130.245.67) |
| 08:59.40 | *** join/#oe Bunio_FH (~bunio@81-18-201-214.static.chello.pl) |
| 09:00.58 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 09:20.50 | *** join/#oe tprrt (~tprrt@217.114.204.178) |
| 09:37.53 | *** join/#oe yann (~yann@85.118.38.73) |
| 09:49.09 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 10:11.17 | *** join/#oe tnovotny (~tnovotny@176-74-132-138.netdatacomm.cz) |
| 10:49.40 | *** join/#oe hpsy (~hpsy@217.66.60.5) |
| 11:17.49 | *** join/#oe rburton (~rburton@35.106.2.81.in-addr.arpa) |
| 12:02.19 | *** join/#oe berton (~berton@189.103.49.163) |
| 12:14.00 | *** join/#oe berton_ (~berton@189.103.49.163) |
| 12:19.20 | *** join/#oe hpsy (~hpsy@217.66.60.5) |
| 12:53.01 | *** join/#oe radsquirrel (~bradleyb@mail.fuzziesquirrel.com) |
| 13:22.04 | *** join/#oe tgamblin (~tgamblin@128.224.252.2) |
| 14:53.31 | *** join/#oe ericch (~ericch@50-205-235-218-static.hfc.comcastbusiness.net) |
| 15:08.45 | *** join/#oe ericch (~ericch@50-205-235-218-static.hfc.comcastbusiness.net) |
| 15:21.20 | *** join/#oe suihkulokki (~voipio@linaro/suihkulokki) |
| 15:21.47 | *** join/#oe stephano (~stephano@c-73-164-244-205.hsd1.or.comcast.net) |
| 15:59.49 | *** join/#oe ericch (~ericch@50-205-235-218-static.hfc.comcastbusiness.net) |
| 16:11.01 | *** join/#oe comptroller (~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net) |
| 16:55.13 | *** join/#oe ericch (~ericch@50-205-235-218-static.hfc.comcastbusiness.net) |
| 17:04.12 | *** join/#oe troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 17:12.34 | *** join/#oe troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 17:48.11 | *** join/#oe yann (~yann@91-170-159-152.subs.proxad.net) |
| 17:57.06 | *** join/#oe ericch (~ericch@50-205-235-218-static.hfc.comcastbusiness.net) |
| 18:06.51 | *** join/#oe Bunio_FH (~bunio@clj-165.netdrive.pl) |
| 18:13.35 | *** join/#oe ao2 (~ao2@95.239.147.221) |
| 18:14.20 | *** join/#oe hpsy (~hpsy@217.66.60.5) |
| 18:30.44 | *** join/#oe Crofton|road (sid401373@gateway/web/irccloud.com/x-ewfqxotxjrtnclbd) |
| 18:34.02 | *** join/#oe darknighte (sid214177@pdpc/supporter/professional/darknighte) |
| 18:34.20 | *** join/#oe mdp (sid49840@gateway/web/irccloud.com/x-efjzhdyfqsumyuab) |
| 18:34.22 | *** join/#oe jonmason (sid36602@gateway/web/irccloud.com/x-kiaqpeshibcgafuy) |
| 18:35.20 | *** join/#oe ribalda (sid306640@gateway/web/irccloud.com/x-kwuvavqkcihvmtzt) |
| 18:35.22 | *** join/#oe dl9pf (sid395223@opensuse/member/dl9pf) |
| 18:37.30 | *** join/#oe ukembedded (sid304355@gateway/web/irccloud.com/x-yvhgpazytaayozjj) |
| 18:38.09 | *** join/#oe mithro (sid24875@gateway/web/irccloud.com/x-zudacrjlrhmgbrme) |
| 19:00.38 | *** join/#oe berton (~berton@189.103.49.163) |
| 19:20.40 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 19:26.38 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 19:32.26 | *** join/#oe laplante (04107f5c@4.16.127.92) |
| 19:46.16 | laplante | Suppose I've got a recipe that has a native and target flavor, pulling from a repo with AUTOREV. Right now there is no guarantee that during parsing the two recipes will end up with the same SRCREV. This is because the srcrev cache is keyed based on repo + pn. One workaround would be to change the srcrev cache to be keyed just on repo (perhaps |
| 19:46.17 | laplante | controlled by a variable, BB_SRCREV_CACHE_GRANULARITY). Another option is to do like poky/meta/recipes-devtools/gcc/gcc-source.inc and have a separate recipe perform the fetch, which the actual recipes just DEPEND on. What do you all think? |
| 19:58.48 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 20:12.27 | laplante | RP: any thoughts? |
| 20:32.10 | RP | laplante: the trouble is you could intentionally set different revisions depending on PN |
| 20:33.02 | *** join/#oe comptroller (~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net) |
| 20:33.09 | RP | laplante: you probably need to set the revisions you want ahead of time, you're into the realms of very specific usage scenarios :( |
| 20:34.08 | laplante | RP: but in the case of different revisions based on PN, the srcrev cache won't be consulted. For example: SRCREV ?= "${AUTOREV}" |
| 20:34.16 | laplante | SRCREV_class-native = "githash" |
| 20:34.41 | laplante | And yes I realize this is niche :). |
| 20:36.00 | RP | laplante: you can't know they don't change the branch or something :/ |
| 20:36.16 | RP | laplante: I think you swap one set of problems for another |
| 20:36.40 | RP | laplante: perhaps it should cache by url? |
| 20:38.28 | laplante | RP: at least for git, the branch is also part of the key |
| 20:39.07 | RP | laplante: what exactly is it keying off? |
| 20:39.23 | laplante | RP: give me a sec, will pop open the cache to dump an example |
| 20:41.29 | laplante | RP: so if you look in fetch2/__init__.py, generate_revision_key is what is responsible for the key. It suffixes the result of calling "self._revision_key" with the "-${PN}" |
| 20:41.54 | laplante | RP: for git, _revision_key is defined as: "git:" + ud.host + ud.path.replace('/', '.') + ud.unresolvedrev[name] |
| 20:42.19 | laplante | RP: so basically, the host, path, and branch or tag name (I guess) |
| 20:43.15 | RP | not brilliant :/ |
| 20:43.33 | laplante | RP: lol which part? |
| 20:43.37 | RP | I hate poking at this code as we'll end up breaking other things :( |
| 20:44.04 | RP | I'm just thinking of all the other interesting parameters people keep adding to the git fetcher |
| 20:45.53 | RP | laplante: the fetcher is called fetch2 as fetch became such a nightmare. We still have pieces of it that leaked through, its better but not brilliant |
| 20:46.43 | RP | we probably could get away with keying on the other data |
| 20:47.01 | RP | I guess to solve your problem we have to try it |
| 20:47.20 | RP | I know who will get the bugs to chase down :( |
| 20:47.46 | laplante | RP: So I have actually already done it locally and it does work :). |
| 20:48.15 | laplante | I already chased down one interesting bug in persist_data.py, where a constraint violation was violated on the key. |
| 20:49.12 | RP | laplante: I spend most of my time chasing down weird bugs that only appear on the testing infrsatructure intermittently :( |
| 20:49.29 | laplante | RP: I've noticed, that's why I hesitated to bother you :/ |
| 20:50.15 | RP | laplante: I agree with your analysis and that its probably something to fix. I just worry about the impact of changes like this |
| 20:50.19 | laplante | RP: Re persist_data.py: There's a race in SQLTable::__setitem__, since the SELECT is executed under a read transaction, and is not upgraded to a write transaction until the INSERT or UPDATE actually runs. This was never a problem before removing -${PN} from the key, since conflicting keys were actually impossible. |
| 20:51.00 | RP | laplante: Well spotted, we should fix that too |
| 20:51.09 | laplante | RP: Yep, will submit a patch |
| 20:51.19 | RP | laplante: I know JPEW found a load of other problems in persist_data, its horribly broken |
| 20:52.06 | JPEW | https://bugzilla.yoctoproject.org/show_bug.cgi?id=13181 |
| 20:52.32 | laplante | RP: Perhaps we could gate this change on a new var as I suggested, e.g. BB_SRCREV_CACHE_GRANULARITY? |
| 20:52.37 | laplante | JPEW: :O that's a doozy |
| 20:53.02 | JPEW | laplante, Yep. That was a *fun* debugging session ;) |
| 20:53.12 | RP | laplante: Lets not do that, just creates more of a mess |
| 20:53.51 | laplante | RP: OK. I'm pretty confident (famous last words) that this fix is correct for the git fetcher. Not sure about the others that implement unresolved refs. |
| 20:53.58 | laplante | e.g. SVN |
| 20:54.18 | RP | laplante: (the reason is a config option then doubles the number of tests needed) |
| 20:54.48 | laplante | Gotcha |
| 20:54.52 | RP | strategy for svn is becoming "point and laugh" :/ |
| 20:55.25 | laplante | To be fair, that's my strategy for usage outside BitBake/Yocto as well |
| 20:56.32 | *** join/#oe ndec (sid219321@linaro/ndec) |
| 20:57.33 | laplante | RP: BTW I doubt you've had time to go through the recent email I sent (regarding building tagged releases) but I hope to post a prototype tinfoil-based script soon that is capable of generating the SRCREV_pn- overrides. |
| 20:58.07 | laplante | RP: My original approach of shoehorning the necessary support into fetch2 has been abandoned (and it sounds like I'm better off not playing with it too much anyway) |
| 20:58.52 | RP | laplante: I think I would much prefer to see things using its APIs, even event driven as handlers or through tinfoil |
| 20:59.04 | RP | it simply won't scale to everyone;s special way of handing sources |
| 20:59.35 | RP | laplante: I did read through it breifly and your journey through different appraoches |
| 21:00.12 | laplante | RP: Hope it was an entertaining read - I don't think I've ever rewritten a piece of code as many times as I did there :) |
| 21:01.09 | RP | laplante: I feel your pain, I'm open to ways of fetcher help but I think we need new approaches |
| 21:01.19 | RP | if we could rip autorev out the fetcher that would rock |
| 21:01.42 | laplante | RP: where would it move to? |
| 21:02.47 | RP | laplante: eventhandler? |
| 21:02.58 | RP | laplante: not sure, thinking out loud |
| 21:03.13 | laplante | RP: hmm interesting. Like a RecipePreFinalise or something? |
| 21:03.37 | RP | laplante: or similar. Could have its own event if needed |
| 21:05.21 | laplante | RP: I suppose it would be neat to add a stage after parsing that is actually "resolve upstream references". |
| 21:05.27 | laplante | RP: Since "parsing" right now basically covers both |
| 21:05.56 | *** join/#oe ao2 (~ao2@95.239.147.221) |
| 21:06.10 | laplante | Would be convienent to decouple them |
| 21:07.39 | RP | laplante: Its not quite as simple as "after parsing" since some of the code you're parsing depends on the revision/version |
| 21:07.52 | RP | which is what makes autorev such fun |
| 21:07.54 | laplante | Ah true. |
| 21:09.29 | RP | laplante: not trying to put you off, just being clear about the challenge |
| 21:09.40 | laplante | RP: no I get it :) |
| 21:10.44 | laplante | RP: (the point you're making, not the full consequences/minutiae of the challenge) |
| 21:11.54 | RP | laplante: I've never liked how that code works... |
| 21:12.17 | RP | or uninative installation process which I'm currently reminded of :/ |
| 21:14.11 | *** join/#oe ndec (sid219321@linaro/ndec) |
| 21:14.48 | laplante | RP: what specifically about uninative do you not like? |
| 21:15.55 | RP | laplante: its hacked onto the front of the system without a dedicated event or a dedicated point in the task graph |
| 21:16.19 | RP | plan was to prove it and add something proper in due course |
| 21:16.27 | RP | worked too well |
| 21:17.02 | RP | laplante: to see what I mean, watch the NATIVELSBTRING in a first build in a clean directory vs the second |
| 21:21.55 | laplante | RP: Gotcha. |
| 21:22.44 | laplante | RP: The one thing I've noticed about it is that since it operates outside the task graph, it can't be setscened, so never makes it to a sstate mirror :/ |
| 21:23.25 | RP | laplante: setscene makes no sense there, its already a binary |
| 21:23.39 | RP | sstate mirror is a different story though |
| 21:24.20 | laplante | RP: Ah yes, messed up my terminology. |
| 21:24.21 | fray | FYI I backported the recent sstate-cache changes to zeus and they are fixing problems we had |
| 21:24.46 | RP | fray: the length ones? |
| 21:24.53 | RP | made a lot of changes recently |
| 21:25.08 | fray | yes, that series of 4.. |
| 21:26.16 | fray | there were 2 others from master I pulled in as well.. (I brought in anything that modified sstate.bbclass) |
| 21:37.38 | *** join/#oe laplante (04107f5c@4.16.127.92) |
| 21:48.08 | laplante | RP: do you know why fetch2 allows more than one name for a SRC_URI entry? e.g. SRC_URI = "git://whatever;name=name1,name2" ? |
| 21:49.02 | laplante | (^ last question, I promise) |
| 21:51.54 | RP | laplante: no, that seems strange |
| 21:52.19 | RP | fray: so you're saying we should backport them officially? |
| 21:52.45 | fray | for me I needed them.. but changing the sstate paths means more of a decision from someone other then me |
| 21:52.48 | laplante | RP: just as you wrote that I think I found the "answer". I think it's becuase multiple branches can be specified, and you need one name per branch. Which raises why would you need to clone more than one branch? |
| 21:52.56 | fray | (but yes, I've been using them now for about 18 hours and they're working great) |
| 21:53.07 | RP | laplante: the kernel used to do that |
| 21:53.08 | fray | this is on top of zeus w/ out own internal layers.. |
| 21:53.47 | fray | (I can get you the list of what I merged if you care.. but easy enough to figure out) |
| 21:53.55 | RP | laplante: it needed a bare repo where we ensured X branches were present with revisions ... |
| 21:54.22 | RP | fray: I can guess, really just a question of whether we want to do that in stabl |
| 21:54.48 | fray | at a minimum all of the ones other then the change of the directory structure I think we do.. |
| 21:55.03 | fray | I personally think the directory structure change is a good idea.. but I'm not sure it is for general zeus maitneance |
| 21:57.40 | RP | fray: well, the filename limiting is way more invasive |
| 21:58.13 | fray | but without it, things are broken |
| 21:59.13 | RP | fray: and have been since forever |
| 22:00.23 | fray | but it was bad enough I couldn't build.. |
| 23:24.00 | *** join/#oe tgamblin (~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com) |