search for: pipefail

> Hi Rafael, > > Did this discussion ever get a conclusion? I support enabling > pipefail. Fallout for out of tree users should be easy to fix. As we > learned from LLVM tests, almost all tests that start to fail actually > indicate a real problem that was hidden. So far I got some positive feedback, but no strong LGTM from someone in the area :-( > Dmitri > Cheers, Ra...

...ev/llvm-commits and know what's going on. > Also, the commit causing all the new failures might not be as obvious > down the line to someone updating their tree irregularly (which is > probably true for a lot of academic LLVM users, I'm guessing.) > > Just curious, does using pipefail give any information about where in > the pipe the failure actually comes from? Some kind of message would > be useful for debugging purposes, in addition to explaining what's > going on to someone who wasn't watching dev lists and commit messages > carefully. With the external...

We currently don't use pipefail when running test under make check. This has the undesirable property that it is really easy for tests to bitrot. For example, something like llc %s | FileCheck %s will still pass if llc crashes after printing what FileCheck was looking for. It is also easy to break the tests when refactoring. I...

On Wed, Jul 17, 2013 at 9:48 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > Hi Rafael, > > > > Did this discussion ever get a conclusion? I support enabling > > pipefail. Fallout for out of tree users should be easy to fix. As we > > learned from LLVM tests, almost all tests that start to fail actually > > indicate a real problem that was hidden. > > So far I got some positive feedback, but no strong LGTM from someone > in the area :-( >...

On Wed, Jul 17, 2013 at 6:48 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > Hi Rafael, > > > > Did this discussion ever get a conclusion? I support enabling > > pipefail. Fallout for out of tree users should be easy to fix. As we > > learned from LLVM tests, almost all tests that start to fail actually > > indicate a real problem that was hidden. > > So far I got some positive feedback, but no strong LGTM from someone > in the area :-( >...

On Thu, Jul 4, 2013 at 8:56 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > We currently don't use pipefail when running test under make check. > This has the undesirable property that it is really easy for tests to > bitrot. Hi Rafael, Did this discussion ever get a conclusion? I support enabling pipefail. Fallout for out of tree users should be easy to fix. As we learned from LLVM tests, alm...

...e is a strong LGTM. =] > > Please make the change, and do the following things to aid out-of-tree > maintainers: > > 1) Add a flag to lit and an option to configure/make (I don't care about > CMake here as that is much less frequently used for out-of-tree work) to > disable pipefail. > I have just fixed the last failures on windows. I have also added documentation and the support for disabling pipefail in a directory. The one thing I have not implemented yet is the configure change. The reason is that after thinking a bit about it it looks like something we don't want...

...aying attention to LLVMDev/llvm-commits and know what's going on. Also, the commit causing all the new failures might not be as obvious down the line to someone updating their tree irregularly (which is probably true for a lot of academic LLVM users, I'm guessing.) Just curious, does using pipefail give any information about where in the pipe the failure actually comes from? Some kind of message would be useful for debugging purposes, in addition to explaining what's going on to someone who wasn't watching dev lists and commit messages carefully. Anyway, perhaps none of this is as bi...

...ss) the exit code is not exit code of the process of interest (e.g. the ``make`` or ``configure`` invocations). Here's a simple example that illustrates the problem ``` $ false ; echo $? 1 false | tee /dev/null ; echo $? 0 ``` In addition to doing ``set -e`` what we also need to do ``set -o pipefail`` in the ``test-release.sh`` script. ``` $ set -o pipefail $ false ; echo $? 1 $ false | tee /dev/null ; echo $? 1 ``` Is it okay for me to commit a fix for this to trunk? @Ben: Could you add a line just after ``set -e`` in your copy of ``test-release.sh`` that runs ``set -o pipefail`` and try...

On 5 July 2013 00:15, Stephen Lin <swlin at post.harvard.edu> wrote: > Hi Rafael, > > I think you saw my other e-mail, but just in case you haven't, do you > have any thoughts about making this an option that could be easily > disabled on the command line without maintaing a patch to lit? I think > it would help out-of-tree target maintainers to transition, since

