**** BEGIN LOGGING AT Mon Feb 14 02:59:56 2022 Feb 14 07:41:40 good morning Feb 14 08:54:35 RP: "you're saying that in the run file, the functions read_subpackage_metadata and do_package_ipk are sometimes listed in one order and sometimes in the other but the order of the exec_func calls in do_package_write_ipk is always correct?", exactly, the scripts will do the same thing, the exec_func are in the same order. Feb 14 08:58:24 jeroen_: yes, I'd suggest python dict ordering causes it but it won't change the signatures for the task Feb 14 12:50:35 RP: ok understood, as already mentioned, I do have a single do_package_write_ipk.sigdata, so it indeed doesn't seem to change the it. But do you have any idea why I have it running per machine? Feb 14 12:52:28 jeroen_: did you say one of the builds fails? Feb 14 12:54:27 yes, I pasted the details here https://pastebin.com/At4XgPhD Feb 14 12:54:56 well, not sure I already said that it fails, but it does.. Feb 14 12:55:12 jeroen_: so did you try the -S none trick I mentioned ? Feb 14 13:01:24 running now.. Feb 14 13:11:02 RP: right, thanks, that makes the sigdata file appear; and the problem, there is a RDEPEND to a machine specific config for qt. Feb 14 13:15:13 jeroen_: glad you to the bottom of it! Feb 14 13:32:28 hi guys, I'd like to ask about the hash equivalence server. If I want to share the db with some clients (together with the shared state)... can I execute a second instance of the `bitbake-hashserv` in read-only mode over the same db file that is being use for the CI builders in RW mode? or should I create a copy of the database to start the read-only hashserv? Feb 14 13:52:45 dagmcr: You should be able to run a second instance in most cases. It uses sqlite which supports that Feb 14 13:53:35 dagmcr: I'm not sure if sqlite uses file locking for that, but that would be the thing to watch out for if it does; make sure the underlying FS supports it Feb 14 14:05:03 Thanks @JPEW. I will try it. On the other hand, if i want the read-only 'clients' to use the CI db (hash server)... is the `HASHSERV_UPSTREAM` the way to go? Or it's just to connect with the yocto public hash equiv server? It seems you can either achieve the same by running a server in `--read-only` or keep it in rw while clients use the `HASHSERV_UPSTREAM` instead of the `BB_HASHSERVE`. Feb 14 14:06:39 I'm not sure if `HASHSERV_UPSTREAM` works only when hashserv runs in `--read-only`... Feb 14 14:06:58 Ya, it depends on what you want. If the upstream is read-only, use HASHSERV_UPSTREAM, if the clients can publish results back (which also means they are sharing sstate back), then BB_HASHSERVE Feb 14 14:09:45 well, I want clients to use the server in read-only as they are only consumers of the sstate-cache while the CI builds are the ones publishing in the hash serv db + sstate-cache. In that case, seems like I can go with both options? server in `--read-only` + client `BB_HASHSERVE`. Or server in `rw` + client `HASHSERV_UPSTREAM`. Feb 14 14:28:41 dagmcr: server in --read-only, client uses HASHSERV_UPSTREAM Feb 14 14:30:03 dagmcr: Or more specifically, run two servers, one rw and one ro. The CI will use rw server with BB_HASHSERV, clients will use ro with HASHSERV_UPSTREAM Feb 14 14:39:39 RP: is there a way to tell bitbake not to care so much about the RDEPENDS, as in as long as the version is the, don't repackage it? Feb 14 14:39:59 .. is the same .. Feb 14 15:00:53 jeroen_: no, since the output would be different, it does have to care Feb 14 15:04:26 RP: but these are RDEPENDS, not DEPENDS, why would it need to care about the contents instead of only the right version to reference? Feb 14 15:06:33 RP: in this case, the only thing which differs is the presence of a touchscreen, https://github.com/victronenergy/meta-victronenergy/blob/master/meta-venus/recipes-qt/qt4/qt4-machine-conf/einstein/qt4.sh Feb 14 15:07:11 RP: it seems rather a overkill to trigger a repackage of qt for that per machine.. Feb 14 15:07:53 (and yes, obviously I can move that RDEPEND to another place, so it won't happen...) Feb 14 15:17:01 jeroen_: the rdepends are written into the packages. If it changes, you want it to rebuild and generate different output Feb 14 15:17:15 the system can't just ignore that Feb 14 15:35:21 RP: why not, there is vardepsexclude e.g., why not vardeps=VERSION e.g. Feb 14 15:36:19 (well more like something[vardeps] = "${PV}" or something Feb 14 15:39:30 jeroen_: If a recipe says RDEPENDS = "X" for one machine and then RDEPENDS = "Y" for another, it is entirely correct that it rebuilds and you do not want to stop that. It sounds like the RDEPENDS is in the wrong place (the other alternative being that the recipe should be marked as machine specific) Feb 14 15:39:47 jeroen_: I'm not saying you can't exclude these things, I'm saying it would be incorrect to Feb 14 15:40:57 JPEW: Thanks for the help. I'll set up my 2 hash servers in that way. Feb 14 15:41:54 RP: understood, I will simply move it to another spot Feb 14 15:44:01 RP: but it is still interesting, even for DEPENDS, egl provides common headers, but the implementation might be machine specific, that also triggers quite some unnecessary rebuilds.. Feb 14 15:46:14 jeroen_: there are some mechanisms which can avoid that but in general if you have machine specific headers like that the library is also machine specific :( Feb 14 15:47:28 RP: yes, but that doesn't need to make qt machine specific perse.. Feb 14 15:49:44 Hello there **** ENDING LOGGING AT Tue Feb 15 02:59:57 2022