v2.22-rc2 wish list

v2.22-rc2 wish list

[Karel Zak]

 It would be nice to have:

  - fixed typos in docs, man pages, Release Notes, strings, ...
    (misspell-check)

  - regression tests for fdisk (see for example tests/ts/fdisk/sunlabel),
    it would be really nice to have tests for all labels with all
    basic operations (add, move, remove partitions, ...)

  - try to re-build tarball in your distro

  - test uuidd with systemd

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: v2.22-rc2 wish list

[Sami Kerola]

On Fri, Jul 27, 2012 at 10:10 AM, Karel Zak <kzak@redhat.com> wrote:
>  It would be nice to have:
>
>   - fixed typos in docs, man pages, Release Notes, strings, ...
>     (misspell-check)

I wonder if that could be automated somehow...

>   - regression tests for fdisk (see for example tests/ts/fdisk/sunlabel),
>     it would be really nice to have tests for all labels with all
>     basic operations (add, move, remove partitions, ...)
>
>   - try to re-build tarball in your distro

git clean -xdf
./autogen.sh && ./configure && make distcheck
scp util-linux-2.22.rc1*tar.xz unusual-build-system:

Build on 'unusual-build-system' the util-linux tar ball with

./configure --enable-most-builds

and remember to './tests/run.sh'.

>   - test uuidd with systemd

I think it might be good idea to try to get 'make check' to run
'./tests/run.sh'.

-- 
   Sami Kerola
   http://www.iki.fi/kerolasa/

Re: v2.22-rc2 wish list

[Karel Zak]

On Fri, Jul 27, 2012 at 10:26:24AM +0200, Sami Kerola wrote:
> I think it might be good idea to try to get 'make check' to run
> './tests/run.sh'.

 Maybe, but many of the tests requires root permissions and it's
 designed for developers only. I'd like to avoid situations when the
 tests are executed with root permissions by automatic distro build
 systems etc.

 Maybe we can improve run.sh to be require .git/ in the top level
 sources directory if executed with root permissions.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: v2.22-rc2 wish list

[Bernhard Voelker]

On 07/27/2012 12:31 PM, Karel Zak wrote:
>  Maybe, but many of the tests requires root permissions and it's
>  designed for developers only. I'd like to avoid situations when the
>  tests are executed with root permissions by automatic distro build
>  systems etc.

Why? The more folks run the tests, the more bugs can be reported and fixed.
What's wrong about the tests? And if there's something wrong: shouldn't
they not be made more robust?

E.g. coreutils also has many tests which "require_root", and I think
it's safe to run these tests.

Have a nice day,
Berny

Re: v2.22-rc2 wish list

[Karel Zak]

On Fri, Jul 27, 2012 at 12:47:46PM +0200, Bernhard Voelker wrote:
> On 07/27/2012 12:31 PM, Karel Zak wrote:
> >  Maybe, but many of the tests requires root permissions and it's
> >  designed for developers only. I'd like to avoid situations when the
> >  tests are executed with root permissions by automatic distro build
> >  systems etc.
> 
> Why? The more folks run the tests, the more bugs can be reported and fixed.
> What's wrong about the tests? And if there's something wrong: shouldn't
> they not be made more robust?
> 
> E.g. coreutils also has many tests which "require_root", and I think
> it's safe to run these tests.

Does the tests modify /etc/fstab, mount another filesystems and
initialize scsi_debug, loop and raid devices?

I have experience that some distros and end-users rebuild packages
as superuser. I don't want to be responsible for possible problems on
the target systems.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: v2.22-rc2 wish list

[Bernhard Voelker]

On 07/27/2012 01:15 PM, Karel Zak wrote:
> On Fri, Jul 27, 2012 at 12:47:46PM +0200, Bernhard Voelker wrote:
>> On 07/27/2012 12:31 PM, Karel Zak wrote:
>>>  Maybe, but many of the tests requires root permissions and it's
>>>  designed for developers only. I'd like to avoid situations when the
>>>  tests are executed with root permissions by automatic distro build
>>>  systems etc.
>>
>> Why? The more folks run the tests, the more bugs can be reported and fixed.
>> What's wrong about the tests? And if there's something wrong: shouldn't
>> they not be made more robust?
>>
>> E.g. coreutils also has many tests which "require_root", and I think
>> it's safe to run these tests.
> 
> Does the tests modify /etc/fstab, mount another filesystems and
> initialize scsi_debug, loop and raid devices?

