| Message ID | 20200722114729.4210-1-pvorel@suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [ima-evm-utils] Drop empty NEWS file | expand |
On Wed, 2020-07-22 at 13:47 +0200, Petr Vorel wrote: > Signed-off-by: Petr Vorel <pvorel@suse.cz> > --- > NEWS | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > delete mode 100644 NEWS > > diff --git a/NEWS b/NEWS > deleted file mode 100644 > index e69de29..0000000 Really annoying having to include an empty file, but without it, autoconf fails with: Makefile.am: error: required file './NEWS' not found src/Makefile.am: installing './depcomp' autoreconf: automake failed with exit status: 1 Mimi
Mimi, On Wed, Jul 22, 2020 at 10:27:01AM -0400, Mimi Zohar wrote: > On Wed, 2020-07-22 at 13:47 +0200, Petr Vorel wrote: > > Signed-off-by: Petr Vorel <pvorel@suse.cz> > > --- > > NEWS | 0 > > 1 file changed, 0 insertions(+), 0 deletions(-) > > delete mode 100644 NEWS > > > > diff --git a/NEWS b/NEWS > > deleted file mode 100644 > > index e69de29..0000000 > > Really annoying having to include an empty file, but without it, > autoconf fails with: > > Makefile.am: error: required file './NEWS' not found > src/Makefile.am: installing './depcomp' > autoreconf: automake failed with exit status: 1 Maybe current ChangeLog should be renamed to NEWS? git log is better changelog, and ChangeLog is really condensed and suitable to be NEWS. > > Mimi
Hi Mimi, > On Wed, 2020-07-22 at 13:47 +0200, Petr Vorel wrote: > > Signed-off-by: Petr Vorel <pvorel@suse.cz> > > --- > > NEWS | 0 > > 1 file changed, 0 insertions(+), 0 deletions(-) > > delete mode 100644 NEWS > > diff --git a/NEWS b/NEWS > > deleted file mode 100644 > > index e69de29..0000000 > Really annoying having to include an empty file, but without it, > autoconf fails with: > Makefile.am: error: required file './NEWS' not found > src/Makefile.am: installing './depcomp' > autoreconf: automake failed with exit status: 1 OK, it does not work with the new way. It'd be better to touch the file in autogen.sh and add it into .gitignore, but let's ignore it. I found that when looking at rpmlint errors, I just don't package this file and hope you never start to use it. Kind regards, Petr
Hi, ... > > Really annoying having to include an empty file, but without it, > > autoconf fails with: > > Makefile.am: error: required file './NEWS' not found > > src/Makefile.am: installing './depcomp' > > autoreconf: automake failed with exit status: 1 > Maybe current ChangeLog should be renamed to NEWS? > git log is better changelog, and ChangeLog is really condensed and > suitable to be NEWS. +1, good idea. Kind regards, Petr
On Wed, 2020-07-22 at 16:50 +0200, Petr Vorel wrote: > Hi, > > ... > > > Really annoying having to include an empty file, but without it, > > > autoconf fails with: > > > > Makefile.am: error: required file './NEWS' not found > > > src/Makefile.am: installing './depcomp' > > > autoreconf: automake failed with exit status: 1 > > > Maybe current ChangeLog should be renamed to NEWS? > > > git log is better changelog, and ChangeLog is really condensed and > > suitable to be NEWS. > +1, good idea. Sure, thank you for the suggestion. I'll queue this change and any other change(s) in the "next" branch for a minor release. thanks, Mimi
On Wed, 2020-07-22 at 11:31 -0400, Mimi Zohar wrote: > On Wed, 2020-07-22 at 16:50 +0200, Petr Vorel wrote: > > Hi, > > > > ... > > > > Really annoying having to include an empty file, but without it, > > > > autoconf fails with: > > > > > > Makefile.am: error: required file './NEWS' not found > > > > src/Makefile.am: installing './depcomp' > > > > autoreconf: automake failed with exit status: 1 > > > > > Maybe current ChangeLog should be renamed to NEWS? > > > > > git log is better changelog, and ChangeLog is really condensed and > > > suitable to be NEWS. > > +1, good idea. > > Sure, thank you for the suggestion. I'll queue this change and any > other change(s) in the "next" branch for a minor release. After renaming "ChangeLog" to "NEWS" as discussed, autotools now complains about the missing "ChangeLog" file. automake has a number of flavors[1][2]. The "foreign" flavor, which can be supplied as an option to AM_INIT_AUTOMAKE, doesn't require the NEWS, COPYING, AUTHORS, ChangeLog, or README files to exist. Although renaming the files didn't help, it makes sense. The patch does both - renames ChangeLog and uses the "foreign" option. Mimi [1] https://www.gnu.org/software/automake/manual/automake.html#index-a utomake-options [2] https://autotools.io/automake/options.html
Hi Mimi, ... > After renaming "ChangeLog" to "NEWS" as discussed, autotools now > complains about the missing "ChangeLog" file. > automake has a number of flavors[1][2]. The "foreign" flavor, which > can be supplied as an option to AM_INIT_AUTOMAKE, doesn't require the > NEWS, COPYING, AUTHORS, ChangeLog, or README files to exist. > Although renaming the files didn't help, it makes sense. The patch > does both - renames ChangeLog and uses the "foreign" option. Thanks for fixing it. foreign flavor fits our needs better than gnu. Autotools "features" like this (having strange gnu flavor as the default) explain why people keep introducing new build systems like Meson (which brings other problems). Kind regards, Petr > Mimi > [1] https://www.gnu.org/software/automake/manual/automake.html#index-automake-options > [2] https://autotools.io/automake/options.html
On Thu, 2020-07-23 at 13:54 +0200, Petr Vorel wrote: > Hi Mimi, > > ... > > After renaming "ChangeLog" to "NEWS" as discussed, autotools now > > complains about the missing "ChangeLog" file. > > > automake has a number of flavors[1][2]. The "foreign" flavor, which > > can be supplied as an option to AM_INIT_AUTOMAKE, doesn't require the > > NEWS, COPYING, AUTHORS, ChangeLog, or README files to exist. > > > Although renaming the files didn't help, it makes sense. The patch > > does both - renames ChangeLog and uses the "foreign" option. > > Thanks for fixing it. foreign flavor fits our needs better than gnu. > Autotools "features" like this (having strange gnu flavor as the default) > explain why people keep introducing new build systems like Meson (which brings > other problems). Changing the autotools flavor solved the problem, but I wasn't sure that it was the correct solution. Thank you for validating the flavor change. Mimi
Hi Mimi, ... > > Thanks for fixing it. foreign flavor fits our needs better than gnu. > > Autotools "features" like this (having strange gnu flavor as the default) > > explain why people keep introducing new build systems like Meson (which brings > > other problems). > Changing the autotools flavor solved the problem, but I wasn't sure > that it was the correct solution. Thank you for validating the flavor > change. yw :). BTW could you also merge your .travis.yml from next-testing-travis to next (and preferably also to master)? Even if you have no way to setup automatic mirror to some travis account, it help to run it sometimes or at least before release. Also, having docker based travis setup helps to test build against other distros (we have it in LTP). Kind regards, Petr
Mimi, On Thu, Jul 23, 2020 at 02:29:34PM +0200, Petr Vorel wrote: > Hi Mimi, > > ... > > > Thanks for fixing it. foreign flavor fits our needs better than gnu. > > > Autotools "features" like this (having strange gnu flavor as the default) > > > explain why people keep introducing new build systems like Meson (which brings > > > other problems). > > > Changing the autotools flavor solved the problem, but I wasn't sure > > that it was the correct solution. Thank you for validating the flavor > > change. > yw :). > > BTW could you also merge your .travis.yml from next-testing-travis to next (and > preferably also to master)? Even if you have no way to setup automatic mirror to > some travis account, it help to run it sometimes or at least before release. Also, it's useful to packagers to see that there is tests and how to run them. Thanks, > > Also, having docker based travis setup helps to test build against other distros > (we have it in LTP). > > Kind regards, > Petr
On Thu, 2020-07-23 at 17:04 +0300, Vitaly Chikunov wrote: > Mimi, > > On Thu, Jul 23, 2020 at 02:29:34PM +0200, Petr Vorel wrote: > > Hi Mimi, > > > > ... > > > > Thanks for fixing it. foreign flavor fits our needs better than gnu. > > > > Autotools "features" like this (having strange gnu flavor as the default) > > > > explain why people keep introducing new build systems like Meson (which brings > > > > other problems). > > > > > Changing the autotools flavor solved the problem, but I wasn't sure > > > that it was the correct solution. Thank you for validating the flavor > > > change. > > yw :). > > > > BTW could you also merge your .travis.yml from next-testing-travis to next (and > > preferably also to master)? Even if you have no way to setup automatic mirror to > > some travis account, it help to run it sometimes or at least before release. > > Also, it's useful to packagers to see that there is tests and how to run > them. > > Thanks, > > > > > Also, having docker based travis setup helps to test build against other distros > > (we have it in LTP). The existing travis.yml is a first attempt at using travis. (Hint: help with cleaning it up would be much appreciated.) Should this travis.yml be included now in 1.3.1 or deferred to 1.3.2? Let's sync up on what should be included when. Additional suggestions are welcome. 1.3.1 release (~1 week): - minor fixes Proposed 1.3.2 features (~3 months): - Travis integration - Support providing the TPM 2.0 PCRs as a file (--pcrs option). - Walking the TPM 2.0 event log as the basis for calculating the "boot_aggregate". thanks, Mimi
Hi Mimi, ... > > > Also, having docker based travis setup helps to test build against other distros > > > (we have it in LTP). > The existing travis.yml is a first attempt at using travis. (Hint: > help with cleaning it up would be much appreciated.) Should this > travis.yml be included now in 1.3.1 or deferred to 1.3.2? Let's sync > up on what should be included when. Additional suggestions are > welcome. > 1.3.1 release (~1 week): > - minor fixes > Proposed 1.3.2 features (~3 months): > - Travis integration > - Support providing the TPM 2.0 PCRs as a file (--pcrs option). > - Walking the TPM 2.0 event log as the basis for calculating the > "boot_aggregate". Thank you for sharing your roadmap. I'd vote for sooner include (it's not set in the stone, it can be changed later :)), but up to you. Not sure if I have enough time to significantly help with Travis, I'll try. That docker based testing is nice, because it's a testing on real distro. > thanks, > Mimi Kind regards, Petr
On Thu, 2020-07-23 at 19:05 +0200, Petr Vorel wrote: > Hi Mimi, > > ... > > > > Also, having docker based travis setup helps to test build against other distros > > > > (we have it in LTP). > > > The existing travis.yml is a first attempt at using travis. (Hint: > > help with cleaning it up would be much appreciated.) Should this > > travis.yml be included now in 1.3.1 or deferred to 1.3.2? Let's sync > > up on what should be included when. Additional suggestions are > > welcome. > > > 1.3.1 release (~1 week): > > - minor fixes > > > Proposed 1.3.2 features (~3 months): > > - Travis integration > > - Support providing the TPM 2.0 PCRs as a file (--pcrs option). > > - Walking the TPM 2.0 event log as the basis for calculating the > > "boot_aggregate". > > Thank you for sharing your roadmap. I'd vote for sooner include (it's not set > in the stone, it can be changed later :)), but up to you. > > Not sure if I have enough time to significantly help with Travis, I'll try. > That docker based testing is nice, because it's a testing on real distro. Thanks, Petr. You've provided so much help, support, and guidance already. We know a lot of companies are using the Integrity subsystem. Some are even actively contributing to it. They should realize the more time I need to spend on ima-evm-utils, means the less time I have for reviewing and upstreaming kernel patches. Hopefully they're listening and will step up to helping improve ima-evm-utils as well. I can't be any blunter than that. Let's see what happens. :) Mimi
Hi, > > BTW could you also merge your .travis.yml from next-testing-travis to next (and > > preferably also to master)? Even if you have no way to setup automatic mirror to > > some travis account, it help to run it sometimes or at least before release. > Also, it's useful to packagers to see that there is tests and how to run > them. +1 Kind regards, Petr
diff --git a/NEWS b/NEWS deleted file mode 100644 index e69de29..0000000
Signed-off-by: Petr Vorel <pvorel@suse.cz> --- NEWS | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 NEWS