[ANNOUNCE] util-linux-ng

[ANNOUNCE] util-linux-ng

[Karel Zak]

 I'm pleased to announce a new "util-linux-ng" project. This project
 is a fork of the original util-linux (2.13-pre7). 

 The goal of the project is to move util-linux code back to useful state, sync
 with actual distributions and kernel and make development more transparent end
 open.

 The short term goals (for 2.13 release):

	- remove all NFS code from util-linux-ng 
          (/sbin/mount.nfs from nfs-utils is replacement)
	- remove FS/device detection code
          (libblkid from e2fsprogs or libvolumeid is replacement)
	- move as much as possible patches from distributions to upstream

 Mailing list:
   http://vger.kernel.org/vger-lists.html#util-linux-ng

 FTP:
   ftp://ftp.kernel.org/pub/scm/utils/util-linux-ng/

 GIT:
   git clone git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git util-linux-ng

   [Note, GIT repo contains previous 47 versions of util-linux.]

        
 The mailing list or my private e-mail are open for your patches, ideas and
 suggestion. The mailing list is also place where you can help us review
 patches.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: [ANNOUNCE] util-linux-ng

[Ian Kent]

On Mon, 2006-12-18 at 08:52 +0100, Karel Zak wrote:
> 
>  I'm pleased to announce a new "util-linux-ng" project. This project
>  is a fork of the original util-linux (2.13-pre7). 

Perhaps forwarding this to fs-devel would be good also.

> 
>  The goal of the project is to move util-linux code back to useful state, sync
>  with actual distributions and kernel and make development more transparent end
>  open.
> 
>  The short term goals (for 2.13 release):
> 
> 	- remove all NFS code from util-linux-ng 
>           (/sbin/mount.nfs from nfs-utils is replacement)
> 	- remove FS/device detection code
>           (libblkid from e2fsprogs or libvolumeid is replacement)
> 	- move as much as possible patches from distributions to upstream
> 
>  Mailing list:
>    http://vger.kernel.org/vger-lists.html#util-linux-ng
> 
>  FTP:
>    ftp://ftp.kernel.org/pub/scm/utils/util-linux-ng/
> 
>  GIT:
>    git clone git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git util-linux-ng
> 
>    [Note, GIT repo contains previous 47 versions of util-linux.]
> 
>         
>  The mailing list or my private e-mail are open for your patches, ideas and
>  suggestion. The mailing list is also place where you can help us review
>  patches.
> 
>     Karel
> 

Re: [ANNOUNCE] util-linux-ng

[Karel Zak]

On Mon, Dec 18, 2006 at 05:35:29PM +0900, Ian Kent wrote:
> On Mon, 2006-12-18 at 08:52 +0100, Karel Zak wrote:
> > 
> >  I'm pleased to announce a new "util-linux-ng" project. This project
> >  is a fork of the original util-linux (2.13-pre7). 
> 
> Perhaps forwarding this to fs-devel would be good also.

 Fixed.

   Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: [ANNOUNCE] util-linux-ng

[Arkadiusz Miskiewicz]

On Monday 18 December 2006 08:52, Karel Zak wrote:
>  I'm pleased to announce a new "util-linux-ng" project. This project
>  is a fork of the original util-linux (2.13-pre7).

Fork? Are you saying that you just didn't take over maintainership and now we 
will have two versions of util-linux!? :/

>     Karel

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

util-linux: orphan

[Karel Zak]

 It really seems that util-linux project is in a bad condition:

  * the latest *major* stable release: 05-Mar-2004 (util-linux-2.12a)
  * the latest *minor* stable release: 23-Sep-2005 (util-linux-2.12r)
  * the latest unstable release:       05-Mar-2006 (util-linux-2.13-pre7)
  * missing source code repository
  * missing web page
  * maintainer (Adrian Bunk) completely ignores mails about this package
  * source code doesn't follow linux kernel, because there isn't any
    development
  * contributors are sending their patches to distributions rather than 
    to upstream
  * Red Hat (FC6) has 75 patches for this package (!)
  * Novell has (OpenSuse 10.2) 53 patches for this package (!)
 

 I'm Red Hat util-linux maintainer (for 2 years) and I'd like to
 change this bad situation. Yes.. I'd like to help. I've already
 talked with Peter Anvin about git repository for this project at
 kernel.org. Also I have feedback from Novell that they agree that the
 current situation is bad and they want to contribute future
 development.

 My plan:
 
  * create git repo (stable and unstable branches) at kernel.org
  * create some web page with basic pkg description, TODO, changelogs
  * open util-linux development for more people 
  * merge importantpatches from distros to the upstream code and
    release 2.13 as stable
  * prepare plans for future development:
      - don't maintain duplicate code and use libblkid/libvolumeid only
      - completely remove NFS code (we have nfs-utils and
        /sbin/mount.nfs)
      - write modular libmount and use it in other projects (am-utils,
        autofs, mount.cif, mount.nfs, ...)
      - ???

 I've originally thought about util-linux upstream fork, but as
 usually an fork is bad step. So.. I'd like to start some discussion
 before this step. Maybe Adrian will be realistic and he will leave
 the project and invest all his time to kernel only.


    Karel
	