yes, but I don't consider mount/umount as too dangerous - coreutils'
test suite also does it. Some more harmful tests could be guarded by
some special mechanism, e.g. an environment variable.

> I have experience that some distros and end-users rebuild packages
> as superuser.

Building as root is certainly not okay, but prior to packaging UL into a
distro or applying it on a few servers, I expect every admin and
distro maintainer to run 'make check'.

With a proper test suite, we give him/her a basic test to check whether
the software is running as expected in his/her environment. Otherwise,
he doesn't have much chance other than waiting for productive problems.

> I don't want to be responsible for possible problems on
> the target systems.

You aren't:
  $ grep -i warranty COPYING
;-)

Have a nice day,
Berny

Re: v2.22-rc2 wish list

[Davidlohr Bueso]

On Fri, 2012-07-27 at 13:44 +0200, Bernhard Voelker wrote:
> On 07/27/2012 01:15 PM, Karel Zak wrote:
> > On Fri, Jul 27, 2012 at 12:47:46PM +0200, Bernhard Voelker wrote:
> >> On 07/27/2012 12:31 PM, Karel Zak wrote:
> >>>  Maybe, but many of the tests requires root permissions and it's
> >>>  designed for developers only. I'd like to avoid situations when the
> >>>  tests are executed with root permissions by automatic distro build
> >>>  systems etc.
> >>
> >> Why? The more folks run the tests, the more bugs can be reported and fixed.
> >> What's wrong about the tests? And if there's something wrong: shouldn't
> >> they not be made more robust?
> >>
> >> E.g. coreutils also has many tests which "require_root", and I think
> >> it's safe to run these tests.
> > 
> > Does the tests modify /etc/fstab, mount another filesystems and
> > initialize scsi_debug, loop and raid devices?
> 
> yes, but I don't consider mount/umount as too dangerous - coreutils'
> test suite also does it. Some more harmful tests could be guarded by
> some special mechanism, e.g. an environment variable.
> 
> > I have experience that some distros and end-users rebuild packages
> > as superuser.
> 
> Building as root is certainly not okay, but prior to packaging UL into a
> distro or applying it on a few servers, I expect every admin and
> distro maintainer to run 'make check'.
> 
> With a proper test suite, we give him/her a basic test to check whether
> the software is running as expected in his/her environment. Otherwise,
> he doesn't have much chance other than waiting for productive problems.
> 
I partially agree with this. However our test scripts are strictly
regression testing and, of course, that is part of the development
cycle, so end-users have no business dealing with this. For example, we
cannot ask users to rebuild their kernel just to run theses tests (like
scsi_debug module).

> > I don't want to be responsible for possible problems on
> > the target systems.
> 
> You aren't:
>   $ grep -i warranty COPYING
> ;-)
> 
> Have a nice day,
> Berny
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: v2.22-rc2 wish list

[Bruce Dubbs]

Bruce Dubbs wrote:
> Karel Zak wrote:
>> On Fri, Jul 27, 2012 at 10:26:24AM +0200, Sami Kerola wrote:
>>> I think it might be good idea to try to get 'make check' to run
>>> './tests/run.sh'.
>>
>>   Maybe, but many of the tests requires root permissions and it's
>>   designed for developers only. I'd like to avoid situations when the
>>   tests are executed with root permissions by automatic distro build
>>   systems etc.
>>
>>   Maybe we can improve run.sh to be require .git/ in the top level
>>   sources directory if executed with root permissions.
>
> The nature of Linux From Scratch is to build inside chroot as the root
> user.  We encourage, but do not require, our users to run tests for
> mostly confidence reasons.  We discuss test issues on our mailing lists
> to determine if problems are due to user error, our procedures, or
> upstream.  We rarely need to mention issues here.
>
> I encourage you to *not* require .git to run tests as root.

