**** BEGIN LOGGING AT Sat May 09 02:59:58 2020 May 09 09:03:36 JPEW: it was lost, sorry. I thought I'd added to the branch but I had not, probably fear of full rebuilds May 09 10:18:39 I just discovered that pre/postfuncs behave differently from _pre/_append. Let's say do_unpack_and_patch modifies S, WORKDIR,... if I have a function which uses S and is called via pre/postfuncs the modification to S by do_unpack_and_patch is not being picked up by my function, if I use e.g. do_patch_prepend instead my fucntion gets the modified version of S. Is this by design? Is this documented somewhere? May 09 10:28:29 RobertBerger: I think it depends which function is making the modification and how May 09 10:29:01 RobertBerger: most functions do not do that, the archiver ones are 'creative' May 09 10:59:16 @RP I tried to "fix" meta-java since it it broken when you use the archiver.bbclass. May 09 11:01:34 @RP and this is what seems to work: https://github.com/RobertBerger/meta-java/commit/f988b1d7ac332bff3ed21d40b91b78247ad52610 May 09 11:04:29 @RP what puzzled me for a long time is that so far I could not break the archiver and that meta-java/openjdk up to now for sure was incompatible with archiver May 09 11:21:07 RobertBerger: The archiver code calls into the fetcher and executes the fetch functions directly. It therefore doesn't catch modifications the recipe makes to the fetched sources May 09 11:21:37 RobertBerger: you did tell if you wanted the original sources, not any modifications ;-) May 09 11:38:53 @RP: it fails in do_patch ;) since this https://github.com/RobertBerger/meta-java/blob/2020-05-08-dunfell/recipes-core/openjdk/openjdk-8-common.inc#L33 extracts sources into the wrong dirs when the modified S, WORKDIR,... are not picked up. So I don't think the problem is the archiver, but meta-java ;) May 09 12:16:52 RobertBerger: I don't understand, the recipe shouldn't see any of that :/ May 09 12:19:19 @RP: think about that: without archiver all is good. cd "${S}" followed by tar xjf ${WORKDIR}/${CORBA_FILE_LOCAL} --transform "s,-${CORBA_CHANGESET},,g" works May 09 12:21:22 @RP: now if the archiver moves S to S/archiver-workdir or so tar xjf ${WORKDIR}/${CORBA_FILE_LOCAL} --transform "s,-${CORBA_CHANGESET},,g" does not work anymore, it should be $WORKDIR/../${CORBA_FILE_LOCAL} May 09 12:22:06 and do_patch from do_unpack_and_patch can not patch since the files to be patches are unavailable May 09 12:25:13 RobertBerger: Hmm. The better fix may be to have that function use ${S} instead of WORKDIR May 09 12:26:05 RobertBerger: although it changes WORKDIR, not S that is what is confusing me May 09 12:26:25 archiver changes both May 09 12:28:17 RobertBerger: It doesn't change S, S contains WORKDIR May 09 12:29:13 RobertBerger: depends on how you look at it May 09 12:52:13 RobertBerger1: I think this is the local fetcher being a pain. I think if we 'fetch' the file urls in do_unpack_and_patch this would work better May 09 12:53:46 You mean hacking the archiver class? May 09 13:02:08 RP: if you feel like unbreaking the archiver class I am happy to test. I tried not to touch the archiver class and come up with some minimal intrusive patch for meta-java. May 09 16:43:05 halstead: i wonder if it would make sense for the tools in the yocto project that fetch from the mirrors use a "secret" user-agent, and maybe setup the server so it only delivers to the secret agent. in hopes of deterring traffic from using the mirror for non-yocto-related purposes? May 09 16:43:42 or at the very least to track yocto and non-yocto usage? May 09 17:41:17 tlwoerner: do you think there's actually any non-yocto usage, though? May 09 17:44:21 tlwoerner: it sort of seems like a non-problem unless the hosting cost of the mirror is dramatically higher than expected May 09 17:51:54 tlwoerner: I'm also wondering if this is a problem we need to solve May 09 20:32:11 RP: I don't think it will cause rebuilds because I whitelisted the variable May 09 21:21:26 JPEW: true, it was more that I had enough other issues to worry about I guess. Its tested and in now May 10 02:47:51 smurray: RP: sorry, i never meant to imply there was a problem, never mind one that might need any sort of solution May 10 02:48:22 presumably we use the statistics of the download mirror to track usage and who's still using which branches May 10 02:49:08 but if a significant portion of those downloads are not yocto-related, then any stats would be useless May 10 02:49:24 i would, further, assume that bandwidth isn't free May 10 02:50:21 if other projects figure out there's this amazing mirror out there serving up tarballs of every gnu/linux package known going back decades for free... May 10 02:51:43 i recently tried to use wget to download something from a site and found that it kept failing, yet when i used a browser it would succeed May 10 02:52:33 investigation showed that this side had blocked access based on user-agent, so it made me think that using the same "trick" might be useful if what you're after are meaningful data May 10 02:54:53 from what i can tell, we currently have no way whatsoever to tell if there is any non-yocto usage, so nobody can answer that question **** ENDING LOGGING AT Sun May 10 02:59:57 2020