Gentoo Archives: gentoo-dev

From: Brian Dolbec <dolsen@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Proposal for changes for the next EAPI version
Date: Tue, 17 May 2016 14:03:22
Message-Id: 20160517070224.58e529e4.dolsen@gentoo.org
In Reply to: Re: [gentoo-dev] Proposal for changes for the next EAPI version by "M.B."
1 On Tue, 17 May 2016 15:53:34 +0200
2 "M.B." <tomboy64@××××.cn> wrote:
3
4 > Am 17.05.2016 um 09:37 schrieb Pallav Agarwal:
5 > > For normal users we wouldn't. But currently, arch-testers need to
6 > > make a judgement call on what to test when a stable-req bug is
7 > > filed. Tests run in src_test are provided by upstream, and does not
8 > > guarantee that a package that has been merged will actually run on
9 > > the system. If the maintainer could add a couple small scripts to
10 > > check basic functionality
11 > > of the merged package, it would make testing for arch testers much
12 > > easier and reliable.
13 > > Let me give an example. Let's say
14 > > app-misc/screenfetch-2.7.7 is the current stable package for
15 > > screenfetch in the portage tree.
16 > > However, on running, it produces an error on the top, along with
17 > > the proper output.
18 > > If screenfetch-3.0.0 happens to fix that error, maintainer can add
19 > > a simple script
20 > >
21 > > if [ "$(screenfetch 2>&1 1>/dev/null)" != "" ] then
22 > > eerror "Still producing error"
23 > > fi
24 > >
25 > > To make sure the build is properly updating the screenfetch
26 > > version, and that
27 > > the bug has in fact been fixed. This is the only way I can see to
28 > > reliabily and automatically test packages that have been merged
29 > > successfully.
30 > >
31 > > -------
32 > > Regards,
33 > > Pallav
34 > >
35 > > On Mon, May 16, 2016 at 10:08 PM, Luis Ressel <aranea@×××××.de>
36 > > wrote:
37 > >> On Mon, 16 May 2016 18:13:33 +0530
38 > >> Pallav Agarwal <pallavagarwal07@×××××.com> wrote:
39 > >>
40 > >>> What I'm suggesting is to add a new function post_install_test.
41 > >>> The function will run only if the build is being run for
42 > >>> stabilization (either as a part of automated stabilization, or
43 > >>> manual) which can be controlled by a USE flag. The function would
44 > >>> also require independent dependencies in case it uses external
45 > >>> applications to test the one being built.
46 > >>
47 > >> Could you please elaborate on this? We already have src_test() for
48 > >> automated tests. Why would we want to run additional tests after
49 > >> the package has been merged?
50 > >>
51 > >> --
52 > >> Regards,
53 > >> Luis Ressel
54 > >>
55 > >> Luis Ressel <aranea@×××××.de>
56 > >> GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD
57 > >>
58 > >
59 >
60 > Good afternoon,
61 >
62 > facilities for running post-install (pre-merge) QA-checks are in
63 > place. Please have a look at portage's misc-functions.sh,
64 > install_qa_check() will reveal the locations where you can find the
65 > installed checks, along with a place for local overrides. Perhaps you
66 > can design something around this?
67 >
68 > With kind regards,
69 > tomboy64
70 >
71
72 These tests would be run post-merge, in the normal file system. Mainly
73 for stabilization checks that can be automated, so not a QA-checks
74 qualifier which looks for common problems that can potentially lead to
75 bugs before it is merged to the normal file system.
76
77 --
78 Brian Dolbec <dolsen>