I wish a standard 'reply-to' went to the list by default.  :(

Another item for the wishlist is that /etc/adjtime not be hard coded 
throughout the application.  A configure option would be nice so it is a 
little easier for us to put adjtime in a FHS recommended location 
(/var/lib/hwclock/adjtime).

http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBHWCLOCKSTATEDIRECTORYFORHWCLO

Also, here is a report of a build in the LFS environment.

We will configure  v2.22 with --disable-login --disable-sulogin 
--disable-su because we use the applications from shadow for equivalent 
functionality.

Using gcc 4.7.0 on a P4.  All the following are warnings, but it 
certainly looks a lot more professional to have a clean build.

   -- Bruce

lib/md5.c: In function 'MD5Final':
lib/md5.c:142:5: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]
lib/md5.c:143:5: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]

text-utils/more.c: In function 'main':
text-utils/more.c:322:10: warning: variable 'left' might be clobbered by 
'longjmp' or 'vfork' [-Wclobbered]
text-utils/more.c:323:10: warning: variable 'prnames' might be clobbered 
by 'longjmp' or 'vfork' [-Wclobbered]
text-utils/more.c:324:10: warning: variable 'initopt' might be clobbered 
by 'longjmp' or 'vfork' [-Wclobbered]
text-utils/more.c:325:10: warning: variable 'srchopt' might be clobbered 
by 'longjmp' or 'vfork' [-Wclobbered]
text-utils/more.c:328:11: warning: variable 'initbuf' might be clobbered 
by 'longjmp' or 'vfork' [-Wclobbered]

tests/helpers/test_sysinfo.c: In function 'hlp_wordsize':
tests/helpers/test_sysinfo.c:30:2: warning: format '%lu' expects 
argument of type 'long unsigned int', but argument 2 has type 'unsigned 
int' [-Wformat]

sys-utils/hwclock-cmos.c: In function 'i386_iopl':
sys-utils/hwclock-cmos.c:614:13: warning: redundant redeclaration of 
'iopl' [-Wredundant-decls]
In file included from sys-utils/hwclock-cmos.c:60:0:
/usr/include/sys/io.h:39:12: note: previous declaration of 'iopl' was here

disk-utils/fsck.minix.c: In function 'check_file2':
disk-utils/fsck.minix.c:1049:11: warning: format '%zd' expects argument 
of type 'signed size_t', but argument 2 has type 'long unsigned int' 
[-Wformat]

disk-utils/mkswap.c: In function 'check_blocks':
disk-utils/mkswap.c:322:28: warning: comparison between signed and 
unsigned integer expressions [-Wsign-compare]

fdisks/sfdisk.c: In function 'extended_partition':
fdisks/sfdisk.c:1428:7: warning: format '%ld' expects argument of type 
'long int', but argument 2 has type 'size_t' [-Wformat]
fdisks/sfdisk.c: In function 'bsd_partition':
fdisks/sfdisk.c:1504:6: warning: format '%ld' expects argument of type 
'long int', but argument 2 has type 'size_t' [-Wformat]
fdisks/sfdisk.c: In function 'msdos_partition':
fdisks/sfdisk.c:1554:5: warning: dereferencing type-punned pointer will 
break strict-aliasing rules [-Wstrict-aliasing]
fdisks/sfdisk.c:1556:2: warning: dereferencing type-punned pointer will 
break strict-aliasing rules [-Wstrict-aliasing]

