5399 2013-10-28 17:21:44 +0000 Analyze Sharing PR server between builders with different metadata 2026-07-09 15:19:52 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 1.6 x86 Multiple ACCEPTED Medium enhancement Future 5466 10564 1 Martin.Jansa unassigned alejandro.hernandez alexandru.c.georgescu benjamin.esquivel bluelightning chong.lu jessica.zhang jose.a.lamego joshuagloe juan.m.cruz.alcaraz koen leonardo.sandoval.gonzalez poky.bs.watcher poky.watcher randy.macleod richard.purdie sgw tgamblin --- --- Yes (doc changes required) oldest_to_newest 38231 0 Martin.Jansa 2013-10-28 17:21:44 +0000 Alias access-control for PR server. It's not only about restricting write-access to anonymous users, it's more complicated than that, because it's not clear what such user should do when his signature is different than what PR server has. One way is to add another level in EXTENDPRAUTO, but using max(from-r/o-pr-server).your-local-AUTOPR value doesn't work, because your different local signature isn't always "newer" than what build server has (and you don't want to downgrade some packages on target device and cause e.g. unresolved .so dependencies). Right now I'm exposing writable PR server to local users, which has its own pros and cons. pros: - it's safer to let local users to "bump" it because at least they pre-allocate some number from their signature, so I can be sure that official build server won't build exactly same .ipk with different signatures cons: - 1) if you change busybox.bb and it gets EXTENDPRAUTO bump .1 -> .2 2) some other change in busybox.bb EXTENDPRAUTO bump .2 -> .3 3) some local user reports that the change from 1) was incorrect and prepares his own solution which integrates change from 1) and fix EXTENDPRAUTO bump .3 -> .4 4) maintainer reverts 1) but because of 2) gets new EXTENDPRAUTO bump .4 -> .5 5) maintainer cherry-picks 3) gets old EXTENDPRAUTO value .4 created by local user in step 3), so the fix is never seen by packagemanager as upgrade from .5 Of course you can get EXTENDPRAUTO going backwards a bit easier if you just push something and then revert it without any other changes - but in this case you can be careful and e.g. manually bump PR or something to create new version, but in previous example you usually don't know that some local user already pre-allocated .4 with his local signature and your feed is just unlucky to match it exactly - it doesn't happen often, because usually there are other commits which change signatures more quickly. Honestly I don't see how to use PR server from multiple builders with possibly different metadata and get 100% reliable binary feed from that. My current work-around is to copy prserv.sqlite3 as build artifact for my feeds and encourage users to rather use it as one-time import, rather than using PR server directly (I was doing the same with bb_persist_data.sqlite3 for LOCALCOUNT numbers). 62453 1 leonardo.sandoval.gonzalez 2016-05-25 20:43:43 +0000 Due to limited resources, moving this to 2.3 67614 2 leonardo.sandoval.gonzalez 2016-10-26 21:54:36 +0000 Martin, do you know if this issue still apply on 2.2? I am trying to make an space to work on this one and understand current status. 76237 3 juan.m.cruz.alcaraz 2017-08-29 15:18:30 +0000 (In reply to comment #2) > Martin, > > do you know if this issue still apply on 2.2? I am trying to make an space > to work on this one and understand current status. Martin, does this still apply on 2.5. 76241 4 Martin.Jansa 2017-08-29 15:25:41 +0000 Yes, it still does apply to 2.5. I don't use binary feeds anymore, but for anyone who cares about upgrade path in binary feed it's still broken. 76245 5 juan.m.cruz.alcaraz 2017-08-29 15:49:45 +0000 *** Bug 10564 has been marked as a duplicate of this bug. *** 99105 6 tgamblin 2024-05-30 15:11:30 +0000 This is still relevant to binary distro work.