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> |