[flashrom] Re: libflashrom rust binding
Evan Benn writes: > I think the first question is is the flashrom community happy to have > these bindings live inside the flashrom git repo? They could live in > their own separate repos, but keeping them with flashrom will make > keeping up with libflashrom API changes more straightforward. I am more or less an outsider, but as a packager: I do not want the binding to be hooked into the main build system. Building flashrom is one thing, and I expect that to work pretty much everywhere. Building the rust bindings I expect to be not wanted by everyone who wants flashrom, to have heavier dependencies (rustc is beastly), and to have signficant portability problems. That's all fine, but if in the same release tarball there should be a way to cd to some subdir, and build, expecting that flashrom is already installed and using the installed headers and libs, and expecting a rust compiler. I don't care at all about upstream repo organization if the rust binding is its own release tarball. I'll observe that changes to libflashrom and changes to the bindings may not be connected. Given all of the above, I think it's better to have each language binding be a separate repo with separate release tarballs. 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
Anastasia Klimchuk writes: > I haven’t done any releases before, so tell me if I am wrong. But what I am > thinking when looking at the list of issues: maybe we can have some time > for “just fixing issues on master” and after that do a release branch? Does > it make sense? > “Some time” won’t take forever (AU winter maybe?). I have issue #353 > assigned to me, so now it has to happen :) My $0.02 from dealing with various projects. Flashrom is small and I think it's best to do the release off master, getting everything done that needs to get done, and then beginning the process with feature freeze, moving to regression and doc fixes only, maybe alpha, beta, rc and then release. Only when there is a release create a branch that would be used for micro updates to the release while master is back open for development. In order to make a release it is necessary to say no to further changes. It is always possible to improve, but that leads to never releasing, and users are better served with a series of better releases, as long as each one does not have significant regressions. This is easy to say and hard to do! Creating a release branch before release means changes happen in master disconnected from release and there's backporting effort and a lot more work. Not branching incentivizes everyone to get the release done and hold their feature branches. signature.asc Description: PGP signature ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: One Build System Working Group
Thomas Heijligen writes: > The current policy with the Makefile is to stay backwards compatible. That's fine because make is stable, even the GNU flavor. There really shouldn't be anything in a makefile that is an issue for 5 year old make. The dependency requirements are a different matter, and not different from make to meson. > Since meson is not this long around we have to choose a way to go. > Personally I had the problem that my system meson from a rolling > release distro was to old to build a project from master branch. That's a clue that something is wrong. I would pull a date out of a hat and say that the meson that was the current formal release on 2020-01-01 should be good enough. So that means the build system should work with meson 0.52.1 or higher. Another view is that Ubuntu 20.04's included meson ought to be good enough. With any luck that's at least 0.52.1. signature.asc Description: PGP signature ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: One Build System Working Group
pkgsrc has cmocka 1.1.5. Telling the flashrom package that it is needed for running tests, or that it's always needed is one line in the control Makefile. Including it or downloading it is much more painful. signature.asc Description: PGP signature ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: One Build System Working Group
Some comments from a packager and experience with switching to cmake, some of it ok, some of it bad. I'm trimming stuff I don't have any comments on as I think you have this mostly right. Thomas Heijligen writes: > ## Platforms to support > * Systems > * Linux (Distros / ChromeOS) Long-Term Stable is a real issue. It's not really reasonable for people to expect to build new flashrom with ancient tools, on a system where they have chosen to run old code to get some kind of stability. Yet people routinely demand that they be able to build the latest release of Foo using an LTS with compiler, autoconf, cmake and the like from 5 years ago. They want new Foo, but suggesting they get non-crufty tools and they act like upstream is being unreasonable because their LTS is "supported". My respones is "well, tell RHEL/Ubuntu to do it for you and stop demanding I do it". > * SunOS / Solaris / the current version of it There are two worlds: Oracle Solaris and illumos (OmniOS, OpenIndiana, and more). Probably doesn't need specific code for both, but good to be aware. > * Architectures > * X86 > * ARM > * MIPS > * POWER > x86 supports port I/O (mostly relevant to PCI), others may through > MMIO emulation I guess that's an interesting question. I'm not clear on the full set of interfaces for reading/writing. But really the code should be portable to any reasonable CPU. x86, arm, mips, and ppc are really pairs of CPU architectures, each of which has a 32-bit and a 64-bit variant. And it's a pretty short list; NetBSD also runs on sparc, sparc64, m68k, and less sensible for flashrom, vax, alpha, ia64, and hppa. And, RISC-V is coming and I expect it to appear whereever arm64 does in a few years. In requirements, you left out (but I know you are thinking of cross): cross compilation Almost entirely, switch code on/off by feature tests, and attempt to drive the number of "#ifdef FooOS" to zero. It's not doable entirely, but autoconf got this right and a lot of things that claim they are better do not. > * Write documentation > * Build instructions for all platforms Aside from windows, they really should not be different. > ## Open questions > * System requirements > * How long should we support systems / libraries? > * As long as they have vendor support That's very messy. On one hand if vendors (== "os maintainers") drop support early, it's good to go back slightly further. On the other, if someone decides to freeze code in 2020 and maintain it with *security patches only* for 10 years, then I think a reasonable response is "if you want to run code from 2020 with only security patches, good luck - the license gives you the freedom to do that, but it's not our obligation to do work to make that be easy". Note that such people are welcome to keep running the flashrom version from 2020; that is after all what they chose to do. Yes, I sound cranky, but the crankiness comes from maintaining unison. > * What should be the minimum required version of meson? > * The version of the oldest supported system. Again, same issue. > * Build dependencies > * Can we fetch dependencies like cmocka? This makes building for > some systems easier No, you can't fetch anything at build time. Packaging systems view that as a bug. It means you can't build on a machine not on the internet. Yes, I have built lots of packages on a disconnected machine after fetching their releaes tarballs and transferring on CDROM, and it almost entirely works. So options are: if you want to depend on something, list in in the README and demand that the user have it installed already. If it doesn't already exist as a package in most packaging systems, that's a clue you shouldn't use it. vendor it in. But you really shouldn't do this, because then when there is a security release of that included code, you really need to have a new micro very fast, and I'll pick 7 days out of a hat. > * Shared libflashrom > * How to handle versioning? shared library major/minor is pretty well established (major bump on ABI break, minor bump on ABI addition, and try really hard not to break the ABI). I'm not sure what the question is. > ## Sequence for switching the primary build system > * Meson is feature equivalente with the Makefile > * Switch to meson as default build system, update the documentation > * Make a release with meson as the primary build system, keep the > Makefile for legacy compatible. > * Drop the Makefile > * Drop dead code from Makefile only based option Understand that packagers will need to put in work to switch, they aren't usually paid 40h/week to package, and they don't think flashrom is the most important thing in the world. So what you said means that they have the time between the release with meson documented as primary and the release w/o Makefile. If meson behaves as well as meson proponents say
[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: Gatekeeping, ACLs and Review Rules
> I've noticed something related in reviews over the years, though. Some- > times when reviewers give a lot of comments on Gerrit, among them some > critical ones about the overall patch and a lot of nits, the author > tends to fix the nits and ignore the critical comments. Sure, when > somebody ignores comments and then things get reverted, it's techni- > cally their fault. But I can well imagine that such incidents would > affect future reviews, also for the reviewers. Somehow, everybody > learned that they wasted their time :-/ In formal software engineering culture, there is a notion of findings being major vs minor, where major is failure to meet specification and minor is something else, usually style. I think the basic issue is that flashrom, quite reasonably, is trying to achieve a far higher level of software quality than is typical in open source. It might be reasonable to expect that after a review which had a major finding, to expect it to be re-reviewed before merging. signature.asc Description: PGP signature ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Flashrom Dev Meeting once a month?
Felix Singer writes: > Hi Greg, > > thanks for reaching out :) > > On Thu, 2022-02-03 at 08:11 -0500, Greg Troxel wrote: >> However, if I were, then I would reject anything that requires a >> Google account (or even worse, a facebook account), and also reject >> anything that requires installing proprietary software. > > A Google account for Google Meet is not needed. It depends on the room > settings. So I'm wondering, do you reject Google services in general or > just if an account is needed? That's a bit complicated. I find needing accounts (at ad companies) to be the biggest issue, and then there are lesser issues: Being asked to agree to terms and privacy policy (of google, rather than a separate service with a simple/reasonable policy that only covers that service): I find this objectionable too, and I suspect it would dissuade me from participating about 90% of the time, limiting to the things I really strongly want to participate in. If it's just click and join and no text that tries to claim there is any consent, and the conference itself has a clear privacy policy that prohibits google from retaining the audio and video, it's not so bad. But I don't think people should be asked to grant an advertising company any permission to use or store their image/audio. I don't think Free Software projects should use proprietary tools, if it's possible/reasonable to avoid them. I realize with videoconferencing that's difficult these days, and it's necessary to make project progress. (I also realize I'm an outlier; I originally commented privately and was asked to re-comment onlist.) signature.asc Description: PGP signature ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Flashrom Dev Meeting once a month?
I am just a lurker because I use flashrom to update my apu2 bios, so I am not going to attend anyway (even if it were at a convenient time EST). However, if I were, then I would reject anything that requires a Google account (or even worse, a facebook account), and also reject anything that requires installing proprietary software. I suggest looking at jitsi meet, and there are multiple public servers for it besides meet.jit.si. One is calyx.meet.net. FSF associate members can use the FSF instance. It can be self-hosted pretty easily if you have a GNU/Linux server. I gather there is Big Blue Button too, but I have never tried to use it. signature.asc Description: PGP signature ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: FAILED: apu2e4
Stephen Hladysh writes: > flashrom -w /tmp/apu2_v4.14.0.1.rom -p internal > flashrom v1.2 on FreeBSD 12.2-STABLE (amd64) > flashrom is free software, get the source code at https://flashrom.org I am far from an expert, but: have you previously run flashrom successfully on this device? Other apu2 boxes? I have run flashrom under NetBSD on two apu2 boxes. I did this in March with the then-current BIOS, v4.13.0.6, which worked entirely fine. I am 90% sure it was 1.2, but I might have been running 1.1. One apu2 was bought in 2019, and I think is a 2d4 and the other in 2020, I think 2e4 but it might still be 2d4. I really don't expect 2d4 vs 2e4 to be any different I hope you ordered the BIOS rescue chip when you got your apu2. I did but I have not needed it. It's very cool that such a thing exists. signature.asc Description: PGP signature ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: flashrom on NetBSD 8 and apu2?
Greg Troxel writes a year ago (in March of 2020): > I have a PC Engines apu2d4 running NetBSD 8 (amd64), and would like to > update coreboot/etc. on it. I searched the list (perhaps not well) and > didn't find any reports of success, although I realize things are > generally expected to work so success might well go unreported. > > I am using flashrom 1.1 as built from pkgsrc. > > I was able to read the existing bios without issues as: > flashrom --programmer internal -r 20200301-readflash.rom > > Before I try to write, I am wondering if anyone has successfully done an > apu2 bios update with flashrom under NetBSD 8 amd64? I didn't hear back from anyone, and ended up with a second apu2, that I felt comfortable trying this on before it was in service. Under NetBSD 9, using flashroom 1.2 to update an apu2 was straightforwardly successful. (I had to override the name match just as the instructions say, but that's not related to host os for flashrom.) flashrom -w apu2_v4.13.0.4.rom -p internal:boardmismatch=force I used pcictl /dev/pci0 write -d 24 0x6c 0x580ffe10 to force a cold boot, adapted from FreeBSD instructions. and in the end this was an entirely unexciting experience, for which I am grateful. signature.asc Description: PGP signature ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] flashrom on NetBSD 8 and apu2?
I have a PC Engines apu2d4 running NetBSD 8 (amd64), and would like to update coreboot/etc. on it. I searched the list (perhaps not well) and didn't find any reports of success, although I realize things are generally expected to work so success might well go unreported. I am using flashrom 1.1 as built from pkgsrc. I was able to read the existing bios without issues as: flashrom --programmer internal -r 20200301-readflash.rom Before I try to write, I am wondering if anyone has successfully done an apu2 bios update with flashrom under NetBSD 8 amd64? (I have a debricking adaptor (spi1a) and will prepare a Linux flashing image on USB before trying myself, whether I not a get a report of success.) Thanks, Greg ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
