On Dienstag, 4. März 2025, 11:57:57 CET Michal Suchánek wrote:
On Tue, Mar 04, 2025 at 11:41:58AM +0100, Adrian Schröter wrote:
On Dienstag, 4. März 2025, 11:35:27 CET Michal Suchánek wrote:
On Tue, Mar 04, 2025 at 11:27:12AM +0100, Adrian Schröter wrote:
On Dienstag, 4. März 2025, 09:58:13 CET Michal Suchánek wrote:
On Tue, Mar 04, 2025 at 09:49:58AM +0100, Adrian Schröter wrote:
On Dienstag, 4. März 2025, 09:38:52 CET Michal Suchánek wrote: > On Tue, Mar 04, 2025 at 09:31:18AM +0100, Adrian Schröter wrote: > > On Dienstag, 4. März 2025, 09:14:53 CET Richard Biener wrote: > > > On Mon, 3 Mar 2025, Michal Suchánek wrote: > > > > > > > On Mon, Mar 03, 2025 at 03:34:56PM +0100, Adrian Schröter wrote: > > > > > On Montag, 3. März 2025, 14:53:09 CET Michal Suchánek wrote: > > > > > > On Mon, Mar 03, 2025 at 02:18:38PM +0100, Adrian Schröter wrote: > > > > > > > On Montag, 3. März 2025, 14:05:40 CET Michal Suchánek wrote: > > > > > > > > > > ... (trying to get back on focus) > > > > > > > > > > > > I agree, but this is actually the goal with git approach: > > > > > > > > > > > > > > Having one single identifier to get an entire build setup which can be used > > > > > > > to reproduce the entire build. This is not possible with classic OBS mechanics. > > > > > > > > > > > > > > Unfortunatly, this means that local hacks don't become easier ... > > > > > > > > > > > > And hacks in prjconf suggested multiple times throughout this thread > > > > > > undermine this reproducibility, as is already the case with the old > > > > > > mechanic and multibuiltd. > > > > > > > > > > > > I want: > > > > > > - everything built by default > > > > > > - a project configuration *DATA* file for selecting what to build, per > > > > > > architecture/repository/flavor > > > > > > > > > > you can do this via the build config in a way that works in git projects > > > > > and also in classic OBS setups (and solving issues there as well): > > > > > > > > > > There are either onlybuild: or excludebuild: tags which you can use > > > > > to enable or disable builds. You can use them also for flavors, for example > > > > > > > > > > BuildFlags: excludebuild:<package>:<flavor> > > > > > > > > > > like > > > > > > > > > > BuildFlags: excludebuild:kernels-source:kernel-default > > > > > > > > > > > > > > > And you can have any %if statements (repository name, architecture, ..) > > > > > around these. > > > > > > > > > > This works with git and classic OBS, with project linking, via path > > > > > elements and so on. And without the need to check at least 4 different > > > > > source histories and replicating them just for a single build. > > > > > > > > It actually does not. > > > > > > > > 1) this is inherited between repositories, and then once a build is > > > > disabled it cannot be reenabled > > > > You can omit build config rules again on a higher level if needed via > > prefixing it with an ! > > > > For example > > > > BuildFlags: !onlybuild:kernel-source:kernel-default > > > > should enable it again, if it was disable in another repo you are referencing it. > > Oh the atrocity intensifies. So if you want to build a package you have > to negate any build flags that might have been set in a project you are > building against. > > How do you do that? > > Set up the project, get the expanded prjconf, negate any flags present, > and then add yours on top? > > Could we just drop this atrocity in favor of actual data based > per-repository configuration?
Actually, it should be easier because you could just build against the source and repositories of the base project.
Atm. you have multiple revision repositories, in your case at least these:
1. Project meta repo 2. Project build config repo 3. kernel-source meta repo 4. kernel-source source repo 5. kernel-default meta repo 6. kernel-default source repo 7. kernel-obs-build meta repo 8. kernel-obs-build source repo 9. kernel-obs-qa meta repo 10. kernel-obs-qa source repo
And for each kernel flavor you get two more.
All of them are not connected and on a replication of the build setup you need to copy all of them and even worse, in package meta case there is code which needs to know which parts of the files can be copied, which needs to adapted and which must not be copied.
In case you want to learn about the configuration of a build, you have to verify all of them independend.
With the git approach there would be only
1. Project source, referencing to all package sources 2. Project meta repo (and even here we will be able to store critical parts in the source)
And you don't need to fiddle around per package, they would get the config from the project source definition.
Your branched project just needs to define the wanted repositories and these should have a path to their pendant of your base project.
It utterly fails when I want to build the package independetly of the base project build settings because these are silently imported, the format of the settings is unspecified,
what do you mean here exactly? The BuildFlags are specified in
https://opensuse.github.io/obs-build/pbuild.html#_about_the_build_configurat...
. IMHO as good documented as any package meta flag.
Yes, the flags are. The file as a whole is not.
The syntax of the conditionals is not defined.
indeed, we can add that.
The syntax is whatever rpm accepts, and rpm syntax is not documented, either. So no, you cannot unless you take on documenting rpm spec and macro file syntax, and then define which is used in which parts of the prjconf.
we don't use rpm to interpret this file to schedule build jobs. We know our parser, so we can document it.
The inheritance is poorly documented.
that is independ an obs feature.
And previously was not involved in setting what to build, and now is.
That's one of the problems. It's no longer an independent OBS feature.
??? any package meta setting was always only an OBS feature. There is now the additional possibility to build also independ of OBS. But we build also the same inside of OBS.
That setting these buildflags requires examining buildflags of all projects built against is definitely not explicitly documented.
that is in general true for any build config setting which is there in OBS.
Indeed. Except the old build selection settings were not in prjconf, they were separate.
They could be randomly copied when packages were branched but then were separate and explicit. The whole settings would be visible as a XML document in the project they apply to, and could be altered in the web UI as well as by editing that one project.
you obviously never had to debug a state, not understandable by someone, where you had to check several meta histories, sync timestamps between them, guess temporary build states at that time and that via many repositories and projects.
The current solution of stuffing them in prjconf is a severe regression in transperency, intelligibility, and usability.
and there is no tooling neither in the web UI
well, yes, the goal is to have it as part of the source.
What parts of package to build in which repository should be separate from the package source.
yes, it would be in the source of the project. But not in multiple meta objects in multiple own revision trees which you need to combine (also not that good documented, I have to admit).
And handling the above listed independend repositories via webui is not really a serious thing either.
nor the commandline to alter these settings.
sure, it is just a git commit and push.
Except you have to know what setting are in projects you build against to negate them. I did not know git push had this functionality. Where is that documented?
The build config in a git project is stored as "_config" as normal file.
So in general we have again only the build config documentation here.
You can also try it without git if you want by using "osc meta prjconf -e ..."
But that does not show the settings that apply to the project, only the part stored in the project, not the upstream settings.
yes, but neither the package meta is doing that. You can just guess. In any case you would need to fetch current build state. In the past and also in the future. again, I offered you a brainstorming how to get a better solution for your very specific issue. Something where we can still replicate the build setup without plenty of individual setup tasks of copied many repositories and editing many meta files. I can imaging that we could add further functionality to give hints as part of the package source for the build flags. But you won't get me to a solution which requires many many manual steps, many independend history repos and reverse engineering of the timeline of intermediate states. That is just the horror for any tooling and for anyone who needs to debug content. Also violates clearly the goal of getting a reproducible build based on a given source. -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev