flashrom November 2022

flashrom@flashrom.org

17 participants
16 discussions

Status of Meson support, where are we? (was Re: Build systems and `uinstall` option)
by Nico Huber 14 Nov '22

14 Nov '22

Hi all, it feels like this deserves its own thread. I was a little surprised by the news that we are already ready to deprecate Make. Hopefully, I'm just not up to date and this is the case! If I'm horribly off track, please ignore the following. IIRC, we said this would be the case if we can do everything with Meson what we can do with Make (due to lack of knowing what the latter can, we made a list of target environments that we need to support at least) and Meson produces the same binaries as Make. Are we there yet? My last state wrt. the more special target environments like lib- payload was that it seems feasible, but I haven't seen a PoC yet. On 10.11.22 17:43, Felix Singer wrote: > The Make build system is going to be deprecated with the next release > and it is going to be dropped with the release after that. "next release" being the one that just started or the next after that? iow. does this mean deprecate with flashrom 1.3 and drop in 1.4? > We discussed the Make build system in many meetings now and we all > agreed that we won't add any more features to it. That means its > current feature state is frozen and it doesn't get any additional > functionality, just bug fixes, refactorings or adjustments as far as > they are really necessary. Was this ever discussed on / announced to the ML? My status was that this was of the "nobody objected during some meeting" decision kind. Nico

5 7

Build systems and `uinstall` option
by Joursoir 14 Nov '22

14 Nov '22

Hello everyone, I wonder why there is no 'uninstall' option in the flashrom's Makefile? Is it just an oversight? Or do we have a reason for that? The same question is related to the meson script. -- Joursoir

5 12

Future development and release process
by Nico Huber 11 Nov '22

11 Nov '22

Hi flashrom fellows, some of us have picked a new release process for flashrom 1.3 that ignores the problems of the master branch but will attend to them on a separate branch. This leaves us without a strategy to get future releases done with less hassle. It also feels quite frustrating be- cause I fear it takes incentive away to fix the master branch. And hence increases the incentive for myself to abandon said branch. During a phone call with Felix, I explained the options I see roughly as follows. There are probably more options, feel free to discuss others as well. These just came to my head. 1. Full reset: Branch off 1.2.x before the master branch started to make trouble. Also reset the Gerrit privileges to a state where only people got merge rights after they earned trust by the pre- existing maintainers (people with those rights); to prevent that history repeats itself. So far this seemed to be unacceptable by the Google team. The rest of this email will assume that we won't be doing this. If it turns out I'm wrong, this would be my preferred solution and we won't have to discuss anything below. 2. Try harder: Keep working on the current master branch. Try to fix the process as we go along. This is unacceptable to me. We have tried this already and I have not seen things getting better. Building up on a broken state is most often harder than rewinding to a good state and starting new things from scratch. Working on this branch has not been fun since flashrom 1.2. Beside that, the master branch hasn't provided any- thing that I could use in my day job for years (not as a develop- ment tool and definitely not in our products). 3. Compromise: The current situation evolved due to a highly dynamic development process that is roughly the opposite of what we had before we tried to converge upstream and chromium development. Also, adding many new developers that are used to a very different process requires a lot of communication (IMO) which didn't happen. We could accept these different development strategies and work on two branches. Not(!) competing branches but branches that complement each other. Something like this was actually proposed before [1]. The rough idea: we could have a 'stable' branch and a more dynamic one. Back then we called the latter 'staging'. Merging commits to the 'stable' branch would be limited to maintainers who know flash- rom well enough and trust each other. To be honest, I wouldn't care much what happens on the 'staging' branch, who gets to merge etc. There were often reservations if this could work without diverging the branches. But there are strategies to avoid it. For instance, a regular `git merge` onto the 'staging' branch could avoid that. To give it a good start, I would also suggest to base a 'stable' branch on 1.2.x. 4. Divide: If we don't find a compromise, I'll have to continue my work on a new branch. I wouldn't care then if things diverge. Details depend mostly on who would like to join the effort. It would likely start on 1.2.x with things added from the current master branch (might get things through review again, or also cherry pick real cherries directly without going through Gerrit). Quite unappealing because it would push contributors to choose a branch. And we would have to discuss how to deal with future releases. You may notice that most of my ideas suggest rewinding to 1.2.x. Beside easing further development on a reasonable code base, there is one more thing driving me: The master branch contains many commits that caused awkward feelings. I think it would help working together if we wouldn't be reminded of them all the time. Nico [1] https://www.flashrom.org/index.php?title=Development_Guidelines&oldid=2252#…

1 0

Documenting flashrom's guts
by Angel Pons 07 Nov '22

07 Nov '22

Hi list, There's several things regarding flashrom's structure that seem to be underdocumented (or *are* documented, but the information is extremely hard to find). It would be very helpful to have this information available somewhere easy to find, such as the Wiki. Some things that would greatly benefit from being documented are: - flashrom's layers: which layers there are, and how they interact with each other. - flashrom's structures: which structures there are, how they interact with each other, and how they "map" to layers. Surely there are more things that would benefit from being documented. Let's not discuss *who* is going to do what for now; first, let's collect information about these parts of flashrom. Best regards, Angel

3 2

Branch 1.3.x is being prepared for release candidate
by Anastasia Klimchuk 07 Nov '22

07 Nov '22

Good Day Flashrom community, We’ve got good news about the upcoming release v1.3. Branch 1.3.x is officially opened and being prepared for release candidate. The branch has been fast-forwarded to head as of Friday last week. We are now going through the list of what is critical to do for the release and patching 1.3.x accordingly. You can see the patches for 1.3.x by this link: https://review.coreboot.org/q/project:flashrom+branch:1.3.x The next step will be to put an RC1 tag for the branch (when ready for that) and write another announcement. If you know of any bugs, please report to us, and thank you! In any case, bugs will be reported in the bugtracker. And then we can decide what’s the urgency and whether the bug is blocking the release or not. Meanwhile, development continues on master branch. Specifically, there are few ongoing projects in various stages of development: all of that continues. And hopefully, could be included in the next release. Thanks everyone! -- Anastasia.

1 0

Re: [review] WP documentation for flashrom users
by Anastasia Klimchuk 04 Nov '22

04 Nov '22

I only noticed now that the mailing list got lost from the last two messages. I apologise for that, it was completely unintentional! Re-sending again, and now including the mailing list. Text below. On Wed, Nov 2, 2022 at 12:17 AM Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com> wrote: > > On Tue, Nov 01, 2022 at 09:32:27AM +1100, Anastasia Klimchuk wrote: > > Sergii, you mentioned in the earlier thread, you can convert the text > > to mediawiki format? That would be great! > > Also, would you be able to update the wiki page by yourself? We can > > create an account for you. > > Then you can preview/correct the text , until the result looks good to you. > > > > As we agreed in the earlier thread, this should go to > > https://www.flashrom.org/Documentation#Using_flashrom section. > > > > Thank you so much for your contributions! > > Yes, I can deal with MediaWiki and handle formatting issues myself if > I'll get an account. > > Just for information, it's trivial to convert to Wiki automatically: > > pandoc -w mediawiki bootblock-protection.md -o bootblock-protection.wiki > > The important thing is to have empty lines before lists in Markdown, > pandoc doesn't recognize lists otherwise. There can be other minor > differences. -- Anastasia.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom November 2022