-- 
 Karel Zak  <kzak@redhat.com>

Re: util-linux: orphan

[H. Peter Anvin]

Karel Zak wrote:
> 
>  I've originally thought about util-linux upstream fork, but as
>  usually an fork is bad step. So.. I'd like to start some discussion
>  before this step. Maybe Adrian will be realistic and he will leave
>  the project and invest all his time to kernel only.
> 

Actually, forking is not really that bad of an idea.  When I took over 
tftp, for example, I just did it and called it tftp-hpa.  It didn't take 
very long before I got a message from the netkit maintainer asking if I 
was planning to continue, and if so if he could drop tftp from netkit.

A similar thing happened when Jeremy (and now Ian) took over autofs from me.

Forking gets your new maintainership proven *before* you end up taking 
over.  On the other hand, magicfilter effectively died when I handed it 
over to someone who didn't do a good job with it.

	-hpa

Re: util-linux: orphan

[Pádraig Brady]

Karel Zak wrote:
>  It really seems that util-linux project is in a bad condition:

Here here. I mentioned this a few months back to no avail:
http://lkml.org/lkml/2006/6/27/310

Adrian can you please hand over maintainership ASAP.

thanks,
Pádraig.

p.s. I included util-linux as a bad example
in an OSS openness metric I was thinking about:
http://www.pixelbeat.org/docs/oss_project_quality.html

Re: util-linux: orphan

[Karel Zak]

 Hello,

 after few weeks I'm pleased to announce a new "util-linux-ng" project. This
 project is a fork of the original util-linux (2.13-pre7). 

 The goal of the project is to move util-linux code back to useful state, sync
 with actual distributions and kernel and make development more transparent end
 open.

 The short term goals (for 2.13 release):

	- remove all NFS code from util-linux-ng 
          (/sbin/mount.nfs from nfs-utils is replacement)
	- remove FS/device detection code
          (libblkid from e2fsprogs or libvolumeid is replacement)
	- move as much as possible patches from distributions to upstream

 Mailing list:
   http://vger.kernel.org/vger-lists.html#util-linux-ng

 FTP:
   ftp://ftp.kernel.org/pub/scm/utils/util-linux-ng/

 GIT:
   git clone git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git util-linux-ng

   [Note, GIT repo contains previous 47 versions of util-linux.]

        
 The mailing list or my private e-mail are open for your patches, ideas and
 suggestion. The mailing list is also place where you can help us review
 patches.

 Thanks mostly to Ian Kent, P.H. Anvin. Well, and thanks to Adrian
 Bunk for his previous work on this package.

    Karel


On Thu, Nov 09, 2006 at 11:41:57PM +0100, Karel Zak wrote:
> 
>  It really seems that util-linux project is in a bad condition:
> 
>   * the latest *major* stable release: 05-Mar-2004 (util-linux-2.12a)
>   * the latest *minor* stable release: 23-Sep-2005 (util-linux-2.12r)
>   * the latest unstable release:       05-Mar-2006 (util-linux-2.13-pre7)
>   * missing source code repository
>   * missing web page
>   * maintainer (Adrian Bunk) completely ignores mails about this package
>   * source code doesn't follow linux kernel, because there isn't any
>     development
>   * contributors are sending their patches to distributions rather than 
>     to upstream
>   * Red Hat (FC6) has 75 patches for this package (!)
>   * Novell has (OpenSuse 10.2) 53 patches for this package (!)
>  
> 
>  I'm Red Hat util-linux maintainer (for 2 years) and I'd like to
>  change this bad situation. Yes.. I'd like to help. I've already
>  talked with Peter Anvin about git repository for this project at
>  kernel.org. Also I have feedback from Novell that they agree that the
>  current situation is bad and they want to contribute future
>  development.
> 
>  I've originally thought about util-linux upstream fork, but as
>  usually an fork is bad step. So.. I'd like to start some discussion
>  before this step. Maybe Adrian will be realistic and he will leave
>  the project and invest all his time to kernel only.

-- 
 Karel Zak  <kzak@redhat.com>

Re: util-linux: orphan

[Jan Engelhardt]

> after few weeks I'm pleased to announce a new "util-linux-ng" project. This
> project is a fork of the original util-linux (2.13-pre7). 
>
> The goal of the project is to move util-linux code back to useful state, sync
> with actual distributions and kernel and make development more transparent end
> open.

