[flashrom] Re: Release preparations
On 21 March 2022 22:04:07 WET, Greg Troxel wrote: > >Richard Hughes writes: > >> On Mon, 21 Mar 2022 at 20:04, Nico Huber wrote: >>> There is also one big general issue: we need to maintain two build >>> systems now. We can't use GNU make only, because nobody knows what >>> the requirements of the Meson users are. >> >> My vote would be to remove the *Makefile*, and move 100% to Meson -- >> the modern build-system that's *already* being used by the packagers >> for all the supported architectures and OS builds on dozens of >> distros. > >FWIW, the pkgsrc build is currently using the Makefile. I use that to >get flashrom on NetBSD-9 amd64 to use with apu2. > >More importantly, the instructions in the README in flashrom 1.2 do not >mention meson and say to use make. > >Similary, > https://www.flashrom.org/Downloads#Installation_from_source >does not mention meson. >(It also doesn't mention that specifically GNU make is required, vs BSD >make, but that's pretty common to omit.) > >(I'm not claiming that building with meson wouldn't work, but just >pointing out that "all packaging system builds use meson" is incorrect.) > >So if there is any talk of removing makefiles, there needs to be a >release with formal support for meson including it being the standard >approach in REAMDE and a deprecation warning. > Beside from the documentation, the meson file currently only works for Linux and was never announced as official way to build flashrom. Dropping the Makefile is also no option as long as the meson.build does not work with all platforms supported by flashrom. In a release we should have a consisted build system across all those platforms. The two build systems are also topic of the next developer meeting. Imo we should find a proper solution for the meson build file and do not rush for the next release. -- Thomas ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Release preparations
Richard Hughes writes: > On Mon, 21 Mar 2022 at 20:04, Nico Huber wrote: >> There is also one big general issue: we need to maintain two build >> systems now. We can't use GNU make only, because nobody knows what >> the requirements of the Meson users are. > > My vote would be to remove the *Makefile*, and move 100% to Meson -- > the modern build-system that's *already* being used by the packagers > for all the supported architectures and OS builds on dozens of > distros. FWIW, the pkgsrc build is currently using the Makefile. I use that to get flashrom on NetBSD-9 amd64 to use with apu2. More importantly, the instructions in the README in flashrom 1.2 do not mention meson and say to use make. Similary, https://www.flashrom.org/Downloads#Installation_from_source does not mention meson. (It also doesn't mention that specifically GNU make is required, vs BSD make, but that's pretty common to omit.) (I'm not claiming that building with meson wouldn't work, but just pointing out that "all packaging system builds use meson" is incorrect.) So if there is any talk of removing makefiles, there needs to be a release with formal support for meson including it being the standard approach in REAMDE and a deprecation warning. signature.asc Description: PGP signature ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Release preparations
On Mon, 21 Mar 2022 at 20:04, Nico Huber wrote: > There is also one big general issue: we need to maintain two build > systems now. We can't use GNU make only, because nobody knows what > the requirements of the Meson users are. My vote would be to remove the *Makefile*, and move 100% to Meson -- the modern build-system that's *already* being used by the packagers for all the supported architectures and OS builds on dozens of distros. Richard ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Questions regarding Easy project and GSoC
Hi Simon, I got my hardware yesterday and I played around with it and flashrom. I also studied the code flow for the erase functions. I saw that flashrom tries different erase functions given in the flashctx->chip->block_erasers[] by iterating through the list. Assuming these functions are in order of the length (number of sectors) they erase, the first one would get selected most of the time as it erases the smallest length. But this would be inefficient as the function which erases more length would do the job faster although it might not give the required granularity. A better approach could be to use the latter (if necessary) until the remaining length is less than the length that this function can erase. Aarya On Wed, Mar 16, 2022 at 4:45 PM Buhrow, Simon wrote: > Hi Aarya, > > > > nice progress! > > > > I´m writing having "optimizing erase-function" in mint. However the > following might apply fully or in parts to the other topic(s) as well: > > > > As written to Hui Xiang: > > As it´s never a good idea to experiment with the workhorse itself, I would > recommend to do tests on extra hardware. (There might be some things you > can test with software dummies, someone else must tell you about that). A > very cheap programmer often mentioned here is the CH341A Programmer, > however there are many other affordable programmers with ftdi chips, the > raspberry pi and other manufactures as well ( > https://www.flashrom.org/Supported_programmers). > > In addition you would need any supported Flash in a DIP package or a in > SO-Package plus DIP-adapter. > > There are several examples along the internet using flashrom and a > programmer plus flash or target board with a soldered flash. Just pick any > and start with that. > > > > > > >> Can you suggest some tasks so that I can know more about these projects > > > A question from me: have you tried to build and run flashrom from your > local repo source code? > > > > Building flashrom is a good start. Furthermore possible steps to play a > bit around would be this: > > * Read a good article (e.g. wikipedia) about flash memory technology and > understand why there are “block erase” functions (instead of byte wise > erase). > > * When you have done so and have any supported programmer plus flash at > your hands (see above), take the datasheet of the flash and explore the > parts about the different erase functions. > > * Then try running erase (parts of or the entire) flash memory. Check (via > debugging/print messages/verbose output) which block erase function is > used. > > * Compare the result with the best theoretical option derived from > datasheet values. (“best” = fastest) > > > > Hope this helps and you´ve got some dollars for the hardware. If anyone > else has some thoughts about making progress without proposing a purchase, > just let Aarya know. > > > > Regards, > > > > Simon > > > > > > *Von:* Anastasia Klimchuk > *Gesendet:* Sonntag, 13. März 2022 07:45 > *An:* flashrom@flashrom.org; Aarya Chaumal > *Betreff:* [flashrom] Re: Questions regarding Easy project and GSoC > > > > Aarya, > > > > Thank you so much for your patches, awesome work! > > > > Don't worry about merging for now. Merging almost never happens > immediately. Reviewers will come back to the patches, check that everything > is fine, all the comments are resolved etc. If everything is alright, > reviewers will approve and then at some point merge. > > It can also happen that you get another iteration of comments: but don't > worry this is a normal process! > > From your side, you always (for now, and for future) need to understand > all the comments, resolve and reply - once this is done, it is the > Reviewer's turn :) > > > > It is very good that you identified two projects that are interesting for > you. You will discuss a project in more detail with someone who plans to be > Mentor for the project. Let me check who that will be. > > Also, if someone who plans to be a Mentor for "optimizing erase-function" > or "fixing endianness issues" is reading this, you can just reply :) What > would be the best next steps for Aarya to prepare? > > > > A question from me: have you tried to build and run flashrom from your > local repo source code? To begin with you can run > > > > flashrom -h > > > > which is help information. It tells you all command line operations and > arguments. It is served by cli_classic.c file. > > So you can read about "erase" operation and then explore the code which > implements it. > > > > Meanwhile, just to check, have you read official resources from gsoc? > These ones: > > Student Guidelines https://google.github.io/gsocguides/student/ > > Rules https://summerofcode.withgoogle.com/rules (especially p.7) > > And timeline https://developers.google.com/open-source/gsoc/timeline > > > > Anastasia. > > > > On Sun, Mar 13, 2022 at 1:44 PM Aarya Chaumal > wrote: > > As suggested, I have been doing some of the easy projects till now and > I have enjoyed it. I have
[flashrom] Re: Release preparations
Hello Richard, On 21.03.22 17:23, Richard Hughes wrote: > On Sun, 13 Mar 2022 at 15:49, Nico Huber wrote: >>> Also I understand Meson already got into v1.2? I thought the next version >>> is based on the previous? >> Yes, but I hope that doesn't mean we can't revert problems :) > > I don't think adding a smiley face makes it any less insulting to the > people that added, and *continue to maintain* the meson feature. sorry if the context offended you. I meant this rather generally: We should be open to discuss such things. In the Meson case, I'd be happy about any solution that avoids accidental use of Meson for releases, i.e. when nobody tested if it's working correctly in a given environ- ment. > >> The `meson.build` made it into v1.2, that is right but turned out to >> cause more trouble than was expected. OS package maintainers quickly >> adopted it without any second thought. > > Have you pondered why that might be? OS package maintainers usually > don't change the way they build packages without a good reason. I assume they got used to configuration systems like autotools/cmake/ Meson and use them by default if the necessary files are around. I consider not using such a system the exception today. > >> And then all their packages had >> issues because the `meson.build` did some things wrong (no version in- >> formation in the binary for instance, no man page in the package, CLI >> options not working). > > Are there any issues outstanding? How should we know? Nobody is taking the time to really test the Meson setup on Meson-supported platforms (except Linux). Or maybe somebody is and doesn't tell us. The issues that were fixed so far were only iden- tified when quirky binaries made it to the end users already. Fixing issues is the easy part, one needs to find them first though. And if that happens too late, it creates unnecessary work for developers and package maintainers. There is also one big general issue: we need to maintain two build systems now. We can't use GNU make only, because nobody knows what the requirements of the Meson users are. And we can't use Meson only, because nobody knows if and how it works on all the platforms suppor- ted by the Makefile. Nico > All this talk of "removing things" > does not give me the warm-and-fuzzies for building things on top of > the flashrom project. ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Release preparations
On Sun, 13 Mar 2022 at 15:49, Nico Huber wrote: > > Also I understand Meson already got into v1.2? I thought the next version > > is based on the previous? > Yes, but I hope that doesn't mean we can't revert problems :) I don't think adding a smiley face makes it any less insulting to the people that added, and *continue to maintain* the meson feature. > The `meson.build` made it into v1.2, that is right but turned out to > cause more trouble than was expected. OS package maintainers quickly > adopted it without any second thought. Have you pondered why that might be? OS package maintainers usually don't change the way they build packages without a good reason. > And then all their packages had > issues because the `meson.build` did some things wrong (no version in- > formation in the binary for instance, no man page in the package, CLI > options not working). Are there any issues outstanding? All this talk of "removing things" does not give me the warm-and-fuzzies for building things on top of the flashrom project. Richard ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Release preparations
Hi, On 21.03.22 10:11, Anastasia Klimchuk wrote: > Thank you for the explanations! Really helpful. > > I am trying to understand the mechanics. > >> This is also why I suggested that we can drop suspicious >> code from a release branch (i.e. we could branch 1.3.x now >> and then delete code on that branch without affecting master). >> Then the freeze might be over really quickly. > > This option would mean all the items from the first list are reverted in > v1.3? in the most extreme scenario, yes. Please note that I don't consider everything on that list as a release blocker. Some things just looked odd and may only need a second look. > And then they, hopefully, all get fixed to the time of v1.4? > (correct me if I am wrong) Hopefully, yes. Not sure what to do if not, I wouldn't like to repeatedly clean up on release branches. Also, some of the items look like something we wouldn't even want on master, e.g. known broken things. > > Then that means on the other end there is an ideal scenario where all the > items from the first list are fixed (on master) and then v1.3 happens? Then we would branch 1.3.x from master and v1.3-rc1 happens. > > And also a scenario in between when some of the items are fixed, but not > all of them? Pretty much, yes, and I'd hope for this. Better to compromise than to wait forever ;) > > Which of these scenarios has minimum time to freeze master, and which one > takes second place? I am asking because I fully agree with you, it seems > just as you said “a very desperate measure”... so I am worried this may > create a drama :\ Given that nobody reacted with "let's do it", it seems very unlikely to me that we will exercise a freeze. Nico ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Release preparations
Thank you for the explanations! Really helpful. I am trying to understand the mechanics. “This is also why I suggested that we can drop suspicious code from a release branch (i.e. we could branch 1.3.x now and then delete code on that branch without affecting master). Then the freeze might be over really quickly.” This option would mean all the items from the first list are reverted in v1.3? And then they, hopefully, all get fixed to the time of v1.4? (correct me if I am wrong) Then that means on the other end there is an ideal scenario where all the items from the first list are fixed (on master) and then v1.3 happens? And also a scenario in between when some of the items are fixed, but not all of them? Which of these scenarios has minimum time to freeze master, and which one takes second place? I am asking because I fully agree with you, it seems just as you said “a very desperate measure”... so I am worried this may create a drama :\ We have already created 5 bugs as “flashrom release blockers” in our internal bug tracker (the only reason they are created in internal one is because flashrom bug tracker is not ready yet). There is no secret info there at all. That’s for all the items that are missing documentation. It is not a hasty activity, we want to help! Release is important. And especially the items which say “missing documentation”, it’s a no-brainer, needs to be fixed. “My latest idea about this is that we could add an option (e.g. `inofficial`) and a whitelist of known working platforms. Such that one would have to literally state they want an inofficial binary to build on a platform with unknown status.” Looks fine, let’s keep it unofficial (if it really is). Let’s just not delete it :) “I can work on that unless someone else wants the task.” Thanks Martin! There is a patch currently for man page: https://review.coreboot.org/c/flashrom/+/62768 But did you mean more than that? On Fri, Mar 18, 2022 at 2:56 AM Nico Huber wrote: > On 13.03.22 16:28, Nico Huber wrote: > > On 13.03.22 08:28, Anastasia Klimchuk wrote: > >>> I suggest that we freeze the master branch for everything that is > neither > >>> a fix nor on the list (or a similar case that I missed) > >> > >> But how can we freeze master… that would mean no one can do any work? > Maybe > >> I am missing something? > > > > No you didn't miss anything :) it would be a very desperate > > measure. However, I see no other solution to make progress > > again without forking or further stalling a release. And > > after 2 years I think the project has waited long enough. > > Sorry folks, I didn't mean to provoke any hasty activity to fix the > listed problems. Rather to push us to talk about what we should fix > before a release and what features we could do without in a release. > If we'd wait for everything to be fixed at snail pace, I fear people > would give up before another release happens (I would). Not to mention > that people will continue to push more controversial patches in the > meantime. > > Nico > ___ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org > -- Anastasia. ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
