Re: SAMBA crash of smbd(18370) signal 6

2016-05-31 Thread johnw
On 06/01/2016 01:52 PM, johnw wrote:

Hi, I got the core dump now, thank.

https://drive.google.com/file/d/0B6LuynW2KDT_NUtacXc4YVpVM3c/view?usp=sharing




0xCF2C80AC.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


Re: SAMBA crash of smbd(18370) signal 6

2016-05-31 Thread johnw
Hi, smbd crash again.
>> A gdb backtrace would help.
>>
>> doas gdb smbd /var/crash/smbd/something.core, type 'bt'
>>
>> BTW testparm is nice but it contains lots of extra data, it is a good
>> thing to have its output plus the original smb.conf.
Sorry to say that, I forget to mkdir -m 700 /var/crash/smbd, so no core
this time.

I attached /etc/samba/smb.conf.

>
> In your smb config file add
>
> panic action = /bin/sleep 9000
>
> Start smbd, do what ever you do to make it crash and attach to the smbd 
> process using gdb.
>
>

I found some crash message in /var/log/samba/log.smbd (attached) like this:

[2016/06/01 13:14:14.773811,  0] ../lib/util/fault.c:79(fault_report)
  INTERNAL ERROR: Signal 11 in pid 92776 (4.4.3)
  Please read the Trouble-Shooting section of the Samba HOWTO
[2016/06/01 13:14:14.773862,  0] ../lib/util/fault.c:81(fault_report)
  ===
[2016/06/01 13:14:14.773876,  0] ../source3/lib/util.c:791(smb_panic_s3)
  PANIC (pid 92776): internal error
[2016/06/01 13:14:14.774048,  0] ../source3/lib/util.c:902(log_stack_trace)
  BACKTRACE: 1 stack frames:
   #0 0x11bbe8ae751e  at
/usr/local/lib/libsmbconf.so.0.0
[2016/06/01 13:14:14.774116,  0] ../source3/lib/util.c:803(smb_panic_s3)
  smb_panic(): calling panic action [/bin/sleep 9000]

then I run gdb /usr/local/sbin/smbd 92776 as root

and then type bt

(gdb) bt
#0  0x11bc8570973a in _thread_sys_wait4 () at :2
#1  0x11bc856f9e79 in *_libc_wait4_cancel (wpid=Variable "wpid" is
not available.
) at /usr/src/lib/libc/sys/w_wait4.c:27
#2  0x11bc8571ad4d in *_libc_system (command=Variable "command" is
not available.
) at /usr/src/lib/libc/stdlib/system.c:69
#3  0x11bbe8ae766d in smb_panic_s3 () from
/usr/local/lib/libsmbconf.so.0.0
#4  0x11bc3b68362d in smb_panic () from
/usr/local/lib/libsamba-util.so.1.0
#5  0x11bc3b68383f in sig_fault () from
/usr/local/lib/libsamba-util.so.1.0
#6  
#7  0x11b98ce0a52a in smbd_sig_chld_handler () from /usr/local/sbin/smbd
#8  0x11bc86ee89eb in tevent_common_check_signal () from
/usr/local/lib/libtevent.so.0.2
#9  0x11bbe8afcc51 in run_events_poll () from
/usr/local/lib/libsmbconf.so.0.0
#10 0x11bbe8afd270 in s3_event_loop_once () from
/usr/local/lib/libsmbconf.so.0.0
#11 0x11bc86ee4dd1 in _tevent_loop_once () from
/usr/local/lib/libtevent.so.0.2
#12 0x11bc86ee4e4b in tevent_common_loop_wait () from
/usr/local/lib/libtevent.so.0.2
#13 0x11b98ce0c0f0 in main () from /usr/local/sbin/smbd
Current language:  auto; currently asm



Thank all.
# Global parameters
[global]
dos charset = CP950
unix charset = UTF-8
workgroup = WONGHOME
netbios name = KDC
netbios aliases = PDC
server string = %h server (Samba %v)
interfaces = 192.168.168.1, 127.0.0.1
bind interfaces only = Yes
encrypt passwords = Yes
log level = 0 smb:10 vfs:10 auth:10 lanman:10 rpc_parse:10 rpc_srv:10 
rpc_cli:10 winbind:10 idmap:10
log file = /var/log/samba/log.%m
max log size = 1000
name resolve order = wins lmhosts host
os level = 65
local master = Yes
domain master = Yes
preferred master = Yes
dns proxy = No
wins support = Yes
invalid users = root
hosts allow = 192.168.168.0/24, 127.0.0.1
passdb backend = tdbsam
logon drive = S:
logon path = \\%N\home\samba\netlogon\%U\profiles
logon home = \\%N\home\samba\netlogon\%U
smb ports = 139 445
create mask = 0777
directory mask = 0777
force create mode = 0644
force directory mode = 0555