If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
the maintainer, ask if you can take over, including the name.
This smells a lot like the RPM case [ http://lwn.net/Articles/196523/ ]
however, it does not look like anyone is going to call it rpm-ng just
because the original name is owned by the last maintainer.


Regards,
	-`J'
-- 

Re: util-linux: orphan

[Arkadiusz Miskiewicz]

On Monday 18 December 2006 10:33, Jan Engelhardt wrote:
> > after few weeks I'm pleased to announce a new "util-linux-ng" project.
> > This project is a fork of the original util-linux (2.13-pre7).
> >
> > The goal of the project is to move util-linux code back to useful state,
> > sync with actual distributions and kernel and make development more
> > transparent end open.
>
> If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
> the maintainer, ask if you can take over, including the name.
> This smells a lot like the RPM case [ http://lwn.net/Articles/196523/ ]
> however, it does not look like anyone is going to call it rpm-ng just
> because the original name is owned by the last maintainer.

rpm.org case is even worse. Original maintainer still develops rpm - at this 
moment version 4.4.7 at http://wraptastic.org/ (while rpm.org starts from 
older 4.4.2 codebase), there is active mailing list, so we have two running 
projects with the same name which is bad thing and will cause confusion.

I hope that there will be one util-linux and one rpm project.

> Regards,
> 	-`J'

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: util-linux: orphan

[Matthias Koenig]

Jan Engelhardt <jengelh@linux01.gwdg.de> writes:
>> after few weeks I'm pleased to announce a new "util-linux-ng" project. This
>> project is a fork of the original util-linux (2.13-pre7). 
>>
>> The goal of the project is to move util-linux code back to useful state, sync
>> with actual distributions and kernel and make development more transparent end
>> open.
>
> If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
> the maintainer, ask if you can take over, including the name.

Well, there hasn't been any response since about one month. I think the decision
to fork in this situation is reasonable. We all hope that it will be just a 
temporary fork.

Matthias

Re: util-linux: orphan

[Karel Zak]

On Mon, Dec 18, 2006 at 10:33:33AM +0100, Jan Engelhardt wrote:
> 
> > after few weeks I'm pleased to announce a new "util-linux-ng" project. This
> > project is a fork of the original util-linux (2.13-pre7). 
> >
> > The goal of the project is to move util-linux code back to useful state, sync
> > with actual distributions and kernel and make development more transparent end
> > open.
> 
> If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
> the maintainer, ask if you can take over, including the name.

On Mon, Dec 18, 2006 at 10:55:05AM +0100, Arkadiusz Miskiewicz wrote:
> On Monday 18 December 2006 08:52, Karel Zak wrote:
> >  I'm pleased to announce a new "util-linux-ng" project. This project
> >  is a fork of the original util-linux (2.13-pre7).
> 
> Fork? Are you saying that you just didn't take over maintainership and now we 
> will have two versions of util-linux!? :/

 People around util-linux-ng are not so naive ;-)
 
 We spent last month with discussion about a way how (non-)fork this
 project. We made decision that a fork is the right way, because
 Adrian Bunk completely ignores __everyone__ who wants to talk with
 him about utils-linux.

 A fork is nothing attractive, but it's also a way how improve things
 in Open Source world.

 The goal is not only improve source code, but also a way how this
 project is maintained (mailing list, discussion about changes, git,
 transparent development, ...).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: util-linux: orphan

[Arnd Bergmann]

On Monday 18 December 2006 08:17, Karel Zak wrote:
>         - remove FS/device detection code
>           (libblkid from e2fsprogs or libvolumeid is replacement)

I saw that the current Fedora already dynamically links /bin/mount
against /usr/lib/libblkid.so. This obviously does not work if
/usr is a separate partition that needs to be mounted with /bin/mount.
I also had problems with selinux claiming I had no right to access
libblkid, which meant that the root fs could not be remounted r/w.

I'd suggest that you make sure that mount always gets statically linked
against libblkid to avoid these problems.

	Arnd <><

Re: util-linux: orphan

[H. Peter Anvin]

Arnd Bergmann wrote:
> On Monday 18 December 2006 08:17, Karel Zak wrote:
>>         - remove FS/device detection code
>>           (libblkid from e2fsprogs or libvolumeid is replacement)
> 
> I saw that the current Fedora already dynamically links /bin/mount
> against /usr/lib/libblkid.so. This obviously does not work if
> /usr is a separate partition that needs to be mounted with /bin/mount.
> I also had problems with selinux claiming I had no right to access
> libblkid, which meant that the root fs could not be remounted r/w.
> 
> I'd suggest that you make sure that mount always gets statically linked
> against libblkid to avoid these problems.
> 

That's a pretty silly statement.  The real issue is that any library 
needed by binaries in /bin or /sbin should live in /lib, not /usr/lib.

	-hpa

Re: util-linux: orphan

[Arnd Bergmann]

On Wednesday 27 December 2006 04:08, H. Peter Anvin wrote:
> 
> > I'd suggest that you make sure that mount always gets statically linked
> > against libblkid to avoid these problems.
> > 
> 
> That's a pretty silly statement.  The real issue is that any library 
> needed by binaries in /bin or /sbin should live in /lib, not /usr/lib.

Right, this is obviously true in general. I don't understand enough
about selinux (who does?) to be sure what went wrong there on top
of this, but my impression was that I could have solved the problem
if I had been able to remount the root partition, or mount the selinux
file system, which was made impossible by the fact that I had no
permission to access one of the libraries for the mount binary.

The location of the library file was not the problem I had, as that
system doesn't have a separate /usr partition. 

	Arnd <><

Re: util-linux: orphan

[Theodore Tso]

