[ANNOUNCE] autofs 4.1.4 beta1 release

[ANNOUNCE] autofs 4.1.4 beta1 release

[raven]

Hi all,

It's been a long time between releases so there are many changes that need 
testing and so this is labeled a beta so we can test it.

For more information look at the CHANGELOG in the distribution.

There are still a few problems that I'm aware of such as:

- the init script for Debian and Gentoo doesn't handle the reload
   option quite right.
- there seems to be a bug with the selection of the default map
   type when using submounts. I still need to investigate this.

So let me know when you find more and I'll fix`em as quick as I can!

The distribution can be found at the usual place at:

http://www.kernel.org/pub/linux/daemons/autofs/v4

in the tars

autofs-4.1.4_beta1.tar.[gz|bz2]

also there is a tarball called:

autofs-4.1.4-beta1-deb.tar.[gz|bz2]

that can be used to build binary debs (see below).

It is possible to build packages for testing from the distribution. 
I'm not the maintainer of any of these distribution packages so please be 
aware that this is for convenience and testing.

To build an rpm package use:

rpmbuild -tb autofs-4.1.4_beta1.tar.gz

and the binary rpms will end up in the usual location.

To merge the package into Gentoo use:

tar zxf autofs-4.1.4_beta1.tar.gz
cd autofs-4.1.4_beta1/gentoo
export PORTDIR_OVERLAY=`pwd`
ebuild net-fs/autofs/autofs-4.1.4_beta1.ebuild digest
ebuild net-fs/autofs/autofs-4.1.4_beta1.ebuild clean install
ebuild net-fs/autofs/autofs-4.1.4_beta1.ebuild qmerge
unset PORTDIR_OVERLAY

To build binary debs for Debian download the tar refered to above and:

tar zxvf autofs-4.1.4-beta1-deb.tar.gz
dpkg-source -x autofs_4.1.4-beta1-1.dsc
cd autofs-4.1.4-beta1
dpkg-buildpackage -b

and the binary debs will be placed in the directory the tar was unpacked.

Hopefuly this will help with the testing

Ian

Re: [ANNOUNCE] autofs 4.1.4 beta1 release

[Steinar H. Gunderson]

On Wed, Jan 26, 2005 at 10:17:53PM +0800, raven@themaw.net wrote:
> So let me know when you find more and I'll fix`em as quick as I can!

Looks like you missed a patch or two from the Debian archive, at least:

- Quite recently, I uploaded a patch for the debian/event.d script, but this
  is probably not relevant for the upstream distribution.
