tritondatacenter/pkgsrc-wip

Conversion of the pkgsrc-wip CVS project

pkgsrc-wip's Issues

LLVM/Clang 6.0 port

Is there any effort going on to support latest LLVM toolchain?

Few examples:

Fedora: https://src.fedoraproject.org/rpms/clang/blob/master/f/clang.spec
Gentoo: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/clang/clang-6.0.0-r1.ebuild
Windows: https://github.com/Microsoft/vcpkg/blob/master/ports/llvm/portfile.cmake

If there are blockers in LLVM toolchain for Solaris in general (chatted with @jperkin once on IRC), could those be reported upstream for our visibility: http://reviews.llvm.org/?

Folks are literally waiting for it since 2015: https://github.com/dotnet/coreclr/issues/803#issuecomment-164936893

adding ssl support for rsyslogd

It would be nice to have TLS/SSL support for rsyslogd.

A patch for this is here: https://gist.github.com/Licenser/5090345

mongodb manifest file has @SMF_METHOD_FILE@ not expanded

https://github.com/joyent/pkgsrc-wip/blob/joyent/mongodb/files/smf/manifest.xml#L22

Every var is getting replaced but @SMF_METHOD_FILE@ not.

The pkgsrc Makefile doesnt has explicit set SMF_METHOD_FILE, and im not sure what https://github.com/joyent/pkgsrc/blob/joyent/release/trunk/mk/smf.mk#L78 really means, but the builded package that comes with base64 13.3.0, has that problem.

[ Dec 17 19:53:13 Executing start method ("/opt/local/@SMF_METHOD_FILE@ start"). ]
/sbin/sh[1]: exec: /opt/local/@SMF_METHOD_FILE@: not found

Thanks!!

use updated URL for wkhtmltopdf downloads

Hello,

wkhtmltopdf has moved the downloads provider from SourceForge to gna.org. As mentioned in the linked message, all earlier downloads have been removed from SourceForge and you are strongly advised to migrate to the new URLs. The following files in your repository will need to be updated:

• wkhtmltopdf/Makefile

It is recommended to either subscribe to the mailing list or Twitter feed to receive updates on new releases and further changes.

Thanks,
wkhtmltopdf maintainer

GHC build leaks pbulk ar which prevents building subsequent GHC from it

The ar command used to build GHC gets leaked in the built program:

# ghc --info | grep 'ar command'
 ,("ar command","/home/pbulk/build/lang/ghc7/work/.wrapper/bin/ar")

Should be:

# ghc --info | grep 'ar command'
 ,("ar command","ar")

I can't find how these are being created. The only workaround I can think of is putting /home/pbulk/build/lang/ghc7/work/.wrapper/bin/ in the PATH when building GHC and configuring it with --with-ar=ar.

netatalk-3.1 needs a patch to support volumes for timemachine

Jan 30 20:06:36.808575 afpd[23901] {afp_config.c:202} (N:AFPDaemon): Netatalk AFP/TCP listening on 172.16.10.55:548
Jan 30 20:06:36.809413 afpd[23901] {fault.c:123} (S:Default): ===============================================================
Jan 30 20:06:36.809440 afpd[23901] {fault.c:124} (S:Default): INTERNAL ERROR: Signal 11 in pid 23901 (3.1.0)
Jan 30 20:06:36.809490 afpd[23901] {fault.c:125} (S:Default): ===============================================================
Jan 30 20:06:36.809713 afpd[23901] {fault.c:96} (S:Default): PANIC: internal error
Jan 30 20:06:36.809736 afpd[23901] {fault.c:97} (S:Default): BACKTRACE: 12 stack frames:
Jan 30 20:06:36.809754 afpd[23901] {fault.c:103} (S:Default):  #0 /opt/local/lib/libatalk.so.12.0.0'netatalk_panic+0x2d [0xfef2928d]
Jan 30 20:06:36.809779 afpd[23901] {fault.c:103} (S:Default):  #1 /opt/local/lib/libatalk.so.12.0.0'sig_fault+0x47 [0xfef29437]
Jan 30 20:06:36.809797 afpd[23901] {fault.c:103} (S:Default):  #2 /lib/libc.so.1'__sighndlr+0x15 [0xfe7615c5]
Jan 30 20:06:36.809815 afpd[23901] {fault.c:103} (S:Default):  #3 /lib/libc.so.1'call_user_handler+0x292 [0xfe755ff3]
Jan 30 20:06:36.809832 afpd[23901] {fault.c:103} (S:Default):  #4 /lib/libc.so.1'strlen+0xb [0xfe6d1ecb]
Jan 30 20:06:36.809849 afpd[23901] {fault.c:103} (S:Default):  #5 /lib/libc.so.1'vsnprintf+0x78 [0xfe72a048]
Jan 30 20:06:36.809873 afpd[23901] {fault.c:103} (S:Default):  #6 /lib/libc.so.1'vasprintf+0x44 [0xfe7254c4]
Jan 30 20:06:36.809900 afpd[23901] {fault.c:103} (S:Default):  #7 /lib/libc.so.1'asprintf+0x31 [0xfe7255e5]
Jan 30 20:06:36.809922 afpd[23901] {fault.c:103} (S:Default):  #8 /opt/local/sbin/afpd'register_stuff+0xe9 [0x805bf09]
Jan 30 20:06:36.809941 afpd[23901] {fault.c:103} (S:Default):  #9 /opt/local/sbin/afpd'configinit+0x58e [0x8059f2e]
Jan 30 20:06:36.809967 afpd[23901] {fault.c:103} (S:Default):  #10 /opt/local/sbin/afpd'main+0x430 [0x8085910]
Jan 30 20:06:36.809986 afpd[23901] {fault.c:103} (S:Default):  #11 /opt/local/sbin/afpd'_start+0x83 [0x80596f3]
Jan 30 20:06:37.796329 netatalk[23886] {netatalk.c:227} (N:AFPDaemon): Restarting 'afpd' (restarts: 13)

the patch:
http://svnweb.freebsd.org/ports/head/net/netatalk3/files/patch-etc_afpd_afp_mdns.c?revision=340612&view=markup

was found by @konobi

coturn has hardcoded Sun Studio flags for Solaris

remove_sun_studio_dep.patch.txt

Not sure if pkgsrc is intended to be built with the Studio compiler aswell, in that case the compiler version should be checked in the configure script.

Updating libcouchbase to v2.3.1

I did some work to get pkgsrc to build libcouchbase v2.3.1

The patch is located here:
http://us-east.manta.joyent.com/forestside/public/0001-Update-libcouchbase-to-v2.3.1.patch

ptpd needs more work

It doesn't even launch. The reason for this is because the getifaddrs() call on Illumos doesn't return AF_LINK addresses, which ptp2d requires. dmesg(1m) shows this clearly:

2014-01-19T15:50:05+00:00 localhost ptpd2: [ID 149225 daemon.error] could not get hardware address for interface "net0"

A patched 2.1 from Pluribus Networks has a lot of diffs, including the use of libdlpi to obtain the NIC's MAC address. I'm not sure yet if that's the best approach, but I can provide this patched 2.1 for inspection, if need be. (I may also be able to help a little immediately, and perhaps a lot more in February.)