Arch Linux

Uploaded 2.2.6-11: fixed manpages installation path (was /usr/share/, must be /usr/share/man/)

Uploaded 2.2.6-10: trailing chars removed and usr/sbin moved to usr/bin

@izmntuk: Which files are conflicting with core/filesystem ?

Hello, please add `--sbindir=/usr/bin` to the ./configure line. Packages should not put binaries into `/usr/sbin` since Arch fininshed the usr merge. Otherwise when installing this package with core/filesystem at the same time, pacman will report `error: failed to commit transaction (conflicting files)`[1]
- and, there are some trailing spaces in the PKGBUILD, please remove them :)

1: https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/

Package adopted and added my last suggestion. Any problems, please let me know.

Here is a suggestion of PKGBUILD: mtab patch (as suggested by dresb) and split patches and compilation in 'prepare' and 'build' functions, as recommended in PKGBUILD(5). Also moved /sbin to /usr/sbin.

source tarball: https://dl.dropboxusercontent.com/u/19823921/ncpfs-2.2.6-8.src.tar.gz
PKGBUILD: http://pastie.org/8991449

'sbin' is currently being installed in /sbin, but should be installed in /usr/sbin. In order to fix this, the following command (before the ./configure) will do the job:
sed -i 's/sbin/$(sbindir)/' sutil/Makefile.in

Ah, a light at the end of the tunnel. A contribution for an unsupported software (not the package). Thanks for your contribution. ASAP I'll try your PKGBUILD and patch.

Ever since /etc/mtab has changed to a symlink both ncpmount and ncpumount complain that "Can't get /etc/mtab~ lock file". Debian has made a patch to mitigate this available in ncpfs_2.2.6-9.debian.tar.bz2.

I updated the PKGBUILD and tarball to apply the patch (successfully) at http://pastebin.com/4mu7uUMR and http://www.mediafire.com/download/sibqh37b11i4wrg/ncpfs-2.2.6-8.src.tar.gz

I suppose that the correct prefix for the manpages is /usr/share/man and not just /usr/share anymore

So i'll replace broken 2.2.6-6. And forward to further suggestions

Looks good.

Updated tarball: http://dl.dropbox.com/u/72253941/ncpfs-2.2.6-7.src.tar.gz

OK. And i think it's better to leave $_with_php = 0 by default, yeah?

Indeed

OK. And i think it's better to leave $_with_php = 0 by default, yeah?

Sorry for the delay. The idea of variable "_with_php" is to be 0 or 1, to disable or enable, respectively, build support for php... correct? Case yes, I set this variable to 0, but it still entered inside the IF statement - not what I wanted.

I think you would prefer to change it to "if [ $_with_php -eq 1 ]; then", so if the value is different than 1 will build without php.

and where all gone? )

OK, let's test and discuss this tarball: http://dl.dropbox.com/u/72253941/ncpfs-2.2.6-7.src.tar.gz

Well, so here some updates:
- I made a package with some fixes from debian package (including security) and I think should at least take a look at it.
- Mikioma found a problem with PHP (indeed ./configure looks for php), so are we use it or disable. My last suggestion was to not to disable, add add the correct package names to makedepends+optdepends (just 'php' maybe?).

Hi, i'm maintainer. what's for talking? :)

Well, I guess that php and pam could be in makedepends AND in optdepends. So, everyone would build with php and pam support for their authetication module, but only keep if desired.

So far, I don't need PHP support for this package... but that's just me, of course ;-)

Given jsivak has already fixed it anyway, I believe it's ok to leave it like that until another issue arises.

Do we want PHP support to work in this package? Case yes, we might want to have it in the "makedepends"+"optdepends" (if not exactly mandatory after built) or in "depends" (if mandatory after built). Otherwise, it should be disable in configure to avoid wrong missing dependencies.

The PHP 5.4.X library changed the type name from function_entry to zend_function_entry.

I hacked the PKGBUILD to add this after the "./configure" call:

sed 's/function_entry/zend_function_entry/' -i contrib/php/php_auth_nds.c

I can't compile this package using the default configuration. It fails to build the PHP part with the following messages:
"php_auth_nds.c:1105:1: error: unknown type name 'function_entry'"
and
"php_auth_nds.c:1106:2: error: initializer element is not computable at load time"

The later is repeated many times in different lines of the file. I guess something must have changed in the PHP headers.

I can workaround it by adding "--disable-php" in the "./configure" line of the PKGBUILD file.

Thanks so much for maintaining this package :-)

I notice some issues that could be fixed, so I made a new PKGBUILD, provided in this source tarball: http://dl.dropbox.com/u/19823921/ncpfs-2.2.6-6.src.tar.gz

What I changed:
- Fix libncp symlinks
- By @frankspace, fix /usr/lib/security/pam_ncp_auth.so folder
- Some debian patches obsoletes the ones currently in the package available (except for linux3.0 patch), so I replaced. Also, added security patches from Debian.
- added pam as depends

This package is affected by the /lib -> /usr/lib update. However, it appears to me that it's easy enough to fix by adding the following just before the ./configure line in the pkgbuild:

export ncp_cv_pam_directory='/usr/lib/security'

I also added an explicit mkdir -p $pkgdir/usr/lib/security just out of paranoia. That appears to move /lib/security/pam_ncp_auth.so to /usr/lib/security/pam_ncp_auth.so, thereby allowing the upgrade of glibc.

Also I get the following error message during 'make install':

installing shared modules into /usr/lib/php/modules
cp: cannot create regular file '/usr/lib/php/modules/php_auth_nds.so': Permission denied

Add this just before make to solve the problem:

sed 's#$(moduledir)#$(DESTDIR)/&#' -i contrib/php/build/rules.mk

If It is not only me, this issue can be solved by adding in package() :

rm "$pkgdir"/usr/lib/libncp.so
ln -s libncp.so.2.3.0 "$pkgdir"/usr/lib/libncp.so
ln -s libncp.so.2.3.0 "$pkgdir"/usr/lib/libncp.so.2.3

Weird. It seems that make install creates a invalid symlink "libncp.so -> libncp.so.2.3", as "lincp.so.2.3" doesn't exist, but "libncp.so.2.3.0" exists and is a file. Is it only me?

Ok, thanks!

Here's a version that uses the build() & package() functions, the $srcdir & $pkgdir variables, and most importantly, includes 'install-dev' on line 37 to install the headers built by this package.

http://codepad.org/QRM3Cw75

It does not work for me on 32bit environments (it does on 64bit though). ncpmount complains with a "-330" error.

It seems to be a GCC related bug... I've gone through two Ubuntu bug reports which look like the very same issue I have:
https://bugs.launchpad.net/ubuntu/+source/ncpfs/+bug/328020
https://bugs.launchpad.net/ubuntu/+source/ncpfs/+bug/354555

I've tried to apply the proposed patches, with no luck.

So far, I'm using the binaries extracted from the ".deb" file at http://ftp.de.debian.org/debian/pool/main/n/ncpfs/ncpfs_2.2.6-8_i386.deb

Is there any patch or compilation flag to make it work with the current arch's gcc on 32bit?

I haven't been able to access http://platan.vc.cvut.cz/pub/linux/ncpfs/ncpfs-2.2.6.tar.gz.
Is the site still available/active?

* Moved from [community]