text-utils/pg.c: In function 'pgfile':
text-utils/pg.c:964:21: warning: variable 'fpos' might be clobbered by 
'longjmp' or 'vfork' [-Wclobbered]
text-utils/pg.c:965:18: warning: variable 'fline' might be clobbered by 
'longjmp' or 'vfork' [-Wclobbered]
text-utils/pg.c:965:40: warning: variable 'oldline' might be clobbered 
by 'longjmp' or 'vfork' [-Wclobbered]
text-utils/pg.c:976:6: warning: variable 'search' might be clobbered by 
'longjmp' or 'vfork' [-Wclobbered]
text-utils/pg.c:977:11: warning: variable 'searchcount' might be 
clobbered by 'longjmp' or 'vfork' [-Wclobbered]
text-utils/pg.c:981:6: warning: variable 'seekeof' might be clobbered by 
'longjmp' or 'vfork' [-Wclobbered]
text-utils/pg.c:985:6: warning: variable 'eof' might be clobbered by 
'longjmp' or 'vfork' [-Wclobbered]
text-utils/pg.c:989:6: warning: variable 'nobuf' might be clobbered by 
'longjmp' or 'vfork' [-Wclobbered]
text-utils/pg.c:1000:8: warning: variable 'fbuf' might be clobbered by 
'longjmp' or 'vfork' [-Wclobbered]

term-utils/setterm.c: In function 'screendump':
term-utils/setterm.c:1191:39: warning: comparison between signed and 
unsigned integer expressions [-Wsign-compare]

isc-utils/lslocks.c: In function 'get_dev_inode':
misc-utils/lslocks.c:221:2: warning: format '%lu' expects argument of 
type 'long unsigned int *', but argument 5 has type 'ino_t *' [-Wformat]
misc-utils/lslocks.c: In function 'add_tt_line':
misc-utils/lslocks.c:419:4: warning: format '%ld' expects argument of 
type 'long int', but argument 3 has type 'off_t' [-Wformat]
misc-utils/lslocks.c:422:4: warning: format '%ld' expects argument of 
type 'long int', but argument 3 has type 'off_t' [-Wformat]

Re: v2.22-rc2 wish list

[Karel Zak]

On Fri, Jul 27, 2012 at 03:13:24PM +0200, Davidlohr Bueso wrote:
> > With a proper test suite, we give him/her a basic test to check whether
> > the software is running as expected in his/her environment. Otherwise,
> > he doesn't have much chance other than waiting for productive problems.
> > 
> I partially agree with this. However our test scripts are strictly
> regression testing and, of course, that is part of the development
> cycle, so end-users have no business dealing with this. For example, we
> cannot ask users to rebuild their kernel just to run theses tests (like
> scsi_debug module).

 Exactly, reports from end users like "test XY failed" are completely
 useless if the user is not able to debug the problem.

 Anyway, more tests, and the tests improvements are wanted.

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: v2.22-rc2 wish list

[Karel Zak]

On Fri, Jul 27, 2012 at 01:44:52PM +0200, Bernhard Voelker wrote:
> Building as root is certainly not okay, but prior to packaging UL into a
> distro or applying it on a few servers, I expect every admin and
> distro maintainer to run 'make check'.

I have added tests/run.sh to 'make check' for non-root users. It should
be enough for smart people who do not rebuild their packages as root.

If you want to run all utils-linux tests then you have to

    cd tests && ./run.sh

*manually* as root user.

> With a proper test suite, we give him/her a basic test to check whether
> the software is running as expected in his/her environment. Otherwise,
> he doesn't have much chance other than waiting for productive problems.

I have no problem to enable all the tests by default for all users,
but we need to *review and make robust* the scripts where is
ts_skip_nonroot.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: v2.22-rc2 wish list

[Bernhard Voelker]

On 07/30/2012 06:37 PM, Karel Zak wrote:
> On Fri, Jul 27, 2012 at 01:44:52PM +0200, Bernhard Voelker wrote:
>> Building as root is certainly not okay, but prior to packaging UL into a
>> distro or applying it on a few servers, I expect every admin and
>> distro maintainer to run 'make check'.
> 
> I have added tests/run.sh to 'make check' for non-root users. It should
> be enough for smart people who do not rebuild their packages as root.
> 
> If you want to run all utils-linux tests then you have to
> 
>     cd tests && ./run.sh
> 
> *manually* as root user.

Great, thanks!

Have a nice day,
Berny