[Pkg-samba-maint] First tests on 3.2.0-pre2

[Christian Perrier]

Quoting Steve Langasek (vorlon at debian.org):
> On Thu, Mar 06, 2008 at 07:04:08PM +0100, Christian Perrier wrote:
> > Yesterday and today, I did preliminary tests to package 3.0.2-pre2.
> 
> > I used the debian/ directory from branches/experimental (the one used
> > for 3.2.0-pre1 we have in experimental).
> 
> > What I did up to now on patches:
> 
> > documentation.patch
> >  -->deactivated (manpages have been messed up upstream)
> 
> Should be resolved before upload, then; is this noted in a TODO somewhere?

Reported in upstream's BTS. Günther Dreschner promised me that
Karolin will look at the problem (both work for SerNet, IIRC).

> 
> > fhs-newpaths.patch
> >  -->applied upstream (sligthly differently but seems consistent)
> > fhs-filespaths.patch
> >  -->applied upstream (sligthly differently but seems consistent)
> 
> What are the outstanding differences?  We should have a close look at this
> to be sure there are no regressions.

IIRC, formatting issues. But, yes, we certainly need to check more
carefully. I might need help there.

> 
> > fhs-filespaths-debatable.patch
> >  -->much lighter
> >     Most of it have been applied upstream
> >     We still have changes for the location of:
> >     - winbindd_cache.tdb: we use "cachedir", upstream uses "lockdir"
> >                           upstream says this should be persistent
> >                           across reboots
> 
> 'cache' is persistent across reboots.
> 
> >     - secrets.tdb: upstream uses private_dir, we use state_dir: weird?
> 
> Was discussed upstream.  The issue is that in Debian, our "private dir" is
> under /etc/ for historical reasons (/etc/samba/smbpasswd).  Could be
> reconciled by moving private dir to /var/lib, but not an immediate concern.
> 
> >     - printing.tdb: upstream uses lockdir, we use cachedir. upstream
> >                     says it should be persistent across reboots
> >                     ditto for printing/
> 
> Again, 'cache' *is* persistent across reboots.  But printing.tdb should not
> be pruned by the admin either, so it should eventually be moved to lockdir
> per discussions with upstream.
> 
> >     - gpo cache (gpo_fetch.c): upstream uses lockdir, we use cachedir
> >     - idmap_cache.tdb: upstream uses lockdir, we use cachedir
> >                        IIRC, upstream also said that this should
> >                        be preserved across reboots
> 
> Preservation across reboots is the completely wrong standard for the
> lockdir/cachedir split.

Yeah, OK.

Anyway, this has to be looked at much more carefully as I can't
actually compile 3.2.0 without completely disabling
fhs-filespaths-debatable.patch

From my last tests, it seems that much more coding skills than mine
are needed to solve out issues.


> 
> > fhs-assignpaths.patch
> >  -->kept. But changes are now in source/configure and no longer
> >           source/configure.in
> 
> Er, this is completely broken.  You can't edit source/configure, all edits
> *must* be made to source/configure.in; this change is completely overwritten
> later in the autoconf patch.

Well, I wasn't sure there. So, I need help there as well.


> > no_smbmount_symlink.patch
> >  -->dropped as upstream drops smbfs support
> 
> Did we already drop this on the svn trunk?  Where changes have already been
> made in trunk, they should be merged to the experimental branch and
> documented as such (ugh svn), rather than duplicating the changes in two
> places.

Sure. I didn't attempt to merge trunk changes to experimental branch yet

Also in the TODO list

There are also things to adapt in smbpasswd-syslog.patch, by the way....


In short, my current conclusion is that I'll not be able to wort out
these things properly by working on them alone. Too many things there
require much more coding skills than mine and a *real understanding*
of the code.

I need to "passer le relais" (En?) to you to get 3.2.0-pre2 in order,
Steve...

And, yes I know, this is probably bad timing because of the upcoming
Ubuntu release...



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20080307/956d0e19/attachment.pgp