Le dimanche 19 juillet 2020 à 10:39 -0700, Kevin Fenzi a écrit : > On Mon, Jul 13, 2020 at 10:17:11AM +0200, Nicolas Mailhot via devel > wrote: > > Tough it is a litteral key = value file with no fancy formatting > > nor > > even ini-like sections, and a handful of variables. Very boring > > KISS > > stuff. > > Sure, but a file with 16 spaces and a newline is pretty confusing. I will add a line of comment instead. The confusion is due to the fact rpmbuild wants source files to exist before the build starts, and wants them to be more than 13 bytes. I thought filling with spaces would convey the empty file idea, I was wrong, adding a comment is trivial and the parsing code is robust WRT comment lines, so no biggie to change and improve. Thank you for the enhancement suggestion! > But then you know that exact thing was built. > With this setup you look at the git hash in koji and... it's the next > commit after that thats exactly this build? Thats really messy. The system separates build commits from modification commits. It’s not like right now when most commits are modification *and* build commits, except when they are not (because the change was done in several commits, because the build failed but git still pretends it occured, because a branch was EOLed before the modification process finished, because the commit tracked a build that did not pass bodhi gating, etc etc.) The proposed system is a lot more clear and strict, for a build to be tracked in git it needs to have actually succeeded and be commited back, anything else is packager WIP. Making git history something you can rely upon. > Right, I was suggesting _changing_ your macros for this workflow. > > maintainer makes changes, runs scratch builds, tests, etc. > They decide everything is good for an official build. > They generate the files and the macros just use those generated > files, > they don't bump anything or require a post build checkin. You do not need to change the macros for this workflow, they already support reproducible replay. Just prepare your build out of band and then ask to build it in reproducible mode. That only requires buildsys support to set the variable that activates reproducible mode, and buildsys or packager support to make sure the buildroot content matches the test builds (macros can do a lot of things, they can not manage buildroot state in stead of the build system). However what this amounts to is the following: 1. build packages in scratch mode 2. check 3. commit 4. rebuild scratch builds in reproducible mode That is more complex than the target workflow in the macros 1. build packages 2. check 3. decide to keep the packages, and commit back The second workflow is more reliable than the first one, because the second preserves the packages you tested, instead of hoping nothing changed in the buildroot between the two build steps. Of course doing it in 3 steps requires pairing back commit with bodhi gating, absent bodhi changes it will probably be more involved at first. But the fact is it *can* evolve to a 3-step process with infra help, and the evolution is consistent with what we’ve been trying to achieve in the past years, and the current 4-step process is also supported at macro level, as long as fedpkg/koji learns to set one variable (*not* rocket science). And setting one variable is no different from the generic bcond stuff ELN people want to happen. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