passdb expand explicit = No
security = user
force user = _samba
force group = _samba

unix extensions = No
wide links = Yes
follow symlinks = Yes

nmbd bind explicit broadcast = No

max open files = 2048
panic action = /bin/sleep 9000

[IPC$]
path = /tmp
read only = Yes
browseable = No

[netlogon]
comment = Samba Logon
path = /home/samba/netlogon
read only = Yes
browseable = No

[ramdisk]
comment = RamDisk
path = /ramdisk
browseable = No

[home]
comment = HOME
path = /home
browseable = No

[2016/05/30 19:05:04.067065, 10, pid=69048, effective(0, 0), real(0, 0), 
class=auth] ../source3/auth/auth_util.c:609(create_local_token)
  Could not convert SID S-1-5-21-1636773426-1683223001-3516073587-514 to gid, 
ignoring it
[2016/05/30 19:05:04.067147, 10, pid=69048, effective(0, 0), real(0, 0), 
class=auth] ../source3/auth/auth_util.c:609(create_local_token)
  Could not convert SID S-1-1-0 to gid, ignoring it
[2016/05/30 19:05:04.067158, 10, pid=69048, effective(0, 0), real(0, 0), 
class=auth] ../source3/auth/auth_util.c:609(create_local_token)
  Could not convert SID S-1-5-2 to gid, ignoring it