On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote:
> >I saw that the current Fedora already dynamically links /bin/mount
> >against /usr/lib/libblkid.so. This obviously does not work if
> >/usr is a separate partition that needs to be mounted with /bin/mount.
> >I also had problems with selinux claiming I had no right to access
> >libblkid, which meant that the root fs could not be remounted r/w.
> >
> >I'd suggest that you make sure that mount always gets statically linked
> >against libblkid to avoid these problems.
> 
> That's a pretty silly statement.  The real issue is that any library 
> needed by binaries in /bin or /sbin should live in /lib, not /usr/lib.

>From a Debian unstable system:

think:~# ldd /bin/mount
        linux-gate.so.1 =>  (0xffffe000)
        libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000)
        libuuid.so.1 => /lib/libuuid.so.1 (0xb7f20000)
        libc.so.6 => /lib/libc.so.6 (0xb7ddf000)
        libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xb7dcd000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb7db8000)
        libsepol.so.1 => /lib/libsepol.so.1 (0xb7d77000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7d61000)
        /lib/ld-linux.so.2 (0xb7f3f000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7d5d000)

... and in fact the e2fsprogs's configure program normally installs
the critical libraries used by mount, fsck, e2fsck, including the
blkid and uuid libraries, in /lib, not /usr/lib.  If blkid is being
installed in /usr/lib in Fedora, someone must have gone out of their
way to override e2fsprogs' defaults, which are designed to do the
right things by default.  (Basically, because I generally don't trust
the choices made by distributions' packaging engineers, having been
burned more than once.  :-)

							- Ted

Re: util-linux: orphan

[Alessandro Suardi]

On 12/27/06, Theodore Tso <tytso@mit.edu> wrote:
> On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote:
> > >I saw that the current Fedora already dynamically links /bin/mount
> > >against /usr/lib/libblkid.so. This obviously does not work if
> > >/usr is a separate partition that needs to be mounted with /bin/mount.
> > >I also had problems with selinux claiming I had no right to access
> > >libblkid, which meant that the root fs could not be remounted r/w.
> > >
> > >I'd suggest that you make sure that mount always gets statically linked
> > >against libblkid to avoid these problems.
> >
> > That's a pretty silly statement.  The real issue is that any library
> > needed by binaries in /bin or /sbin should live in /lib, not /usr/lib.
>
> From a Debian unstable system:
>
> think:~# ldd /bin/mount
>         linux-gate.so.1 =>  (0xffffe000)
>         libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000)
>         libuuid.so.1 => /lib/libuuid.so.1 (0xb7f20000)
>         libc.so.6 => /lib/libc.so.6 (0xb7ddf000)
>         libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xb7dcd000)
>         libselinux.so.1 => /lib/libselinux.so.1 (0xb7db8000)
>         libsepol.so.1 => /lib/libsepol.so.1 (0xb7d77000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0xb7d61000)
>         /lib/ld-linux.so.2 (0xb7f3f000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb7d5d000)
>
> ... and in fact the e2fsprogs's configure program normally installs
> the critical libraries used by mount, fsck, e2fsck, including the
> blkid and uuid libraries, in /lib, not /usr/lib.  If blkid is being
> installed in /usr/lib in Fedora, someone must have gone out of their
> way to override e2fsprogs' defaults, which are designed to do the
> right things by default.  (Basically, because I generally don't trust
> the choices made by distributions' packaging engineers, having been
> burned more than once.  :-)
>
>                                                         - Ted

FC6-current for i386 has it right:

[root@sandman ~]# rpm -qf /bin/mount
util-linux-2.13-0.45.3.fc6
[root@sandman ~]# ldd /bin/mount
        linux-gate.so.1 =>  (0xb7f63000)
        libblkid.so.1 => /lib/libblkid.so.1 (0x4b607000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x4b601000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x49ce5000)
        libc.so.6 => /lib/libc.so.6 (0x00aec000)
        libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x49cfe000)
        libdl.so.2 => /lib/libdl.so.2 (0x00c54000)
        libsepol.so.1 => /lib/libsepol.so.1 (0x4a603000)
        /lib/ld-linux.so.2 (0x0011d000)

--alessandro

"...when I get it, I _get_ it"

     (Lara Eidemiller)

Re: util-linux: orphan

[Jan Engelhardt]

On Dec 27 2006 12:24, Alessandro Suardi wrote:
> On 12/27/06, Theodore Tso <tytso@mit.edu> wrote:
>> On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote:

>>>> I saw that the current Fedora already dynamically links
>>>> /bin/mount against /usr/lib/libblkid.so. This obviously does not
>>>> work if /usr is a separate partition that needs to be mounted
>>>> /with bin/mount. I also had problems with selinux claiming I had
>>>> no right to access libblkid, which meant that the root fs could
>>>> not be remounted r/w.
>>>> 
>>>> I'd suggest that you make sure that mount always gets statically
>>>> linked against libblkid to avoid these problems.
>>> 
>>> That's a pretty silly statement.  The real issue is that any
>>> library needed by binaries in /bin or /sbin should live in /lib,
>>> not /usr/lib.
>> 
>> From a Debian unstable system:
>> 
>> think:~# ldd /bin/mount
>> libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000)
>
> FC6-current for i386 has it right:
>
> [root@sandman ~]# ldd /bin/mount
> libblkid.so.1 => /lib/libblkid.so.1 (0x4b607000)

