On Tue, 17 May 2016 15:53:34 +0200 "M.B." <tombo...@sina.cn> wrote:
> Am 17.05.2016 um 09:37 schrieb Pallav Agarwal: > > For normal users we wouldn't. But currently, arch-testers need to > > make a judgement call on what to test when a stable-req bug is > > filed. Tests run in src_test are provided by upstream, and does not > > guarantee that a package that has been merged will actually run on > > the system. If the maintainer could add a couple small scripts to > > check basic functionality > > of the merged package, it would make testing for arch testers much > > easier and reliable. > > Let me give an example. Let's say > > app-misc/screenfetch-2.7.7 is the current stable package for > > screenfetch in the portage tree. > > However, on running, it produces an error on the top, along with > > the proper output. > > If screenfetch-3.0.0 happens to fix that error, maintainer can add > > a simple script > > > > if [ "$(screenfetch 2>&1 1>/dev/null)" != "" ] then > > eerror "Still producing error" > > fi > > > > To make sure the build is properly updating the screenfetch > > version, and that > > the bug has in fact been fixed. This is the only way I can see to > > reliabily and automatically test packages that have been merged > > successfully. > > > > ------- > > Regards, > > Pallav > > > > On Mon, May 16, 2016 at 10:08 PM, Luis Ressel <ara...@aixah.de> > > wrote: > >> On Mon, 16 May 2016 18:13:33 +0530 > >> Pallav Agarwal <pallavagarwa...@gmail.com> wrote: > >> > >>> What I'm suggesting is to add a new function post_install_test. > >>> The function will run only if the build is being run for > >>> stabilization (either as a part of automated stabilization, or > >>> manual) which can be controlled by a USE flag. The function would > >>> also require independent dependencies in case it uses external > >>> applications to test the one being built. > >> > >> Could you please elaborate on this? We already have src_test() for > >> automated tests. Why would we want to run additional tests after > >> the package has been merged? > >> > >> -- > >> Regards, > >> Luis Ressel > >> > >> Luis Ressel <ara...@aixah.de> > >> GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD > >> > > > > Good afternoon, > > facilities for running post-install (pre-merge) QA-checks are in > place. Please have a look at portage's misc-functions.sh, > install_qa_check() will reveal the locations where you can find the > installed checks, along with a place for local overrides. Perhaps you > can design something around this? > > With kind regards, > tomboy64 > These tests would be run post-merge, in the normal file system. Mainly for stabilization checks that can be automated, so not a QA-checks qualifier which looks for common problems that can potentially lead to bugs before it is merged to the normal file system. -- Brian Dolbec <dolsen>
pgpX_padjvLLx.pgp
Description: OpenPGP digital signature