...ntaing a patch to lit? I think it would help out-of-tree target maintainers to transition, since I'm sure there will be a lot of similarly broken tests to fix. Stephen On Thu, Jul 4, 2013 at 8:56 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > We currently don't use pipefail when running test under make check. > This has the undesirable property that it is really easy for tests to > bitrot. For example, something like > > llc %s | FileCheck %s > > will still pass if llc crashes after printing what FileCheck was > looking for. It is also easy to bre...

I just committed a change (r187261) to use pipefail when running the regression tests. This means that tests that use pipes like opt .... | FileCheck will now fail if opt fails. This would have avoid some test bitrot in the past. For example, we had tests doing opt -S ... | not grep ... and they were still passing even after the the test itself...

...ent. > > It's currently building for FreeBSD 10.x i386 and amd64. Hm, strangely enough, this version of the script does not go further than the Phase 2 installation, and does not run any tests? This used to work fine for the release_36 branch. I think it is because of the "set -o pipefail" which was introduced, but I don't yet understand why this causes the Phase 2 installation to appear to fail, as there is no visible error. I will investigate, or work around it by removing the pipefail option again. -Dimitry -------------- next part -------------- A non-text attachment...

> Ben reports that he didn't get a tarball even after the rpath fix and > had to disable -o pipefail to get one. Still not sure what caused > this. 'make check' failures can cause this. I had to revert r241599 to get a package. > Appendix: compiler-rt test failures > =================================== > Just to add Mips to this: On big-endian Mips32r2: AddressSa...

...cfe-dev] [3.7 Release] RC1 has been tagged, Testing Phase I > begins > > On Wed, Jul 22, 2015 at 7:03 AM, Daniel Sanders > <Daniel.Sanders at imgtec.com> wrote: > >> Ben reports that he didn't get a tarball even after the rpath fix and > >> had to disable -o pipefail to get one. Still not sure what caused > >> this. > > > > 'make check' failures can cause this. I had to revert r241599 to get a > package. > > Oh, I'm silly. Some part of my brain assumed "make -k" would not just > "keep going" but...

On Wed, Jul 22, 2015 at 7:03 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: >> Ben reports that he didn't get a tarball even after the rpath fix and >> had to disable -o pipefail to get one. Still not sure what caused >> this. > > 'make check' failures can cause this. I had to revert r241599 to get a package. Oh, I'm silly. Some part of my brain assumed "make -k" would not just "keep going" but also ignore errors. That's not...

...ndric <dimitry at andric.com> wrote: > ... >> Hm, strangely enough, this version of the script does not go further than the Phase 2 installation, and does not run any tests? This used to work fine for the release_36 branch. >> >> I think it is because of the "set -o pipefail" which was introduced, but I don't yet understand why this causes the Phase 2 installation to appear to fail, as there is no visible error. I will investigate, or work around it by removing the pipefail option again. > > It appears to be caused by the clean_RPATH() function, which h...

...the output of guestfish -- for example, fish/test-edit.sh (it is not the only one). I guess you could turn this test to do the same, which could be also easier to expand if there will be added more commands that output things different than "true". > +(( PIPESTATUS[0] == 0 )) set -o pipefail (which is bash-specific) -- Pino Toscano

Hi, I havea minor suggestion for http://llvm.org/docs/TestingGuide.html: Under 'Requirements', might be worth mentioning that running the basic llvm/clang regression tests (check-all) requires a version of bash that supports pipefail, i.e. bash 3.0+. On older system where /bin/sh is too old, one simply needs to hack LitConfig.py to point to /somewhere/else/bash that meets this requirement. (This method has been tested on powerpc-darwin8.) Thanks! Fang -- David Fang http://www.csl.cornell.edu/~fang/

So this morning at 4am I was awoken to my mail clients getting certificate errors for an expired certificate. I hopped on to the server and checked and? no, the LE certs renewed last month and are valid until November. After some moments of confusion I noticed that dovecot had been running since before the renewal, so I did a quick service dovecot restart which fixed everything. Should dovecot