And so does openSUSE 10.2:

ichi$ ldd /bin/mount
        libblkid.so.1 => /lib/libblkid.so.1 (0xa7f4f000)

Interestingly enough, SUSE Linux 10.1 i586/x86_64 had it statically
ccg$ ldd /bin/mount
        libc.so.6 => /lib64/libc.so.6 (0x00002b489072e000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
        (that's all folks)

Now what puzzles is that FC6's mapping address is quite 'off' - the
host "think" has it near PAGE_OFFSET (0xc0000000), as does "ichi"
(PAGE_OFFSET=0xb0000000), so what's with "sandman"?

	-`J'
-- 

Re: util-linux: orphan

[Horst H. von Brand]

Fedora rawhide (i686):

$ rpm -qf /bin/mount
util-linux-2.13-0.48.fc7

$ ldd /bin/mount
        linux-gate.so.1 =>  (0x00f9b000)
        libblkid.so.1 => /lib/libblkid.so.1 (0x45dbc000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x45db6000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x43c5c000)
        libc.so.6 => /lib/libc.so.6 (0x430d9000)
        libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x4329c000)
        libdl.so.2 => /lib/libdl.so.2 (0x43255000)
        libsepol.so.1 => /lib/libsepol.so.1 (0x43c8b000)
        /lib/ld-linux.so.2 (0x5e3f7000)

Aurora Corona (SPARC64):

$ rpm -qf /bin/mount
util-linux-2.13-0.44.sparc.al3

$ ldd /bin/mount
        libblkid.so.1 => /lib/libblkid.so.1 (0xf7fbc000)
        libuuid.so.1 => /lib/libuuid.so.1 (0xf7fa8000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xf7f80000)
        libc.so.6 => /lib/libc.so.6 (0xf7e10000)
        libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xf7dfc000)
        libdl.so.2 => /lib/libdl.so.2 (0xf7de4000)
        libsepol.so.1 => /lib/libsepol.so.1 (0xf7d88000)
        /lib/ld-linux.so.2 (0x70000000)

CentOS 4.4 (x86_64):

$ rpm -qf /bin/mount
util-linux-2.12a-16.EL4.20

$ ldd /bin/mount
        libc.so.6 => /lib64/tls/libc.so.6 (0x00000031d6c00000)
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)

All look fine to me.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Re: util-linux: orphan

[Christoph Hellwig]

On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote:
> That's a pretty silly statement.  The real issue is that any library 
> needed by binaries in /bin or /sbin should live in /lib, not /usr/lib.

Well, there's a real treat here - lots of shared libraries mean
mount is rendered unusable when they are not available for some reason.
And there could be lots of reasons for this.  We've seen selinux mislabeling
with a fedoro-ish box in the lab, there is the possibility of unintentional
ABI breaks and so on and so on.

Then again using shared libraries has  big advtantags over duplicating all
the code, so I wouldn't want to say I'm totally against it.  As mount
only needs the various libraries for it's non-core features what about
dlopen()ing those libraries?  That way a messed up system at least has the
bare mount functionality available.

Re: util-linux: orphan

[Chris Adams]

Once upon a time, Arnd Bergmann  <arnd@arndb.de> said:
>I saw that the current Fedora already dynamically links /bin/mount
>against /usr/lib/libblkid.so.

What do you mean by "current" Fedora?  I think the first Fedora version
that linked /bin/mount against libblkid.so was FC4, and FC4, FC5, FC6,
and rawhide all have libblkid.so in /lib.
-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: util-linux: orphan

[Karel Zak]

On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> On Monday 18 December 2006 08:17, Karel Zak wrote:
> >         - remove FS/device detection code
> >           (libblkid from e2fsprogs or libvolumeid is replacement)
> 
> I saw that the current Fedora already dynamically links /bin/mount
> against /usr/lib/libblkid.so. 

 Sorry, but it's nonsense.

 $ grep -r %{_root_libdir}/libblkid.so *

 devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
 FC-1/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
 FC-2/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
 FC-3/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
 FC-4/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
 FC-5/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
 FC-5/e2fsprogs.spec~:%{_root_libdir}/libblkid.so.*
 FC-6/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
 RHEL-4/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
 RHEL-5/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
 
 (where %{_root_libdir} = /lib)

> This obviously does not work if /usr is a separate partition that
> needs to be mounted with /bin/mount.

 Yes, I have /usr on a separate partition for many years :-)

> I'd suggest that you make sure that mount always gets statically linked
> against libblkid to avoid these problems.

 It's dynamically linked in many distributions without a problem.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: util-linux: orphan

[Arnd Bergmann]

On Wednesday 27 December 2006 19:15, Karel Zak wrote:
> 
> On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> > On Monday 18 December 2006 08:17, Karel Zak wrote:
> > >         - remove FS/device detection code
> > >           (libblkid from e2fsprogs or libvolumeid is replacement)
> > 
> > I saw that the current Fedora already dynamically links /bin/mount
> > against /usr/lib/libblkid.so. 
> 
>  Sorry, but it's nonsense.
> 
>  $ grep -r %{_root_libdir}/libblkid.so *
> 
>  devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*

Right, please accept my apologies for spreading confusion about this.
I currently don't have access to the machine that broke, so I could
not check the exact problem, and must have misremembered the bug.

> > This obviously does not work if /usr is a separate partition that
> > needs to be mounted with /bin/mount.
> 
>  Yes, I have /usr on a separate partition for many years :-)
>
> > I'd suggest that you make sure that mount always gets statically linked
> > against libblkid to avoid these problems.
> 
>  It's dynamically linked in many distributions without a problem.

The problem that I saw was because of selinux going wild. Statically linking
would have avoided the problem for me, but I guess this is just one
more reason for me to disable selinux and be done with it.

	Arnd <><

Re: util-linux: orphan

[Karel Zak]

On Wed, Dec 27, 2006 at 07:39:47PM +0100, Arnd Bergmann wrote:
> On Wednesday 27 December 2006 19:15, Karel Zak wrote:
> > 
> > On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> > > On Monday 18 December 2006 08:17, Karel Zak wrote:
> > > >         - remove FS/device detection code
> > > >           (libblkid from e2fsprogs or libvolumeid is replacement)
> > > 
> > > I saw that the current Fedora already dynamically links /bin/mount
> > > against /usr/lib/libblkid.so. 
> > 
> >  Sorry, but it's nonsense.
> > 
> >  $ grep -r %{_root_libdir}/libblkid.so *
> > 
> >  devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
> 
> Right, please accept my apologies for spreading confusion about this.

 No problem ;-)

> I currently don't have access to the machine that broke, so I could
> not check the exact problem, and must have misremembered the bug.
> 
> > > This obviously does not work if /usr is a separate partition that
> > > needs to be mounted with /bin/mount.
> > 
> >  Yes, I have /usr on a separate partition for many years :-)
> >
> > > I'd suggest that you make sure that mount always gets statically linked
> > > against libblkid to avoid these problems.
> > 
> >  It's dynamically linked in many distributions without a problem.
> 
> The problem that I saw was because of selinux going wild. Statically linking

 Yes, I remember the bug (or bugs). Fixed now.

> would have avoided the problem for me, but I guess this is just one
> more reason for me to disable selinux and be done with it.

 Frankly, it wasn't always easy to use SeLinux in previous FC
 releases, but there is huge progress and I think it's much better in
 FC6.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: util-linux: orphan

[Theodore Tso]

On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote:
>  Frankly, it wasn't always easy to use SeLinux in previous FC
>  releases, but there is huge progress and I think it's much better in
>  FC6.

I've never tried SELinux, but at one point there were all sorts of
horror stories that if you enabled SELinux, the moment you installed
any 3rd party software packages, whether it's Oracle or Websphere or
some other commercial application program, the application would break
because of all sorts of SELinux policy violations, and that it
required an SELinux wizard to configure SELinux policy to enable a 3rd
party application to actually work correctly.  Given that I tried
enabling SELinux, witnessed things break spectacularly and with no
hints about how to fix things, I've always had the attitude of "life
is too short to enable SELinux", and so my limited experience is
consistent with all of the horror stories that I've heard.

It sounds like SELinux has gotten better, according to your
description.  Will handle arbitrary 3rd party software without running
wild, or is it still the case that the moment you want anything other
than software that was shipped with the distribution, it's "abandon
all hope, all ye who enter here"?

						- Ted

Re: util-linux: orphan

[Karel Zak]

On Wed, Dec 27, 2006 at 03:42:13PM -0500, Theodore Tso wrote:
> On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote:
> >  Frankly, it wasn't always easy to use SeLinux in previous FC
> >  releases, but there is huge progress and I think it's much better in
> >  FC6.
> 
> I've never tried SELinux, but at one point there were all sorts of
> horror stories that if you enabled SELinux, the moment you installed
> any 3rd party software packages, whether it's Oracle or Websphere or
> some other commercial application program, the application would break
> because of all sorts of SELinux policy violations, and that it
> required an SELinux wizard to configure SELinux policy to enable a 3rd
> party application to actually work correctly.  Given that I tried
> enabling SELinux, witnessed things break spectacularly and with no
> hints about how to fix things, I've always had the attitude of "life
> is too short to enable SELinux", and so my limited experience is

 The level of security is always your choice. The real security is
 pretty expensive and you have to invest your time to make your system
 really safe. IMHO people who provides simple and cheap solutions are
 liars or marketing-agents or both.

 For example for my laptop is it true that "life is too short to
 enable SELinux", but it's probably not true for servers in the bank where
 I have money. (I hope so:-)

> consistent with all of the horror stories that I've heard.
>
> It sounds like SELinux has gotten better, according to your

 I'm really occasional selinux enduser only. So don't ask me for
 details.

> description.  Will handle arbitrary 3rd party software without running
> wild, or is it still the case that the moment you want anything other
> than software that was shipped with the distribution, it's "abandon
> all hope, all ye who enter here"?

 There is possible customization of the existing selinux policy. You
 can generate a new loadable policy module from system audit logs (see
 audit2allow util). In the other words -- your system in the permissive
 mode is monitoring your 3rd party software and from the logs you can
 generate new selinux rules. And when you switch system to the
 enforcing mode the application should be run as expected with your
 new rules.

    Karel 

-- 
 Karel Zak  <kzak@redhat.com>

Re: util-linux: orphan

[H. Peter Anvin]

Karel Zak wrote:
> 
>  For example for my laptop is it true that "life is too short to
>  enable SELinux", but it's probably not true for servers in the bank where
>  I have money. (I hope so:-)
> 

You'd be surprised how many banks run Windows, and not even the most 
recent versions.

	-hpa

Re: util-linux: orphan

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Wed, 27 Dec 2006 23:12:51 +0100, Karel Zak said:
>  For example for my laptop is it true that "life is too short to
>  enable SELinux", but it's probably not true for servers in the bank where
>  I have money. (I hope so:-)

On the other hand, the case can be made that your laptop needs SELinux *more*
than the bank servers - because the bank servers are (presumably) heavily
firewalled and stripped down software-wise, and otherwise hardened.  But
your laptop is exactly one Firefox buffer overflow from being completely pwned...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: util-linux: orphan

[Ian Kent]

On Wed, 27 Dec 2006, Theodore Tso wrote:

> On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote:
> >  Frankly, it wasn't always easy to use SeLinux in previous FC
> >  releases, but there is huge progress and I think it's much better in
> >  FC6.
> 
> I've never tried SELinux, but at one point there were all sorts of
> horror stories that if you enabled SELinux, the moment you installed
> any 3rd party software packages, whether it's Oracle or Websphere or
> some other commercial application program, the application would break
> because of all sorts of SELinux policy violations, and that it
> required an SELinux wizard to configure SELinux policy to enable a 3rd
> party application to actually work correctly.  Given that I tried
> enabling SELinux, witnessed things break spectacularly and with no
> hints about how to fix things, I've always had the attitude of "life
> is too short to enable SELinux", and so my limited experience is
> consistent with all of the horror stories that I've heard.

I see the fine grained security of Selinux as a big problem for third 
party applications.

It's a big job to make the OS work cleanly with it but the fact is that 
many machines need to run significant 3rd party applications. I don't have 
first hand experience but I suspect most vendors have tight enough budgets 
without adding an Selinux developer and customers usually don't have this 
resource either so, by and large, I expect people will just have to 
disable it.

I really don't see any solution to this problem either.
Time will tell.

Ian

Re: [ANNOUNCE] util-linux-ng

[Ian Kent]

On Mon, 18 Dec 2006, Arkadiusz Miskiewicz wrote:

> On Monday 18 December 2006 08:52, Karel Zak wrote:
> >  I'm pleased to announce a new "util-linux-ng" project. This project
> >  is a fork of the original util-linux (2.13-pre7).
> 
> Fork? Are you saying that you just didn't take over maintainership and now we 
> will have two versions of util-linux!? :/
> 

We tried, believe me, but couldn't get agreement (or a response from 
current maintainer).

Ian

Re: [ANNOUNCE] util-linux-ng

[Jens Axboe]

On Mon, Dec 18 2006, Ian Kent wrote:
> On Mon, 18 Dec 2006, Arkadiusz Miskiewicz wrote:
> 
> > On Monday 18 December 2006 08:52, Karel Zak wrote:
> > >  I'm pleased to announce a new "util-linux-ng" project. This project
> > >  is a fork of the original util-linux (2.13-pre7).
> > 
> > Fork? Are you saying that you just didn't take over maintainership and now we 
> > will have two versions of util-linux!? :/
> > 
> 
> We tried, believe me, but couldn't get agreement (or a response from 
> current maintainer).

That's ridiculous. Adrian, why don't you just sign over maintainership
of util-linux, if you don't have time to cater for it? At least answer
emails on the subject, you seem to be busy here on lkml all the time, so
I'm sure you can find 2 minutes to wrap this up.

-- 
Jens Axboe

Re: [ANNOUNCE] util-linux-ng

[Ian Kent]

On Wed, 2006-12-20 at 13:19 +0100, Jens Axboe wrote:
> On Mon, Dec 18 2006, Ian Kent wrote:
> > On Mon, 18 Dec 2006, Arkadiusz Miskiewicz wrote:
> > 
> > > On Monday 18 December 2006 08:52, Karel Zak wrote:
> > > >  I'm pleased to announce a new "util-linux-ng" project. This project
> > > >  is a fork of the original util-linux (2.13-pre7).
> > > 
> > > Fork? Are you saying that you just didn't take over maintainership and now we 
> > > will have two versions of util-linux!? :/
> > > 
> > 
> > We tried, believe me, but couldn't get agreement (or a response from 
> > current maintainer).
> 
> That's ridiculous. Adrian, why don't you just sign over maintainership
> of util-linux, if you don't have time to cater for it? At least answer
> emails on the subject, you seem to be busy here on lkml all the time, so
> I'm sure you can find 2 minutes to wrap this up.
> 

Or even accept the offer of help and co-maintainer ship in the spirit
that was given.

Unfortunately we ended up having to fork.

Ian

Re: util-linux: orphan

[Albert Cahalan]

Karel Zak writes:

> I've originally thought about util-linux upstream fork,
> but as usually an fork is bad step. So.. I'd like to start
> some discussion before this step.
...
> after few weeks I'm pleased to announce a new "util-linux-ng"
> project. This project is a fork of the original util-linux (2.13-pre7).

Aw damn, I missed it again. LKML gets about 300 posts/day. The last
time util-linux was offered, I missed out. Bummer.

Well, how about giving me a chunk of it? I'd like /bin/kill please.
I already ship a nicer one in procps anyway, so you can just delete
the files and call that done. (just today I was working on a Fedora
system and /bin/kill annoyed me)

VERY STRONG SUGGESTION: build a full test suite before you mess with
the source. This isn't some cute toy like xeyes or a silly game.
This is util-linux, which MUST work.

Re: util-linux: orphan

[Jan Engelhardt]

>> I've originally thought about util-linux upstream fork,
>> but as usually an fork is bad step. So.. I'd like to start
>> some discussion before this step.
> ...
>> after few weeks I'm pleased to announce a new "util-linux-ng"
>> project. This project is a fork of the original util-linux (2.13-pre7).
>
> Well, how about giving me a chunk of it? I'd like /bin/kill please.
> I already ship a nicer one in procps anyway, so you can just delete
> the files and call that done. (just today I was working on a Fedora
> system and /bin/kill annoyed me)

How can you ship a "nicer" kill, given that its sole purpose is to accept

  kill { -l | -t | {-s SIGNUM | -SIGNAME } somepid [morepids] }

?

What about merging util-linux and procps?


	-`J'
-- 

Re: util-linux: orphan

[Albert Cahalan]

On 12/20/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
> >> I've originally thought about util-linux upstream fork,
> >> but as usually an fork is bad step. So.. I'd like to start
> >> some discussion before this step.
> > ...
> >> after few weeks I'm pleased to announce a new "util-linux-ng"
> >> project. This project is a fork of the original util-linux (2.13-pre7).
> >
> > Well, how about giving me a chunk of it? I'd like /bin/kill please.
> > I already ship a nicer one in procps anyway, so you can just delete
> > the files and call that done. (just today I was working on a Fedora
> > system and /bin/kill annoyed me)
>
> How can you ship a "nicer" kill, given that its sole purpose is to accept
>
>   kill { -l | -t | {-s SIGNUM | -SIGNAME } somepid [morepids] }
>
> ?

I checked compatibility with Solaris, Tru64, probably a few BSDs,
and man pages of many others.

Fedora Core 5 doesn't seem to like this command:

/bin/kill -l 17 19

(which reminds me, I need to add sigqueue support and
maybe tgkill support)

> What about merging util-linux and procps?

How? Which way?

As I mentioned before, I was twice disappointed in missing
announcements of util-linux maintainership being up for grabs.
I certainly have a track record for keeping things stable.

Prior to me, procps has a history of being abandoned and
broken. Procps is a fork of the long-dead kmem-ps project.
Procps was then passed to someone who added color and
then disappeared. The prior maintainer picked up the old
code again, no doubt under influence of his employer Red Hat.
I rewrote much of it then, but had trouble getting in all of
my changes. Debian started using my code, which slowly
turned into a fork. Maintainership was passed to somebody
else, without even telling me. That person and his immediate
successor added numerous serious bugs. Inexperience with
the code and the lack of a test suite soon led to that group
being bogged down in problems. One by one, the various
Linux distributions switched over to my version of the code.

So as you may imagine, I'd be rather nervous about letting
procps get into that situation again. Bugs are yucky. Having
multiple committers and no testing is a sure path to ruin.

Re: util-linux: orphan

[Jan Engelhardt]

>> What about merging util-linux and procps?
>
> How? Which way?

In that all the following tools (and possibly files) which are
returned by `rpm ql procps` replace the util-linux counterparts, if
any. Note that rpm -ql might return less programs than actually
present in procps, since distributors need to choose which program to
pick from what {util-linux or procps}.

21:07 ichi:~ > rpm -ql procps
/bin/ps
/etc/init.d/boot.sysctl
/etc/sysctl.conf
/etc/xinetd.d/systat
/sbin/sysctl
/usr/bin/free
/usr/bin/pgrep
/usr/bin/pkill
/usr/bin/pmap
/usr/bin/pwdx
/usr/bin/skill
/usr/bin/slabtop
/usr/bin/snice
/usr/bin/tload
/usr/bin/top
/usr/bin/vmstat
/usr/bin/w
/usr/bin/watch
+ the stuff in /usr/share/doc and /usr/share/man

with the idea that you retain maintership over these. So my proposal/idea was
just one of how to package it.

> being bogged down in problems. One by one, the various
> Linux distributions switched over to my version of the code.
>
> So as you may imagine, I'd be rather nervous about letting
> procps get into that situation again. Bugs are yucky. Having
> multiple committers and no testing is a sure path to ruin.

	-`J'
--