- There is a patch for rc.autofs.in missing, changing an "else" to en "elif".
  The idea is that failure in loading the autofs4 module should not break
  first-time installation (see http://bugs.debian.org/280276).
- There seem to have been a lot of changes in rc.autofs.in (especially
  related to timeout parsing); I'm unable to follow them all, but I hope
  you've done the right thing in merging in the Debian patches here :-)
- The rc.autofs.in searches for "^automount: ", which breaks if a tab is used
  instead of a space (see http://bugs.debian.org/277320).
- I'm also having a hard time figuring out whether parse_sun.c does the right
  thing wrt. handling whitespace at the end of maps or not; the code looks
  different, at least, but I think it's broken for non-multimaps. Could you
  verify? (Of course, the simplest thing is probably to test :-) )
- I can't see if lookup_file.c handles maps without a trailing newline now
  (Debian patch 051_maps_without_trailing_newline.diff has a hackish fix
  which is obviously not applied, but you might have implemented it
  differently).

Apart from those, it appears like everything else from Debian's 4.1.3 package
is in, at least -- which removes the need for twenty or so local patches :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: [ANNOUNCE] autofs 4.1.4 beta1 release

[raven]

On Wed, 26 Jan 2005, Steinar H. Gunderson wrote:

Cool.

I'll work through this during the beta.

> On Wed, Jan 26, 2005 at 10:17:53PM +0800, raven@themaw.net wrote:
>> So let me know when you find more and I'll fix`em as quick as I can!
>
> Looks like you missed a patch or two from the Debian archive, at least:
>
> - Quite recently, I uploaded a patch for the debian/event.d script, but this
>  is probably not relevant for the upstream distribution.

I'll grab it for my Debian package test build.

> - There is a patch for rc.autofs.in missing, changing an "else" to en "elif".
>  The idea is that failure in loading the autofs4 module should not break
>  first-time installation (see http://bugs.debian.org/280276).

I see.

What if autofs[4] is not compiled as a module?

This might need some more work.

> - There seem to have been a lot of changes in rc.autofs.in (especially
>  related to timeout parsing); I'm unable to follow them all, but I hope
>  you've done the right thing in merging in the Debian patches here :-)

Do you remember what the issues were?

> - The rc.autofs.in searches for "^automount: ", which breaks if a tab is used
>  instead of a space (see http://bugs.debian.org/277320).

Missed that one.

> - I'm also having a hard time figuring out whether parse_sun.c does the right
>  thing wrt. handling whitespace at the end of maps or not; the code looks
>  different, at least, but I think it's broken for non-multimaps. Could you
>  verify? (Of course, the simplest thing is probably to test :-) )

Yep. There's been a bit of work there, not only related to white space.
Please test this out as I need to know what I've broken.

> - I can't see if lookup_file.c handles maps without a trailing newline now
>  (Debian patch 051_maps_without_trailing_newline.diff has a hackish fix
>  which is obviously not applied, but you might have implemented it
>  differently).

I'll check.

Ian

Re: [ANNOUNCE] autofs 4.1.4 beta1 release

[Steinar H. Gunderson]

On Wed, Jan 26, 2005 at 11:35:18PM +0800, raven@themaw.net wrote:
>>- There is a patch for rc.autofs.in missing, changing an "else" to en
>>  "elif".  The idea is that failure in loading the autofs4 module should not
>>  break first-time installation (see http://bugs.debian.org/280276).
> What if autofs[4] is not compiled as a module?

In that case, it is in /proc/filesystems, and there is no problem. You
_could_ argue that is autofs3 was compiled into the kernel, it should fail,
but I can't find a good way to detect that.

>>- There seem to have been a lot of changes in rc.autofs.in (especially
>>  related to timeout parsing); I'm unable to follow them all, but I hope
>>  you've done the right thing in merging in the Debian patches here :-)
> Do you remember what the issues were?

(Just to clear up; "there seems to have been a lot of changes" refers to your
changes, not the Debian changes, although there are several of those as
well.) I'm afraid this was before I took over the maintainership of the
package; the changelog is the best thing I can point you to.

> Yep. There's been a bit of work there, not only related to white space.
> Please test this out as I need to know what I've broken.

OK, I'll give it a shot a bit later. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/

RE: [ANNOUNCE] autofs 4.1.4 beta1 release

[Rigler, Stephen C.]

 

> -----Original Message-----
> From: autofs-bounces@linux.kernel.org 
> [mailto:autofs-bounces@linux.kernel.org] On Behalf Of raven@themaw.net
> Sent: Wednesday, January 26, 2005 9:35 AM
> To: Steinar H. Gunderson
> Cc: autofs@linux.kernel.org
> Subject: Re: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release
> 
> I see.
> 
> What if autofs[4] is not compiled as a module?
> 
> This might need some more work.
> 

Just to contribute to this, on Altix running SGI's variant of RHEL 3,
they compile autofs (3 and 4) into the kernel and not as modules.
We've had problems with automount defaulting to version 3 in this case.
It works fine when compiled as a module.  I opened a case with SGI
asking
them to ship their kernel with it compiled as a module, but I haven't
heard their stance on that yet.

-Steve

Re: [ANNOUNCE] autofs 4.1.4 beta1 release

[Ian Kent]

On Wed, 26 Jan 2005, Steinar H. Gunderson wrote:

> On Wed, Jan 26, 2005 at 11:35:18PM +0800, raven@themaw.net wrote:
> >>- There is a patch for rc.autofs.in missing, changing an "else" to en
> >>  "elif".  The idea is that failure in loading the autofs4 module should not
> >>  break first-time installation (see http://bugs.debian.org/280276).
> > What if autofs[4] is not compiled as a module?
> 
> In that case, it is in /proc/filesystems, and there is no problem. You
> _could_ argue that is autofs3 was compiled into the kernel, it should fail,
> but I can't find a good way to detect that.

Unless I see anything else I'll make the approriate change.

> 
> >>- There seem to have been a lot of changes in rc.autofs.in (especially
> >>  related to timeout parsing); I'm unable to follow them all, but I hope
> >>  you've done the right thing in merging in the Debian patches here :-)
> > Do you remember what the issues were?
> 
> (Just to clear up; "there seems to have been a lot of changes" refers to your
> changes, not the Debian changes, although there are several of those as
> well.) I'm afraid this was before I took over the maintainership of the
> package; the changelog is the best thing I can point you to.

That's right.

The Debian side of things really refers to the merging of patches I 
found in the packages (as best as I could) and some init script changes 
which you are, no doubt checking.

Ian

RE: [ANNOUNCE] autofs 4.1.4 beta1 release

[Ian Kent]

On Wed, 26 Jan 2005, Rigler, Stephen C. wrote:

>  
> 
> > -----Original Message-----
> > From: autofs-bounces@linux.kernel.org 
> > [mailto:autofs-bounces@linux.kernel.org] On Behalf Of raven@themaw.net
> > Sent: Wednesday, January 26, 2005 9:35 AM
> > To: Steinar H. Gunderson
> > Cc: autofs@linux.kernel.org
> > Subject: Re: [autofs] [ANNOUNCE] autofs 4.1.4 beta1 release
> > 
> > I see.
> > 
> > What if autofs[4] is not compiled as a module?
> > 
> > This might need some more work.
> > 
> 
> Just to contribute to this, on Altix running SGI's variant of RHEL 3,
> they compile autofs (3 and 4) into the kernel and not as modules.
> We've had problems with automount defaulting to version 3 in this case.
> It works fine when compiled as a module.  I opened a case with SGI
> asking
> them to ship their kernel with it compiled as a module, but I haven't
> heard their stance on that yet.

Interesting.

Seems to me that having both filesystems compiled in can't work as they 
both attempt to register as "autofs".

So first come first served.
Deselecting autofs would also work of course.

Ian

Re: [ANNOUNCE] autofs 4.1.4 beta1 release

[Steinar H. Gunderson]

(I'm still on the list, no need to Cc me :-) )

On Thu, Jan 27, 2005 at 09:21:10AM +0800, Ian Kent wrote:
> The Debian side of things really refers to the merging of patches I 
> found in the packages (as best as I could) and some init script changes 
> which you are, no doubt checking.

Well, I'm afraid I can't check that you got all the Debian-specific init
script changes right, as I don't really know or understand half the problems
these patches were fixing (and the code they modified seems to have been
mostly rewritten). As long as you actually reviewed the changes, I guess we
should be OK. If there'll be a 4.1.4-beta2 (with the missing patches I
noticed), I'll be happy to put that in experimental and see if people get it
to work properly without regressions. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: [ANNOUNCE] autofs 4.1.4 beta1 release

[raven]

On Thu, 27 Jan 2005, Steinar H. Gunderson wrote:

> (I'm still on the list, no need to Cc me :-) )
>
> On Thu, Jan 27, 2005 at 09:21:10AM +0800, Ian Kent wrote:
>> The Debian side of things really refers to the merging of patches I
>> found in the packages (as best as I could) and some init script changes
>> which you are, no doubt checking.
>
> Well, I'm afraid I can't check that you got all the Debian-specific init
> script changes right, as I don't really know or understand half the problems
> these patches were fixing (and the code they modified seems to have been
> mostly rewritten). As long as you actually reviewed the changes, I guess we
> should be OK. If there'll be a 4.1.4-beta2 (with the missing patches I
> noticed), I'll be happy to put that in experimental and see if people get it
> to work properly without regressions. :-)

I'll put the changes you discussed in.

The main point here is that we really just want a working init script.
The original init script didn't address some problems you were probably
unaware of. Mostly related to master maps with a good number of entries. I 
believe I've delat with much of that within the daemon now so the init 
script is a little simpler and should be OK.

All that really remains then is to ensure that the reported Debian 
problems have also been addressed. Certainly I've tried to include as many 
of the Debian patches as I could, some were catered for in other ways or 
had been applied as part of other patches.

So lets see how we go.

Ian