[2016/05/30 19:

Re: WIP: tex live 2015

2016-05-31 Thread Ingo Schwarze
Hi Edd,

Edd Barrett wrote on Tue, May 24, 2016 at 06:54:33PM +0100:

> Has anyone tested?

I admit i did not do full testing, simply because anything i do
with it (except using it once it's installed) takes almost forever.
My old Z61m seems seriously underpowered to do real build system
and pkg_add(1) tests on packages of this size, even with my
brand-new SSD.

However, it builds, installs, and runs fine for me on i386-current,
including upgrading from the 2014 version.  I found no issues
running it over my collection of LaTeX documents.

> I've been running this for a while now without issues.
> Comments? OK? We need to think carefully if this goes in pre
> or post 6.0.

Whatever a ports OK on my part may be worth, OK schwarze@.

I think you should get it in - the earlier, the better, because
that leaves you more time to fix it if any issues should show up
once the packages hit the mirrors.  Given how slow everything with
this beast is, I doubt that you can get much more testing without
committing it.

Yours,
  Ingo



Re: sparc64 gd or libpng coredump

2016-05-31 Thread Markus Lude
On Mon, May 30, 2016 at 11:42:26PM +0200, Christian Weisgerber wrote:
> Otto Moerbeek:
> 
> > running analog on current sparc64 gives more coredumps coming from
> > libpng (via gd).
> 
> The graphics/png regression tests also fail spectacularly.
> 
> Most likely this is fallout from the ld.so problem that is currently
> ravaging sparc64.
 
Should one report those problems on sparc64?
Some more ports fails to build here on and I see segmentation faults
too.

Regards,
Markus



Re: Inkscape core dump

2016-05-31 Thread Rafael Sadowski
On Mon May 30, 2016 at 03:14:49PM -0400, Predrag Punosevac wrote:
> Rafael Sadowski  wrote:
> 
> > On Sun May 29, 2016 at 10:21:07PM -0400, Predrag Punosevac wrote:
> > > Running amd54 5.9 stable (upgraded from 5.8)
> > > 
> > > predrag@oko$ uname -a
> > > OpenBSD oko.bagdala2.net 5.9 GENERIC.MP#4 amd64
> > > 
> > > predrag@oko$ pkg_info inkscape
> > > Information for inst:inkscape-0.91p7
> > > 
> > > Comment:
> > > SVG vector drawing application
> > > 
> > > Description:
> > > Inkscape is a vector graphics editor, with capabilities similar
> > > to Illustrator, CorelDraw, or Xara X, using the W3C standard Scalable
> > > Vector Graphics (SVG) file format.
> > > 
> > > Maintainer: The OpenBSD ports mailing-list 
> > > 
> > > WWW: http://www.inkscape.org/
> > > 
> > > 
> > > Trying to export SVG image as eps or ps will cause InkScape to crash
> > 
> > Thanks for the report. Could you try Erling's advice, if it's not work
> > for you I'll debug inkscape.
> > 
> 
> The same result. I should have said in my first e-mail that "export PNG"
> works flawlessly. It looks like Inkscape is using ImageMagick as a
> backend for image format conversions. Personally I always use
> GraphicsMagick so for all I know it could be ImageMagick bug.
> 

I have bad news for you. The exports are working fine in -current. I
think it's an ImageMagick (or another library) bug in 5.9.

Best regards,

Rafael



Re: NEW sysutils/exfat-utils 1.2.3 port

2016-05-31 Thread Mikolaj Kucharski
On Mon, May 30, 2016 at 11:01:12PM +0100, Mikolaj Kucharski wrote:
> Hi,
> 
> Another port handful while dealing with exFAT filesystem. Quote from
> DESCR:
> 
> > Utilities to manage extended file allocation table filesystem. This
> > package provides tools to create, check and label the filesystem.
> >
> > It contains dumpexfat to dump properties of the filesystem, exfatfsck to
> > report errors found on a exFAT filesystem, exfatlabel to label a exFAT
> > filesystem and mkexfatfs to create a exFAT filesystem.
> 
> I didn't find nicer way for automake no-installman option in
> configure.ac, so decided to patch Makefile.in files.

New port with modified permit lines, based on discussion in fuse-exfat
thread.

-- 
best regards
q#


exfat-utils-1.2.3-port-v2.tgz
Description: application/tar-gz


Re: NEW sysutils/fuse-exfat 1.2.3 port

2016-05-31 Thread Mikolaj Kucharski
On Tue, May 31, 2016 at 03:31:14PM +0200, Dmitrij D. Czarkoff wrote:
> Mikolaj Kucharski said:
> > Are you saying I should modify port to include:
> > 
> > PERMIT_PACKAGE_CDROM =  patents
> > PERMIT_PACKAGE_FTP =Yes
> 
> This is what we normally do in such cases.  I would be happy to import
> it with this change.  OK?

Yeah, that sounds fine. I'm attaching new port which includes above
permit lines and also some other tiny changes.

-- 
best regards
q#


fuse-exfat-1.2.3-port-v2.tgz
Description: application/tar-gz


How make port which have multiple rc.d scripts?

2016-05-31 Thread Evgeniy Sudyr
I'm working on new port and it contains multiple rc.d scripts, none
with same name as port:

# make plist

===>  Updating plist for silk-3.12.1
Error: Invalid shared library @lib lib/libfixbuf.so.${LIBfixbuf_VERSION}
Subpackage -: Stripping dirs from net/libfixbuf
Subpackage -: Stripping dirs from devel/glib2
Subpackage -: Stripping dirs from devel/gettext
Subpackage -: Stripping dirs from converters/libiconv
Subpackage -: Stripping dirs from lang/python/2.7
Subpackage -: Stripping dirs from archivers/bzip2
Subpackage -: Stripping dirs from devel/libffi
Subpackage -: Stripping dirs from devel/pcre
Subpackage -: Stripping dirs from devel/libelf
Subpackage -: Stripping dirs from net/libcares
Subpackage -: Stripping dirs from net/adns
Subpackage -: Stripping dirs from archivers/lzo
Subpackage -: Stripping dirs from archivers/lzo2
Subpackage -: Stripping dirs from security/gnutls
Subpackage -: Stripping dirs from devel/libidn
Subpackage -: Stripping dirs from security/libtasn1
Subpackage -: Stripping dirs from security/libnettle
Subpackage -: Stripping dirs from devel/gmp
Subpackage -: Stripping dirs from security/p11-kit

Scanning destdir
Getting old lists
1st pass identifying files
Attaching annotations

Sorting out destdir files
make-plist: Bogus element outside of every prefix: /etc/rc.d/flowcap
make-plist: Bogus element outside of every prefix: /etc/rc.d/rwflowappend
make-plist: Bogus element outside of every prefix: /etc/rc.d/rwflowpack
make-plist: Bogus element outside of every prefix: /etc/rc.d/rwpoolexec
make-plist: Bogus element outside of every prefix: /etc/rc.d/rwreceiver
make-plist: Bogus element outside of every prefix: /etc/rc.d/rwsender

WARNING: unregistered shared lib(s)
SHARED_LIBS +=  flowsource0.0 # 14.0
SHARED_LIBS +=  silk-thrd 0.0 # 6.3
SHARED_LIBS +=  silk  0.0 # 20.1


One way I see is to create subpackages, any other suggestions?

--
With regards,
Eugene Sudyr



New port: graphics/imv

2016-05-31 Thread Dmitrij D. Czarkoff
Hi!

Imv is a minimalist command-line image viewer with support for over 30
image formats including Adobe Photoshop .psd files, animated GIFs and
various raw formats.

OK to import?

-- 
Dmitrij D. Czarkoff


imv-2.1.1.tgz
Description: application/tar-gz


Re: NEW sysutils/fuse-exfat 1.2.3 port

2016-05-31 Thread Dmitrij D. Czarkoff
Mikolaj Kucharski said:
> Are you saying I should modify port to include:
> 
> PERMIT_PACKAGE_CDROM =patents
> PERMIT_PACKAGE_FTP =  Yes

This is what we normally do in such cases.  I would be happy to import
it with this change.  OK?

-- 
Dmitrij D. Czarkoff



Re: Update: devel/py-hg-git and its dependencies

2016-05-31 Thread Dmitrij D. Czarkoff
Antoine Jacoutot said:
> Please don't hardcode the python version in dependencies.

Sure.  OK?

-- 
Dmitrij D. Czarkoff

Index: devel/py-gevent/Makefile
===
RCS file: /cvs/ports/devel/py-gevent/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- devel/py-gevent/Makefile18 Oct 2015 14:50:31 -  1.7
+++ devel/py-gevent/Makefile31 May 2016 08:58:22 -
@@ -2,9 +2,9 @@
 
 COMMENT =  network library for easy and scalable concurrency
 
-MODPY_EGG_VERSION =1.0.2
+MODPY_EGG_VERSION =1.1.1
 DISTNAME = gevent-${MODPY_EGG_VERSION}
-PKGNAME =  py-${DISTNAME}
+PKGNAME =  ${MODPY_PY_PREFIX}${DISTNAME}
 MAINTAINER =   Dmitrij D. Czarkoff 
 
 CATEGORIES =   devel
@@ -19,13 +19,21 @@ MODULES =   lang/python
 MODPY_PI = Yes
 MODPY_SETUPTOOLS = Yes
 
+BUILD_DEPENDS =lang/cython \
+   devel/py-cffi
 LIB_DEPENDS =  devel/libev \
net/libcares
 RUN_DEPENDS =  devel/py-greenlet
-TEST_DEPENDS = ${RUN_DEPENDS}
+TEST_DEPENDS = ${RUN_DEPENDS} \
+   lang/python/${MODPY_VERSION},-tests \
+   sysutils/py-psutil
 
 MAKE_ENV = CARES_EMBED=0 LIBEV_EMBED=0
 CFLAGS +=  -I${LOCALBASE}/include
 LDFLAGS += -L${LOCALBASE}/lib
+
+do-test:
+   cd ${WRKSRC}/greentest && ${SETENV} ${MAKE_ENV} PYTHONPATH="${WRKSRC}" \
+   ${MODPY_BIN} ./testrunner.py --config ../known_failures.py
 
 .include 
Index: devel/py-gevent/distinfo
===
RCS file: /cvs/ports/devel/py-gevent/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- devel/py-gevent/distinfo18 Oct 2015 14:50:31 -  1.3
+++ devel/py-gevent/distinfo21 May 2016 11:10:32 -
@@ -1,2 +1,2 @@
-SHA256 (gevent-1.0.2.tar.gz) = OuHKD1M93LF6qxbOZrQks/O4Vf87lQhSaRXTxrc/ujE=
-SIZE (gevent-1.0.2.tar.gz) = 1735721
+SHA256 (gevent-1.1.1.tar.gz) = buW5hRsqzeCN96ubmikD9YtLDlVUBcRE9LHdFvccruo=
+SIZE (gevent-1.1.1.tar.gz) = 2008368
Index: devel/py-gevent/pkg/PLIST
===
RCS file: /cvs/ports/devel/py-gevent/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- devel/py-gevent/pkg/PLIST   18 Oct 2015 14:50:31 -  1.2
+++ devel/py-gevent/pkg/PLIST   21 May 2016 11:10:32 -
@@ -4,24 +4,49 @@ lib/python${MODPY_VERSION}/site-packages
 
lib/python${MODPY_VERSION}/site-packages/gevent-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
 
lib/python${MODPY_VERSION}/site-packages/gevent-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
 
lib/python${MODPY_VERSION}/site-packages/gevent-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
+lib/python${MODPY_VERSION}/site-packages/gevent-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
 
lib/python${MODPY_VERSION}/site-packages/gevent-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
 
lib/python${MODPY_VERSION}/site-packages/gevent-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
 lib/python${MODPY_VERSION}/site-packages/gevent/__init__.py
 lib/python${MODPY_VERSION}/site-packages/gevent/__init__.pyc
+lib/python${MODPY_VERSION}/site-packages/gevent/_corecffi_build.py
+lib/python${MODPY_VERSION}/site-packages/gevent/_corecffi_build.pyc
+lib/python${MODPY_VERSION}/site-packages/gevent/_fileobjectcommon.py
+lib/python${MODPY_VERSION}/site-packages/gevent/_fileobjectcommon.pyc
+lib/python${MODPY_VERSION}/site-packages/gevent/_fileobjectposix.py
+lib/python${MODPY_VERSION}/site-packages/gevent/_fileobjectposix.pyc
+lib/python${MODPY_VERSION}/site-packages/gevent/_semaphore.py
+lib/python${MODPY_VERSION}/site-packages/gevent/_semaphore.pyc
 lib/python${MODPY_VERSION}/site-packages/gevent/_semaphore.so
+lib/python${MODPY_VERSION}/site-packages/gevent/_socket2.py
+lib/python${MODPY_VERSION}/site-packages/gevent/_socket2.pyc
+lib/python${MODPY_VERSION}/site-packages/gevent/_socket3.py
+lib/python${MODPY_VERSION}/site-packages/gevent/_socketcommon.py
+lib/python${MODPY_VERSION}/site-packages/gevent/_socketcommon.pyc
 lib/python${MODPY_VERSION}/site-packages/gevent/_ssl2.py
 lib/python${MODPY_VERSION}/site-packages/gevent/_ssl2.pyc
+lib/python${MODPY_VERSION}/site-packages/gevent/_ssl3.py
+lib/python${MODPY_VERSION}/site-packages/gevent/_ssl3.pyc
 lib/python${MODPY_VERSION}/site-packages/gevent/_sslgte279.py
 lib/python${MODPY_VERSION}/site-packages/gevent/_sslgte279.pyc
+lib/python${MODPY_VERSION}/site-packages/gevent/_tblib.py
+lib/python${MODPY_VERSION}/site-packages/gevent/_tblib.pyc
 lib/python${MODPY_VERSION}/site-packages/gevent/_threading.py
 lib/python${MODPY_VERSION}/site-packages/gevent/_threading.pyc
-lib/python${MODPY_VERSION}/site-packages/gevent/_util.so
+lib/python${MO

Re: NEW sysutils/fuse-exfat 1.2.3 port

2016-05-31 Thread Raul Miller
On Tue, May 31, 2016 at 7:41 AM, Ray Lai  wrote:
> I'm not a lawyer, I don't know what the laws are for distributing patented 
> code, source or binary, paid CD-ROM or free FTP.

In my experience, you should be able to count on lots of people - both
outside the legal profession, and inside - to make up all sorts of
crud about those laws.

But I expect that none of that really matters, because it also seems
like you can count on different courts saying different things (if
they are willing to say anything at all), based on their ideas of what
reasonable behavior looks like (and their own extensive knowledge of
laws and history that no one else knows about). (But, also, I'm
not sure that much of anything in the computer industry is based on
reasonable behavior.)

That said...

Most patents are worthless if you are willing to put in the effort to
research them. I've been through a number of patent proceedings, and I
can at least tell you a bit about the USA patent mechanisms:

Patents are essentially a set of claims. Patent law is based on a
"guilty until proven innocent" philosophy which means it sort of does
not matter what they say - if someone says you are guilty of violating
them, you are technically in violation at that point in time. But if
you can show that all of the claims on a patent are either (a) so
narrow that they do not apply to you, or (b) so broad that they apply
to things which existed before the patent was filed, then you become
innocent of violating that patent. But you have no way of knowing what
patents have been filed, because there are too many of them to
understand, and because no one really cares. But in practice: [a] the
wording of patent claims is so ambiguous that you can almost always
show that you are innocent of violating any patent claims, and [b] the
process of proving your innocence is so expensive that almost no one
actually cares about the patent process. I have read that it costs on
the order of $12 million to deal with a patent court case, and people
with that kind of money don't have the time to understand the relevant
technology - so they delegate the details to people they can get along
with Anyways, it's a mess and almost always a bad investment. But
for the few people with more than enough money to fund this kind of
thing, it's also something they might be doing just on general
principles or because someone asked them to be doing that.

The net effect is that what patents say doesn't really matter all that
much. If someone threatens you with a patent lawsuit you can be almost
guaranteed that they have almost no idea what you are doing, and that
they will loudly assert that you are wrong. If this happens to you,
you should spend some time in a library (the kind that has books, not
a computer based transient phenomena) and sit down and find prior art
(typically from previous centuries) for each of the the things you are
doing which correspond to claims of the patents you are supposedly
"violating". You should expect this to take days, or weeks - don't
give up prematurely. Or, if you don't care that much about what you
are doing, you should have been doing something different in the first
place.

And if you want to protect yourself against patents, spending some
time, effort and/or money to make sure that your local library has
good reference and historical works is probably the best way to go.

At least, if you are concerned about USA patents. I have no background
nor experience with other jurisdictions.

I hope this helps.

Have a nice day.

-- 
Raul



Re: NEW sysutils/fuse-exfat 1.2.3 port

2016-05-31 Thread Ray Lai
On May 31, 2016, at 6:20 PM, Mikolaj Kucharski  wrote:
> 
> Ray,
> 
>> On Tue, May 31, 2016 at 03:18:02PM +0800, Ray Lai wrote:
>> There may be patent issues:
>> http://www.linux-magazine.com/Issues/2013/156/exFAT-Filesystem
> 
> Are you saying I should modify port to include:
> 
> PERMIT_PACKAGE_CDROM =patents
> PERMIT_PACKAGE_FTP =Yes
> 
> I'm not sure, how should I modify the port after your comment.

I'm not a lawyer, I don't know what the laws are for distributing patented 
code, source or binary, paid CD-ROM or free FTP.

Ray


Re: tcsh Ambiguous: choose package on every update

2016-05-31 Thread Stuart Henderson
On 2016/05/31 13:06, Kapetanakis Giannis wrote:
> Hi,
> 
> I'm having this strange issue with tcsh package.
> 
> Every time I'm upgrading packages it asks if I want the dynamic or the
> static flavor.
> 
> This does not happen with other packages (ie. gtar)
> 
> # pkg_info | egrep 'tcsh|gtar'
> gtar-1.28p2 GNU version of the traditional tape archiver
> tcsh-6.19.00extended C-shell with many useful features
> 
> # pkg_add -ui -F update -F updatedepends (or pkg_add -u)
> # pkg_add -u
> 
> quirks-2.234 signed on 2016-05-24T23:44:35Z
> Ambiguous: choose package for tcsh-6.19.00
> a   0: 
> 1: tcsh-6.19.00
> 2: tcsh-6.19.00-static
> Your choice: 1
> 
> regards,
> 
> Giannis
> ps. Please cc me directly as I'm not the @ports list
> 
> 

tcsh used to have a static flavour, then it was removed (with
an @pkgpath marker added), then it was added again (but the marker
was not removed).

At update time, pkg_add sees the @pkgpath marker so it considers
both versions of the package as a suitable upgrade path.

This should fix it ...  ok?




Index: Makefile
===
RCS file: /cvs/ports/shells/tcsh/Makefile,v
retrieving revision 1.54
diff -u -p -r1.54 Makefile
--- Makefile10 Jun 2015 13:02:34 -  1.54
+++ Makefile31 May 2016 11:17:14 -
@@ -3,6 +3,7 @@
 COMMENT=   extended C-shell with many useful features
 
 DISTNAME=  tcsh-6.19.00
+REVISION=  0
 CATEGORIES=shells
 HOMEPAGE=  http://www.tcsh.org/
 
Index: pkg/PLIST
===
RCS file: /cvs/ports/shells/tcsh/pkg/PLIST,v
retrieving revision 1.12
diff -u -p -r1.12 PLIST
--- pkg/PLIST   27 May 2007 18:04:47 -  1.12
+++ pkg/PLIST   31 May 2016 11:17:14 -
@@ -1,5 +1,4 @@
 @comment $OpenBSD: PLIST,v 1.12 2007/05/27 18:04:47 naddy Exp $
-@pkgpath shells/tcsh,static
 @shell bin/tcsh
 @man man/man1/tcsh.1
 share/nls/C/tcsh.cat



Re: NEW sysutils/fuse-exfat 1.2.3 port

2016-05-31 Thread Mikolaj Kucharski
Ray,

On Tue, May 31, 2016 at 03:18:02PM +0800, Ray Lai wrote:
> On Tue, May 31, 2016 at 4:28 AM, Mikolaj Kucharski 
> wrote:
> > New port of fuse-exfat, quote form DESCR:
> > >  fuse-exfat aims to provide a full-featured exFAT file system
> > >  implementaiton for Unix-like systems as a FUSE module.
> > 
> > Tested on SDXC card with exFAT. Seems to work, both read and write.
> 
> There may be patent issues:
> http://www.linux-magazine.com/Issues/2013/156/exFAT-Filesystem

Are you saying I should modify port to include:

PERMIT_PACKAGE_CDROM =  patents
PERMIT_PACKAGE_FTP =Yes

I'm not sure, how should I modify the port after your comment.

-- 
best regards
q#



NEW: devel/py-py-backports-shutil-get-terminal-size and py-backports

2016-05-31 Thread Alexandr Shadchin
Hi,

ok to import?
py-backports-shutil-get-terminal-size need for update ipython.

py-backports:
Namespace for backported Python features.

py-backports-shutil-get-terminal-size:
A backport of the get_terminal_size function from Python 3.3’s shutil.

Unlike the original version it is written in pure Python rather than C,
so it might be a tiny bit slower.

-- 
Alexandr Shadchin



py-backports.tgz
Description: application/tar-gz


py-backports-shutil-get-terminal-size.tgz
Description: application/tar-gz
Index: Makefile
===
RCS file: /cvs/ports/devel/py-backports-ssl-match-hostname/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile22 Apr 2016 11:38:37 -  1.5
+++ Makefile31 May 2016 10:00:27 -
@@ -6,6 +6,7 @@ MODPY_EGG_VERSION = 3.5.0.1
 DISTNAME = backports.ssl_match_hostname-${MODPY_EGG_VERSION}
 PKGNAME =  py-backports-ssl-match-hostname-${MODPY_EGG_VERSION}
 CATEGORIES =   devel
+REVISION = 0
 
 MAINTAINER =   Alexandr Shadchin 
 
@@ -19,5 +20,7 @@ MODULES = lang/python
 # This comes built in with python-3.2 and above. Since all our
 # Python 3 ports are newer than 3.2, we can just do this:
 MODPY_VERSION =${MODPY_DEFAULT_VERSION_2}
+
+RUN_DEPENDS =  devel/py-backports
 
 .include 
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/py-backports-ssl-match-hostname/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST   22 Apr 2016 11:38:37 -  1.2
+++ pkg/PLIST   31 May 2016 10:00:27 -
@@ -1,8 +1,7 @@
 @comment $OpenBSD: PLIST,v 1.2 2016/04/22 11:38:37 shadchin Exp $
-lib/python${MODPY_VERSION}/site-packages/backports/
 
lib/python${MODPY_VERSION}/site-packages/backports.ssl_match_hostname-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info
-lib/python${MODPY_VERSION}/site-packages/backports/__init__.py
-lib/python${MODPY_VERSION}/site-packages/backports/__init__.pyc
+@comment lib/python${MODPY_VERSION}/site-packages/backports/__init__.py
+@comment lib/python${MODPY_VERSION}/site-packages/backports/__init__.pyc
 lib/python${MODPY_VERSION}/site-packages/backports/ssl_match_hostname/
 
lib/python${MODPY_VERSION}/site-packages/backports/ssl_match_hostname/__init__.py
 
lib/python${MODPY_VERSION}/site-packages/backports/ssl_match_hostname/__init__.pyc


tcsh Ambiguous: choose package on every update

2016-05-31 Thread Kapetanakis Giannis

Hi,

I'm having this strange issue with tcsh package.

Every time I'm upgrading packages it asks if I want the dynamic or the 
static flavor.


This does not happen with other packages (ie. gtar)

# pkg_info | egrep 'tcsh|gtar'
gtar-1.28p2 GNU version of the traditional tape archiver
tcsh-6.19.00extended C-shell with many useful features

# pkg_add -ui -F update -F updatedepends (or pkg_add -u)
# pkg_add -u

quirks-2.234 signed on 2016-05-24T23:44:35Z
Ambiguous: choose package for tcsh-6.19.00
a   0: 
1: tcsh-6.19.00
2: tcsh-6.19.00-static
Your choice: 1

regards,

Giannis
ps. Please cc me directly as I'm not the @ports list




[devel/boost] fix error: no member named 'int128_type' in namespace 'boost'

2016-05-31 Thread David Coppa

Basically, boost does not like mixing different compilers at build
and run time.

We build boost with gcc-4.2.1, which doesn't support __int128.

$ /usr/local/bin/egcc -dM -E - < /dev/null | grep SIZEOF_INT128
#define __SIZEOF_INT128__ 16
$ /usr/bin/cc -dM -E - < /dev/null | grep SIZEOF_INT128
$

This results in a /usr/local/include/boost/config/user.hpp missing
the "BOOST_HAS_INT128" define.

When building something which depends on boost using a newer compiler
(gcc-4.9, clang), the following happens:

the code snippet from /usr/local/include/boost/config/compiler/{clang,gcc}.hpp

---8<---

#if defined(__SIZEOF_INT128__) && !defined(__CUDACC__)
#  define BOOST_HAS_INT128
#endif

---8<---

reactivates __int128 support.

But the code into /usr/local/include/boost/config/suffix.hpp:

---8<---

#if defined(BOOST_HAS_INT128) && defined(__cplusplus)
namespace boost{
#  ifdef __GNUC__
   __extension__ typedef __int128 int128_type;
   __extension__ typedef unsigned __int128 uint128_type;
#  else
   typedef __int128 int128_type;
   typedef unsigned __int128 uint128_type;
#  endif
}
#endif

---8<---

is never reached, because /usr/local/include/boost/config/user.hpp
lacks "#define BOOST_HAS_INT128".

And thus the big boom below:

---8<---

In file included from web_connection_base.cpp:44:
In file included from ../include/libtorrent/web_connection_base.hpp:46:
In file included from /usr/local/include/boost/smart_ptr.hpp:28:
In file included from /usr/local/include/boost/make_shared.hpp:15:
In file included from /usr/local/include/boost/smart_ptr/make_shared.hpp:15:
In file included from 
/usr/local/include/boost/smart_ptr/make_shared_object.hpp:18:
In file included from 
/usr/local/include/boost/type_traits/type_with_alignment.hpp:18:
In file included from /usr/local/include/boost/type_traits/is_pod.hpp:14:
In file included from /usr/local/include/boost/type_traits/is_scalar.hpp:12:
In file included from /usr/local/include/boost/type_traits/is_arithmetic.hpp:13:
/usr/local/include/boost/type_traits/is_integral.hpp:72:53: error: no member 
named 'int128_type' in namespace 'boost'
BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,boost::int128_type,true)
 ~~~^
/usr/local/include/boost/type_traits/detail/bool_trait_def.hpp:182:41: note: 
expanded from macro 'BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1'
BOOST_TT_AUX_BOOL_TRAIT_SPEC1(trait,sp const volatile,value) \
^~
/usr/local/include/boost/type_traits/detail/bool_trait_def.hpp:97:26: note: 
expanded from macro 'BOOST_TT_AUX_BOOL_TRAIT_SPEC1'
template<> struct trait< sp > \
 ^~
In file included from web_connection_base.cpp:44:
In file included from ../include/libtorrent/web_connection_base.hpp:46:
In file included from /usr/local/include/boost/smart_ptr.hpp:28:
In file included from /usr/local/include/boost/make_shared.hpp:15:
In file included from /usr/local/include/boost/smart_ptr/make_shared.hpp:15:
In file included from 
/usr/local/include/boost/smart_ptr/make_shared_object.hpp:18:
In file included from 
/usr/local/include/boost/type_traits/type_with_alignment.hpp:18:
In file included from /usr/local/include/boost/type_traits/is_pod.hpp:14:
In file included from /usr/local/include/boost/type_traits/is_scalar.hpp:12:
In file included from /usr/local/include/boost/type_traits/is_arithmetic.hpp:13:
/usr/local/include/boost/type_traits/is_integral.hpp:73:53: error: no member 
named 'uint128_type' in namespace 'boost'
BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,boost::uint128_type,true)
 ~~~^
/usr/local/include/boost/type_traits/detail/bool_trait_def.hpp:179:41: note: 
expanded from macro 'BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1'
BOOST_TT_AUX_BOOL_TRAIT_SPEC1(trait,sp,value) \
^~
/usr/local/include/boost/type_traits/detail/bool_trait_def.hpp:97:26: note: 
expanded from macro 'BOOST_TT_AUX_BOOL_TRAIT_SPEC1'
template<> struct trait< sp > \
 ^~

---8<---

So, I've chosen to use the lowest common denominator, as per the
following diff:

Index: Makefile
===
RCS file: /cvs/ports/devel/boost/Makefile,v
retrieving revision 1.57
diff -u -p -u -p -r1.57 Makefile
--- Makefile27 May 2016 22:35:40 -  1.57
+++ Makefile31 May 2016 07:41:54 -
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS= ${GCC4_ARCHS}
 COMMENT=   free peer-reviewed portable C++ source libraries
 
 VERSION=   1.58.0
-REVISION=  1
+REVISION=  2
 DISTNAME=  boost_${VERSION:S/./_/g}
 PKGNAME=   boost-${VERSION}
 CATEGORIES=devel
Index: patches/patch-boost_config_compiler_clang_hpp
===
RCS file: patches/patch-boost_config_compiler_clang_hpp
diff -N patches/patch-boost_config_compiler_clang_hpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-boos

Re: Inkscape core dump

2016-05-31 Thread Edd Barrett
On Mon, May 30, 2016 at 01:56:39PM +0100, Edd Barrett wrote:
> I know a couple of ways to crash the in-tree inkscape. Ill link the bugs here 
> once i have reported upstream.
> 

FWIW:
https://bugs.launchpad.net/inkscape/+bug/1587311
https://bugs.launchpad.net/inkscape/+bug/1587319

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk



Re: NEW sysutils/fuse-exfat 1.2.3 port

2016-05-31 Thread Ray Lai
> On Tue, May 31, 2016 at 4:28 AM, Mikolaj Kucharski  
> wrote:
> New port of fuse-exfat, quote form DESCR:
>> fuse-exfat aims to provide a full-featured exFAT file system
>> implementaiton for Unix-like systems as a FUSE module.
> Tested on SDXC card with exFAT. Seems to work, both read and write.

There may be patent issues:
http://www.linux-magazine.com/Issues/2013/156/exFAT-Filesystem