[LTP] LTP Release plans

[LTP] LTP Release plans

[Cyril Hrubis]

Hi!
As usuall we are supposed to produce a release in January. I'm on
vacation starting next week till the new year, so we should start to
prepare for the release once I'm back on the 2. January 2020.

Ideally we should release around 20. January, which leaves us at least
two weeks for the last minute fixes and testing but feel free to start
with the pre-release testing sooner, that will help us to find bugs
sooner and we will have more time for fixes.

As usuall if there are any patches that should included in the release,
just reply to this mail and I will try to review them once I'm back.

And lastly but not least Merry Christmass && Happy New Year to these who
celebrate them.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release plans

[Martin Doucha]

On 12/13/19 1:54 PM, Cyril Hrubis wrote:
> As usuall if there are any patches that should included in the release,
> just reply to this mail and I will try to review them once I'm back.

I'd like to include the fix for SCTP test_1_to_1_initmsg_connect (mostly
a simple API port with minor additions).

I also need some feedback for my proposal to change the test scenario in
fallocate05 (from anyone). I'll need a few days to submit a new patch so
the sooner the better. I'd really like to get the final fallocate05
patch into the new release.

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic

[LTP] LTP Release plans

[Cyril Hrubis]

Hi!
> > As usuall if there are any patches that should included in the release,
> > just reply to this mail and I will try to review them once I'm back.
> 
> I'd like to include the fix for SCTP test_1_to_1_initmsg_connect (mostly
> a simple API port with minor additions).

This has been handled already.

> I also need some feedback for my proposal to change the test scenario in
> fallocate05 (from anyone). I'll need a few days to submit a new patch so
> the sooner the better. I'd really like to get the final fallocate05
> patch into the new release.

Acked by Jan, I will have a look ASAP.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release plans

[Yang Xu]

Hi Cyril
> As usuall if there are any patches that should included in the release,
> just reply to this mail and I will try to review them once I'm back.
> 
> And lastly but not least Merry Christmass && Happy New Year to these who
> celebrate them.
I think capset/capget cleanup should be include this release.
Also, I plan to clean up cap_bound  filecap testcases. If I can figure 
out cap_ambient intention, I will write cases to test it.

Kind Regrads
Yang Xu

[LTP] LTP Release plans

[Cyril Hrubis]

Hi!
> > As usuall if there are any patches that should included in the release,
> > just reply to this mail and I will try to review them once I'm back.
> > 
> > And lastly but not least Merry Christmass && Happy New Year to these who
> > celebrate them.
> I think capset/capget cleanup should be include this release.
> Also, I plan to clean up cap_bound  filecap testcases. If I can figure 
> out cap_ambient intention, I will write cases to test it.

I will have a look at the capset/capget patches if they are clean and
safe enough for the release ASAP.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release plans

[Cyril Hrubis]

Hi!
First of all Happy New Year!

I'm back at patch review and we are getting close to a pre-release
testing freeze.

As I stated before I will have a look at he fallocate05 test and the
capset/capget patches. Is there anything else that should be part of the
release?

Looking at the patch queue we should probably include:

tst_dev_bytes_written: parsing /proc/diskstats instead of sys file
syscalls/userfaultfd01: add hint about unprivileged_userfaultfd

Anything else I should look at?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release plans

[Yang Xu]

Hi Cyril
> Hi!
> First of all Happy New Year!
> 
> I'm back at patch review and we are getting close to a pre-release
> testing freeze.
> 
> As I stated before I will have a look at he fallocate05 test and the
> capset/capget patches. Is there anything else that should be part of the
> release?
> 
> Looking at the patch queue we should probably include:
> 
> tst_dev_bytes_written: parsing /proc/diskstats instead of sys file
> syscalls/userfaultfd01: add hint about unprivileged_userfaultfd
> 
> Anything else I should look at?
Yes. I also sent a pipe test[1]to ltp(it has undefined F_GETPIPE_SZ 
error on old kernel [2]and I will fix it in v2), as below:
syscalls/pipe12: add new test for piep when write bytes > PIPE_BUF

Also, Cypresslin has a pull[3] about syscalls/statx05: add mkfs.ext4 
package version check.

[1]https://patchwork.ozlabs.org/patch/1215360/
[2]https://travis-ci.org/xuyang0410/ltp/jobs/629597516?utm_medium=notification&utm_source=github_status
[3]https://github.com/linux-test-project/ltp/pull/626

Best Regards
Yang Xu
> 

[LTP] LTP Release plans

[Yang Xu]

on 2020/01/07 10:03, Yang Xu wrote:
> 
> 
> Hi Cyril
>> Hi!
>> First of all Happy New Year!
>>
>> I'm back at patch review and we are getting close to a pre-release
>> testing freeze.
>>
>> As I stated before I will have a look at he fallocate05 test and the
>> capset/capget patches. Is there anything else that should be part of the
>> release?
>>
>> Looking at the patch queue we should probably include:
>>
>> tst_dev_bytes_written: parsing /proc/diskstats instead of sys file
>> syscalls/userfaultfd01: add hint about unprivileged_userfaultfd
>>
>> Anything else I should look at?
Also. In December-end, pengfei sent a kconfig patch set to support 
CONFIG_X86_INTEL_UMIP|CONFIG_X86_UMIP=y. CONFIG_X86_INTEL_UMIP=y for 
umip kconfig before and v5.4  mainline kernel. CONFIG_X86_UMIP=y for 
umip kconfig after v5.5 mainline kernel. I think we can include this 
patchset before release if it is ok.

