On Mon, 2020-08-03 at 18:46 +0200, Petr Vorel wrote: > Hi all, > > ... > > > @Mimi: As I wrote, I'd suggest moving to docker based travis. I can do it once > > > other issues are addressed, if this setup work for your internal travis support > > > as well. See examples .travis.yml [1] [2], builds: [3] [4]. > > > Advantages are more realistic builds for distro maintainers (different libc and > > > libraries versions, you can test old and new distro releases, etc), but maybe > > > that's not what you want/need. > > > Disadvantage is that sometimes docker releases have temporary packaging related > > > issues (first build in [3]; failure in first build [4] is a bug in LTP, corner > > > case, which would be otherwise undiscovered a long time). > > Nice! I definitely want to move to a docker based travis. How should > > we move forward? Should there be a 1.3.1 release now with just the > > few changes in the next branch and include the existing travis branch > > with changes to address Vitaly's comments? I left off the list TPM 2.0 --pcr support, but the kernel code for exporting the sysfs TPM 2.0 pcrs hasn't been upstreamed yet. I guess we should wait for that to be upstreamed or at least queued to be upstreamed. > Yes, that would work for me. Travis changes aren't related to the release > (it just needs to be published in git), let's give users the fixes. Ok. > > Docker based setup shouldn't take long It's all about to find the dependencies > for used distros (I usually keep them in travis/ directory [5] [6]) and agree on the > variants (which distros, how many jobs are still meaningful, which crypto and > TPM libraries, whether use also: clang, non-intel archs and cross-compilation). Great! Mimi