url:
http://lists.linux.it/pipermail/ltp/2019-December/014841.html
> Yes. I also sent a pipe test[1]to ltp(it has undefined F_GETPIPE_SZ 
> error on old kernel [2]and I will fix it in v2), as below:
> syscalls/pipe12: add new test for piep when write bytes > PIPE_BUF
> 
> Also, Cypresslin has a pull[3] about syscalls/statx05: add mkfs.ext4 
> package version check.
> 
> [1]https://patchwork.ozlabs.org/patch/1215360/
> [2]https://travis-ci.org/xuyang0410/ltp/jobs/629597516?utm_medium=notification&utm_source=github_status 
> 
> [3]https://github.com/linux-test-project/ltp/pull/626
> 
> Best Regards
> Yang Xu
>>
> 
> 
> 

[LTP] LTP Release plans

[Cyril Hrubis]

Hi!
> Yes. I also sent a pipe test[1]to ltp(it has undefined F_GETPIPE_SZ 
> error on old kernel [2]and I will fix it in v2), as below:
> syscalls/pipe12: add new test for piep when write bytes > PIPE_BUF

I will have a look.

> Also, Cypresslin has a pull[3] about syscalls/statx05: add mkfs.ext4 
> package version check.

The patch works only on debian, and I do not see a v2 there, so this has
to wait.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release plans

[Petr Vorel]

Hi Cyril,

> Anything else I should look at?
I'd like to have TI-RPC related patch-set

* RFC,1/1] rpc-tirpc: Remove authdes related tests
https://patchwork.ozlabs.org/patch/1216506/
Acked by Li, waiting for Steve (libtirpc maintainer) to be acked.

And if you have time then this one (not that important, fixing
https://github.com/linux-test-project/ltp/pull/628
and adding libntirpc support):
* TI-RPC: enhancements (pkg-config, libntirpc, travis)
https://patchwork.ozlabs.org/project/ltp/list/?series=151849
(first 2 commits are relevant, the others are travis)

Thanks!

Kind regards,
Petr

[LTP] LTP Release plans

[Cyril Hrubis]

Hi!
I've just finished patchwork queue review and I think that we are fine
and that we should freeze the git for anything but bugfixes at this
point.

I will do a bit more pre-release testing, however the results so far
looks good to me.

This is also last call to test the latest git head, if you haven't done
so plese do so now.

Ideally I would like to stick to the plan and do the release on Monday
20. unless there is a major breakage.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release plans

[Li Wang]

Hi,

On Wed, Jan 15, 2020 at 5:15 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> I've just finished patchwork queue review and I think that we are fine
> and that we should freeze the git for anything but bugfixes at this
> point.
>
> I will do a bit more pre-release testing, however the results so far
> looks good to me.
>

FYI:

I did a round of testing against RHEL6/7/8 and upstream kernel, the test
result looks good except only below tiny issues:

- RHEL6 x86_64 (it is a kernel bug that in old distro)
sysctl02 1 TFAIL: /proc/sys/fs/file-max overflows and is set to 0
sysctl02 2 TINFO: trying to set fs.file-max=18446744073709551615
sysctl02 2 TFAIL: /proc/sys/fs/file-max overflows and is set to
18446744073709551615
sysctl02 3 TINFO: trying to set fs.file-max=9223372036854775808
sysctl02 3 TFAIL: /proc/sys/fs/file-max overflows and is set to
9223372036854775808

fallocate04, fallocate05, fsetxattr01, fdatasync03, fgetxattr01 have the
same issue as:
tst_test.c:1278: INFO: Testing on vfat
tst_mkfs.c:90: INFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
mkfs.vfat: unable to open /dev/loop0
tst_mkfs.c:101: BROK: mkfs.vfat:1: tst_test.c failed with 831

- RHEL7.8 x86_64
  copy_file_range02 failed as a known kernel bug

- RHEL7.8 ppc64le (I have confirmed the latest rhel7 kernel has fixed this
bug)
timer_delete01.c:47: FAIL: Aborting test -
timer_create(CLOCK_BOOTTIME_ALARM) failed: ??? (524)
timer_delete01.c:36: INFO: Testing CLOCK_REALTIME_ALARM
timer_delete01.c:47: FAIL: Aborting test -
timer_create(CLOCK_REALTIME_ALARM) failed: ??? (524)
timer_delete01.c:36: INFO: Testing CLOCK_TAI
timer_delete01.c:54: PASS: Timer deleted successfully!

- Upstream kernel-5.5.0-rc5 x86_64/aarch64
system hang at fs_fill, it more like the unstable kernel issue but not LTP

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200116/650951c5/attachment.htm>