comments for a pmake newb

[Joseph Mingrone]

I'm porting a program that uses a simple GNU make file, but I'm thinking
about replacing the make file to remove the devel/gmake dependency.  I
don't foresee many upstream changes that will make this an issue.  Is
this a bad/good idea?  Are there any example ports that do this?  My
searching didn't turn any up.

My simple make file replacement is below.  If you have any suggestions
to offer, I'm open to criticism.

Thanks,

Joseph

PROG = blah
SRCS != echo *.c
OBJS = $(SRCS:.c=.o)

CFLAGS  = -D_POSIX_SOURCE -D_POSIX_C_SOURCE=200809L -D_THREAD_SAFE 
-D_XOPEN_SOURCE=700 -pedantic -std=c11 -Wall
INC = -I/usr/local/include
LDFLAGS = -L/usr/local/lib
LDLIBS  = -lX11

.ifmake debug
   CFLAGS += -DDEBUG -g -O0
.else
   CFLAGS += -DNDEBUG -O3
.endif

${PROG}: ${OBJS}
${CC} ${CFLAGS} ${LDFLAGS} ${LDLIBS} $(.ALLSRC) -o $(.TARGET)

${OBJS}: ${SRCS}
${CC} -c ${CFLAGS} ${INC} ${SRCS}

debug: ${PROG}

clean:
rm -f ${PROG} *.o *.core

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

situation with www/node6 and www/node

[Joseph Mingrone]

Hello,

I am hitting an issue where the conflicting www/node6 and www/node
packages are attempting to be installed together.  For example, the
upcoming net-im/mastodon pulls in www/yarn (which depends on www/node6
by default), and indirectly depends on devel/rubygem-execjs (which
depends on www/node by default).

It would be ideal if all ports depended on the same node version by
default.  Looking at the current state of the ports tree, it would make
sense for everything to depend on www/node since the only two ports
depending on www/node6 by default are www/npm3 and www/yarn.  But, Luca
makes the point that version 7 of node is not what upstream recommends.

Could we come to a consensus here?

Thanks,

Joseph


signature.asc
Description: PGP signature

Re: situation with www/node6 and www/node

[Joseph Mingrone]

Steve Wills  writes:
> Can execjs work with node6? What else would have to change to get it all
> onto node6?

It can, but other changes would be needed.  For example www/gitlab pulls
in www/npm, which pulls in www/node.  It also pulls in other ports that
pull in www/rubygjec-execjs.

I think the question is, what should be the default version of node?
Then, everything should (by default) depend on that default version.


signature.asc
Description: PGP signature

Re: situation with www/node6 and www/node

[Joseph Mingrone]

Adam Weinberger  writes:

>> On 18 May, 2017, at 12:25, Adam Weinberger  wrote:

>>> On 18 May, 2017, at 12:22, Luca Pizzamiglio  
>>> wrote:

>>> Hi,

>>> node6 is the LTS, node is the current. From a stability point of view,
>>> node6 is the choice, but node (7) is already widely used.
>>> Probably, the best solution would be to provide the desired node
>>> version via Mk/bsd.default-versions.mk and then all ports depends to
>>> the common version (like perl, python, ...).

>>> In the meanwhile, node can be the new default for yarn and the
>>> conflict will be solved (and it will be coherent with npm)

>> Luca,

>> You're completely right, we really need a USES=node (and there are multiple 
>> attempts at it currently floating around). In the meantime, I think you're 
>> making the right choice setting www/node as the yarn
>> default.

>> # Adam

> Committed in r441191. Thanks, Luca.

> # Adam

Thanks all.  I will abandon https://reviews.freebsd.org/D10696.

Joseph


signature.asc
Description: PGP signature

Re: situation with www/node6 and www/node

[Joseph Mingrone]

Adam Weinberger  writes:

>> On 18 May, 2017, at 12:45, Joseph Mingrone  wrote:

>> Adam Weinberger  writes:

>>>> On 18 May, 2017, at 12:25, Adam Weinberger  wrote:

>>>>> On 18 May, 2017, at 12:22, Luca Pizzamiglio  
>>>>> wrote:

>>>>> Hi,

>>>>> node6 is the LTS, node is the current. From a stability point of view,
>>>>> node6 is the choice, but node (7) is already widely used.
>>>>> Probably, the best solution would be to provide the desired node
>>>>> version via Mk/bsd.default-versions.mk and then all ports depends to
>>>>> the common version (like perl, python, ...).

>>>>> In the meanwhile, node can be the new default for yarn and the
>>>>> conflict will be solved (and it will be coherent with npm)

>>>> Luca,

>>>> You're completely right, we really need a USES=node (and there are 
>>>> multiple attempts at it currently floating around). In the meantime, I 
>>>> think you're making the right choice setting www/node as the yarn
>>>> default.

>>>> # Adam

>>> Committed in r441191. Thanks, Luca.

>>> # Adam

>> Thanks all.  I will abandon https://reviews.freebsd.org/D10696.

> Sorry, Joseph, I wasn't aware of that phab. The update in it is still 
> relevant though; no need to abandon that.

> # Adam

No worries, I was mistaken.  I did an svn diff -rPREV in my copy, which
had my local changes and thought that's what you had committed.

Cheers,

Joseph


signature.asc
Description: PGP signature

Re: math/R: Build failure after PORTREVISION for shlib change

[Joseph Mingrone]

Hi David,

So far I haven't been able to reproduce any problems in an
11.0-RELEASE-p1 jail.  Could you send your list of port options?  If I
can't reproduce any issues with the same options turned on, I will ask
you for a full build log.

Joseph


signature.asc
Description: PGP signature

Re: math/R: Build failure after PORTREVISION for shlib change

[Joseph Mingrone]

David Wolfskill  writes:
> g1-227(11.1)[2] make -C /usr/ports/math/R showconfig
> ===> The following configuration options are available for R-3.4.0_1:
>  ICU=on: Unicode support via ICU
>  INFO=on: GNU info manuals
>  LDOUBLE=on: Long double data type
>  LETTER=on: US letter paper
>  LIBR=on: Shared R library
>  MEMPROF=off: Memory profiling via Rprofmem() and tracemem()
>  NLS=on: Native Language Support
>  RPROF=on: R profiling via Rprof()
>  X11=on: X11 graphics device
> > Require GCC
>  LTO=on: Use Link Time Optimization
>  OPENMP=on: Parallel processing support via OpenMP
> > Require X11
>  GHOSTSCRIPT=on: Graphics device for bitmap files via Ghostscript
>  JPEG=on: JPEG graphics device
>  CAIROPANGO=on: Cairo graphics device and Pango multi-language text
>  PNG=on: PNG graphics device
>  TCLTK=on: Tcl/Tk GUI toolkit support
>  TEXDOCS=on: Build/Install TeX-dependent documentation files
>  TIFF=on: TIFF image format support
> > Options available for the single BLAS: you have to select exactly one 
> of them
>  ATLAS=off: ATLAS BLAS implementation
>  OPENBLAS=off: OpenBLAS BLAS implementation
>  NETLIB=off: Netlib BLAS implementation
>  RBLAS=on: Use R-bundled BLAS implementation
> ===> Use 'make config' to modify these settings
> g1-227(11.1)[3] 

With those options, the build succeeds in an 11.0-RELEASE-p1 jail.
http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2017-06-28_16h53m48s/logs/R-3.4.0_2.log

> Just in case it's relevant, as /usr/local/bin/gcc-ar5 is from gcc5-5.4.0_2:

> g1-227(11.1)[5] make -C /usr/ports/lang/gcc5 showconfig
> ===> The following configuration options are available for gcc5-5.4.0_2:
>  BOOTSTRAP=on: Build using a full bootstrap
>  GRAPHITE=off: Support for Graphite loop optimizations
>  JAVA=on: Java platform support
> ===> Use 'make config' to modify these settings


Everything matches.  The successful build in poudriere even has the same
line that generates the error for you.

/usr/local/bin/gcc-ar5 -cr libtre.a regcomp.o regerror.o regexec.o tre-ast.o 
tre-compile.o tre-match-approx.o tre-match-backtrack.o tre-match-parallel.o 
tre-mem.o tre-parse.o tre-stack.o xmalloc.o

Could you have something in your environment or in make.conf that's
causing a problem?

Joseph


signature.asc
Description: PGP signature

Re: math/R: Is LIBR really needed?

[Joseph Mingrone]

[quoted with Yuri's permission]
Yuri  writes:
> Setting LIBR=off causes lib/R/lib/libR.so to disappear. This makes it
> difficult for ports depending on math/R (like RStudio) to set port
> dependencies.  Is it really important to have the ability to use only
> the static library? In case it isn't important, maybe you could delete
> LIBR?

I think it could be OK to remove the option and always build the shared
library.

Some potential concerns:

- This is not upstream's default.
- Upstream warns of possible performance penalties [1,2].
- Users currently without the shared library will have to reinstall R
  packages the next time they update math/R.

[1] 
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Configuration-options
[2] https://cran.r-project.org/doc/manuals/r-release/R-admin.html#DOCF57

Joseph


signature.asc
Description: PGP signature

Re: Are these Emacs ports still useful?

[Joseph Mingrone]

Yasuhiro KIMURA  writes:

> From: Joseph Mingrone 
> Subject: Are these Emacs ports still useful?
> Date: Sat, 23 Dec 2017 17:29:51 -0400

>> A quick scan suggests that these port may have passed their usefulness.
>> Could you speak up if they are still useful or if you feel they should
>> be removed?
> (snip)
>> - japanese/lookup (source tarball from 2007)

> At least I still use it. And there is beta version of Lookup 2.0 in
> following URL. But it isn't fully compatible with 1.4.1. So I cannot
> dicide whether to update to 2.0.

> http://lookup2.github.io/

Thanks for your feedback.  japanese/lookup should not be removed then.

Joseph


signature.asc
Description: PGP signature

Are these Emacs ports still useful?

[Joseph Mingrone]

[resending (with updates) because original message did not make it to the list]

Hello all,

A quick scan suggests that these port may have passed their usefulness.
Could you speak up if they are still useful or if you feel they should
be removed?

Regards,

Joseph

- sysutils/puppet-mode.el (pulling from source over 5 years old)
- japanese/egg-canna/Makefile (does not build with emacs versions >= 23)
- deskutils/etask (non-mirrored tarball dead since 2007)
- editors/apel (2010 source)
  - editors/flim (2007 source)
- editors/semi (2003 source)
- editors/tree-widget (part of emacs since 2007)
- graphics/xface.el (distilator reports 500 for all sources)
- japanese/lookup (source tarball from 2007) (update: feedback received;
  still useful)
- japanese/migemo-emacs23
- japanese/yc.el (source from 2010, does not build w/ emacs-devel)
- mail/xcite (no real updates since 2010, still useful?) (update:
  feedback received; still useful)
- textproc/dictem (last release over five years ago)
- textproc/doc-mode.el (last release from 2006)
- textproc/emacs-wiki (last release from 2006)
- textproc/htmlize.el (500 from MASTER_SITES; fetchable from distcache)
- textproc/ibus-el (no updates for over 5 years)
- textproc/muse (last release from 2010)
- textproc/xml-lite.el (merged with sgml-mode.el in 2007)
- textproc/xml-parse.el (described as deprecated on Emacs wiki; release
  from 2001)

These ports have not been updated in some time.  Should they be updated or 
removed?

 - editors/psgml (use psgml-1.3.4.tar from 
http://elpa.gnu.org/packages/psgml.html ?)
 - editors/slime (five new releases since last 2015 port update)
 - japanese/ddskk (using nearly 5-year-old release)
 - mail/waderlust (only fetchable by distcache; source from 2005?;
   combine with mail/wanderlust-devel)
 - mail/x-face-e21 (not fetchable) (update: www.jpl.org is back up)
 - math/proofgeneral (version over 5 years old w/ releases since;
   does not building with Emacs 27 without X)
 - misc/elscreen (release from 2007)
 - print/hyperlatex (release from 2006)
 - print/yatex (version almost 5 years old, newer release available)
 - security/starttls (superceded by
   https://github.com/emacs-mirror/emacs/blob/master/lisp/net/starttls.el ?)
 - textproc/dictionary (port version from 2011 or earlier, 2013 version
   available)


signature.asc
Description: PGP signature

Re: Are these Emacs ports still useful?

[Joseph Mingrone]

[resending because original message did not make it to the list]
Joseph Mingrone  writes:

> Yasuhiro KIMURA  writes:

>> From: Joseph Mingrone 
>> Subject: Are these Emacs ports still useful?
>> Date: Sat, 23 Dec 2017 17:29:51 -0400

>>> A quick scan suggests that these port may have passed their usefulness.
>>> Could you speak up if they are still useful or if you feel they should
>>> be removed?
>> (snip) 
>>> - editors/apel (2010 source)
>>>   - editors/flim (2007 source)
>>> - editors/semi (2003 source)

>> They are required by www/emacs-w3m.

>> Regards.

> They are dependencies for www/emacs-w3m, but are they really required?
> Upsreams [1,2] say apel and friends are only required with quite old
> versions of Emacs that were released around 2001.

> Regards,

> Joseph

> [1] The original emacs-w3m source, http://emacs-w3m.namazu.org/, says
> with Emacs 21.1 (released in 2001) "No additional packages are
> required."  Other sources, such as [2] have made fixes to the last
> release from this source.

> [2] The melpa source,
> https://github.com/emacsorphanage/w3m/ has no other elisp dependencies.



signature.asc
Description: PGP signature

Re: Are these Emacs ports still useful?

[Joseph Mingrone]

[resending because original did not make it to the list]
Joseph Mingrone  writes:

> Hajimu UMEMOTO  writes:

>> Hi,

>>>>>>> On Sat, 23 Dec 2017 17:29:51 -0400
>>>>>>> Joseph Mingrone  said:

>> jrm> - mail/xcite (no real updates since 2010, still useful?)

>> I'm using it.  It is very useful at least for me.
>> I don't think no update means no usefulness. :-(

> Agreed.  No updates does not imply it should be removed, but
> superficially it can sometimes suggest stale
> code.  I will unflag mail/xcite for removal.

> Thanks,

> Joseph



signature.asc
Description: PGP signature

Re: Are these Emacs ports still useful?

[Joseph Mingrone]

Yasuhiro KIMURA  writes:

> From: Joseph Mingrone 
> Subject: Re: Are these Emacs ports still useful?
> Date: Sat, 23 Dec 2017 18:29:29 -0400

>>>> A quick scan suggests that these port may have passed their usefulness.
>>>> Could you speak up if they are still useful or if you feel they should
>>>> be removed?
>>> (snip) 
>>>> - editors/apel (2010 source)
>>>>   - editors/flim (2007 source)
>>>> - editors/semi (2003 source)

>>> They are required by www/emacs-w3m.

>> They are dependencies for www/emacs-w3m, but are they really required?
>> Upsreams [1,2] say apel and friends are only required with quite old
>> versions of Emacs that were released around 2001.

> I checked '*.el' files of emacs-w3m-emacs-nox11-1.4.598.b.20170903_2
> and found following lines in
> ${PREFIX}${EMACS_VERSION_SITE_LISPDIR}/w3m/octet.el that is
> installed when OCTET_VIEWER option is enabled.

> yasu@eastasia[2305]% less -N 
> /usr/local/share/emacs/25.3/site-lisp/w3m/octet.el

> (snip)

>  65 ;;; Code:
>  66 
>  67 (eval-when-compile
>  68   (require 'cl))
>  69 
>  70 (require 'poe) ; for compatibility
>  71 (require 'pces); as-binary-process
>  72 (require 'mime); SEMI
>  73 (require 'static)
>  74 (require 'w3m-util); w3m-insert-string

> At line 72 'mime' is required, and this feature is provided by
> semi. So if OCTET_VIEWER option is enabled www/emacs-w3m depends on
> editors/semi.

> Regards.

Thanks for checking.

Joseph


signature.asc
Description: PGP signature

Re: Are these Emacs ports still useful?

[Joseph Mingrone]

Joseph Mingrone  writes:
> - japanese/egg-canna/Makefile (does not build with emacs versions >= 23)
> - japanese/migemo-emacs23

Are you Ok if I remove these ports immediately, since Emacs version 23 was 
removed from the
ports tree in 2014.

Joseph


signature.asc
Description: PGP signature

print/textinfo fails to build due to size mismatch after htmlxref.cnf changed

[Joseph Mingrone]

print/texinfo % make extract
===>  License GPLv3+ accepted by the user
===>   texinfo-6.5,1 depends on file: /usr/local/sbin/pkg - found
...
=> htmlxref.cnf doesn't seem to exist in /usr/ports/distfiles/texinfo/6.5.
=> Attempting to fetch http://ftpmirror.gnu.org/texinfo/htmlxref.cnf
fetch: http://ftpmirror.gnu.org/texinfo/htmlxref.cnf: size mismatch: expected 
20137, actual 20118
...

From print/texinfo/Makfile
MASTER_SITES=   GNU \
LOCAL/sunpoet/${DIST_SUBDIR}:DEFAULT,local
DISTFILES=  ${DISTNAME}${EXTRACT_SUFX} htmlxref.cnf texi2dvi:local 
texinfo.tex:local

It is odd that they distribute these files separately and unversioned.


signature.asc
Description: PGP signature

Re: print/textinfo fails to build due to size mismatch after htmlxref.cnf changed

[Joseph Mingrone]

Marco Beishuizen  writes:

> On Tue, 26 Dec 2017, the wise Joseph Mingrone wrote:

>> print/texinfo % make extract
>> ===>  License GPLv3+ accepted by the user
>> ===>   texinfo-6.5,1 depends on file: /usr/local/sbin/pkg - found
>> ...
>> => htmlxref.cnf doesn't seem to exist in /usr/ports/distfiles/texinfo/6.5.
>> => Attempting to fetch http://ftpmirror.gnu.org/texinfo/htmlxref.cnf
>> fetch: http://ftpmirror.gnu.org/texinfo/htmlxref.cnf: size mismatch: 
>> expected 20137, actual 20118
>> ...

>> From print/texinfo/Makfile
>>  MASTER_SITES=   GNU \
>>  LOCAL/sunpoet/${DIST_SUBDIR}:DEFAULT,local
>>  DISTFILES=  ${DISTNAME}${EXTRACT_SUFX} htmlxref.cnf texi2dvi:local 
>> texinfo.tex:local

>> It is odd that they distribute these files separately and unversioned.


> Hi,

> This has happened before, see:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209228

> I always solved it by downloading the file with the correct size somewhere 
> else on the internet.

> Regards,
> Marco

Hi Marco,

Another workaround is to do `make makesum` to rebuild distinfo after you
are satisfied that the new file is safe.  But, users who build their own
packages should not have to jump through these hoops.  If the file can
change without notice from this source, should it should be fetched from
this source?


signature.asc
Description: PGP signature

Re: Are these Emacs ports still useful?

[Joseph Mingrone]

Liu Dryice  writes:

> On 24 Dec 2017, 05:29 +0800, Joseph Mingrone , wrote:

> - deskutils/etask (non-mirrored tarball dead since 2007)

> This is still fetchable from distcache. Though I admit I haven't used
> it and haven't heard about it for quite a long time.

I see reports that patches were required to get it working with Emacs
21, so I wonder how well it works 10 years later?  Choice is good, but I
suspect that it would be best to point Emacs users looking for task
management to something reasonably maintained like org-mode.  If you
disagree, could you try it out and report back whether it is working and
still useful?

> - editors/tree-widget (part of emacs since 2007)

> This was added for devel/xtla (Emacs mode for tla/gnu arch). Now
> devel/xtla is gone and tree-widget is in Emacs. I guess it's OK to be
> removed.

Removed.

> - textproc/emacs-wiki (last release from 2006)
>  - textproc/muse (last release from 2010)

> They are superceded by org-mode but there are people like me keeping
> old files and diaries written with them. I'd suggest we keep them.

Sounds good.

> - textproc/htmlize.el (500 from MASTER_SITES; fetchable from distcache)

> New version is at https://github.com/hniksic/emacs-htmlize, I'll
> update it

Thanks for your feedback.

Joseph


signature.asc
Description: PGP signature

Call for testing: Emacs flavors and cleanup

[Joseph Mingrone]

There is a review for proposed changes to Emacs ports.

https://reviews.freebsd.org/D13506

Could you reply to the review if you have any concerns or notice any
run-time issues as a result of these changes?

Thanks,

Joseph

[1] A port with USE_EMACS=yes (proposed to be USES=emacs)


signature.asc
Description: PGP signature

Re: Are these Emacs ports still useful?

[Joseph Mingrone]

Hajimu UMEMOTO  writes:
>>>>>> On Sun, 24 Dec 2017 12:12:44 -0400
>>>>>> Joseph Mingrone  said:

>> - japanese/egg-canna/Makefile (does not build with emacs versions >= 23)
>> - japanese/migemo-emacs23

> jrm> Are you Ok if I remove these ports immediately, since Emacs version 23 
> was removed from the
> jrm> ports tree in 2014.

> As for japanese/egg-canna, since there is no working emacs with it any
> more, it's okay to remove it.

While japanese/migemo-emacs23 (now japanese/migemo-emacs) builds
successfully, I am increasingly suspicious that it has passed its
usefulness.  For example, during the build there are messages about
obsolete and missing elisp functions.  Moreover, the port itself seems
broken.  Many of the variable definitions in
japanese/migemo-emacs/Makefile are overwritten by the master port.

/usr/ports/japanese % grep _DEPENDS migemo-emacs/Makefile
BUILD_DEPENDS= apel${EMACS_PKGNAMESUFFIX}>=10.8:editors/apel@${EMACS_FLAVOR}
RUN_DEPENDS= apel${EMACS_PKGNAMESUFFIX}>=10.8:editors/apel@${EMACS_FLAVOR} \

/usr/ports/japanese % make -C migemo-emacs -VBUILD_DEPENDS -VRUN_DEPENDS
/usr/local/lib/ruby/site_ruby/2.4/romkan.rb:japanese/ruby-romkan  
/usr/local/lib/ruby/site_ruby/2.4/bsearch.rb:devel/ruby-bsearch 
/usr/local/bin/ruby24:lang/ruby24 /usr/local/bin/emacs-25.3:editors/emacs@full 
autoconf-2.69:devel/autoconf  autoheader-2.69:devel/autoconf  
autoreconf-2.69:devel/autoconf  aclocal-1.15:devel/automake  
automake-1.15:devel/automake
/usr/local/lib/ruby/site_ruby/2.4/romkan.rb:japanese/ruby-romkan  
/usr/local/lib/ruby/site_ruby/2.4/bsearch.rb:devel/ruby-bsearch 
/usr/local/bin/ruby24:lang/ruby24 /usr/local/bin/emacs-25.3:editors/emacs@full

I will mark it as deprecated and set an expiration date.  Please speak
up if you believe it is still useful!

Joseph


signature.asc
Description: PGP signature

build errors after upgrading editors/emacs to version 26.1

[Joseph Mingrone]

Hello maintainers,

Poudriere tests of all 'USES=emacs' ports with the latest editors/emacs
(version 26.1) resulted in the following errors in either 10i386 or
11amd64 jails:

editors/tamago (hrs@)
mail/mu4e (hrs@)
japanese/mozc-server (hrs@)
deskutils/howm (kuriyama@)
net/tramp (kuriyama@)
databases/bbdb (dryice@)
graphics/xface.el (ports@)
japanese/yc.el (t...@nakao.org)
net-im/jabber.el (max.n.boya...@gmail.com)
www/emacs-w3m (nobutaka@)

Follow these URL for details:
http://pkg.awarnach.mathstat.dal.ca/build.html?mastername=10i386-default&build=2018-05-29_16h46m12s
http://pkg.awarnach.mathstat.dal.ca/build.html?mastername=11amd64-default&build=2018-05-29_13h08m46s

https://reviews.freebsd.org/D15044

Unless I hear any objections, I will likely go ahead with the
editors/emacs update tomorrow afternoon (UTC) and will mark these ports
as BROKEN.

Joseph


signature.asc
Description: PGP signature

Re: unbound / automake ports circula logical error

[Joseph Mingrone]

Joseph Mingrone  writes:

> The Doctor  writes:

>> Looks like in any of the autoconf / automake circular error.

>> > Compressing man pages (compress-man)
>> ===>>> Starting check for runtime dependencies
>> ===>>> Gathering dependency list for devel/automake from ports
>> ===>>> Dependency check complete for devel/automake

>> ===>>> dns/unbound 2/2 >> devel/automake (2/2)

>> ===>  Installing for automake-1.16.1
>> ===>  Checking if automake already installed
>> ===>   Registering installation for automake-1.16.1
>> Installing automake-1.16.1...
>> pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203 
>> (installs files into the same place).  Problematic file: 
>> /usr/local/bin/aclocal
>> *** Error code 70

>> Stop.
>> make: stopped in /usr/ports/devel/automake

>> The circular error comes when you try to remove autoconf-wrapper
>> and correct autoconf.

>> This is unacceptably ridiculous.

>> Please remedy this within 24 hours.

Re-sending to the list.

> Hello "The Doctor",

> I just tested dns/unbound in a poudriere 11amd64 jail and there were no
> problems [1].  If you insist on building your own packages, and if you
> insist on building them in an unclean (live) environment, expect to get
> your hands dirty.  Trying to account for the many quirks of a live
> system makes the job of building and maintaining packages harder.  The
> nice thing about poudriere is that things are built in a clean
> environment.

> Please keep in mind that this is a volunteer effort.  If you find
> something "unacceptably ridiculous", please consider chipping in rather
> than demanding action from volunteers.

> Patches welcome,

> Joseph

> [1] 
> http://pkg.awarnach.mathstat.dal.ca//data/11amd64-default/2018-06-15_13h14m33s/logs/unbound-1.7.2.log



signature.asc
Description: PGP signature

Re: Removing git dependencies on perl5 and python27

[Joseph Mingrone]

Mahmoud Al-Qudsi  writes:
> Do you know what features python unlocks?

I am not sure, but grepping gives some hints.

% pkg info -lq git-2.17.1 | xargs grep -l '^#!.*python'
/usr/local/bin/git-p4.py
/usr/local/libexec/git-core/git-p4
/usr/local/share/git-core/contrib/fast-import/import-zips.py
/usr/local/share/git-core/contrib/hg-to-git/hg-to-git.py
/usr/local/share/git-core/contrib/hooks/multimail/git_multimail.py
/usr/local/share/git-core/contrib/hooks/multimail/migrate-mailhook-config
/usr/local/share/git-core/contrib/hooks/multimail/post-receive.example
/usr/local/share/git-core/contrib/svn-fe/svnrdump_sim.py

J.


signature.asc
Description: PGP signature

Re: FreeBSD Port: R-3.6.2

[Joseph Mingrone]

"Joel Rodriguez"  writes:

> Hello,



> I am having trouble building the latest version of R. The build is
> complaining:



> Fatal error: cannot create 'R_TempDir'



> I have reviewed my /tmp directory and cleaned it out to no avail. Nothing
> under a google search seems relevant(pretty much all windows stuff).



> Any suggestions?



> Thanks in advance.



> Joel


Hello Joel,

Are any of 'TMPDIR', 'TMP', or 'TEMP' set in the build environment?  Do
you have anything in the user's ~/.Renviron ?  Maybe you could share a
link to the full build log.

What do `ls -ld /tmp` and `df -h /tmp` report?

Joseph


signature.asc
Description: PGP signature

math/R: Upcoming major version update

[Joseph Mingrone]

Hello all,

You are receiving this message because you maintain a port that has a
run-time dependency on math/R.  This is a heads-up that math/R will be
updated to version 4.0.0.  As this is a major version change, R packages
will also need to be rebuilt.  Unless there are some unforeseen
problems, I will try to do this update tomorrow.  I will also do a
PORTREVISION bump for these dependent ports.  Please let me know if this
is a problem.

https://reviews.freebsd.org/D24572

Regards,

Joseph


signature.asc
Description: PGP signature

Re: math/R: Upcoming major version update

[Joseph Mingrone]

Jason Bacon  writes:

> On 2020-04-25 22:50, Joseph Mingrone wrote:
>> Hello all,

>> You are receiving this message because you maintain a port that has a
>> run-time dependency on math/R.  This is a heads-up that math/R will be
>> updated to version 4.0.0.  As this is a major version change, R packages
>> will also need to be rebuilt.  Unless there are some unforeseen
>> problems, I will try to do this update tomorrow.  I will also do a
>> PORTREVISION bump for these dependent ports.  Please let me know if this
>> is a problem.

>> https://reviews.freebsd.org/D24572

>> Regards,

>> Joseph

> Thanks for your work on this!

> Do you have any estimate of how many R-cran packages this might break?  I've 
> seen some that are persnickety about R versions and I suspect a new 
> major version will cause some issues.

> Perhaps we can investigate this and head off problems before the new R 
> version is committed.

> Cheers,

>     JB

No rush.  We can wait a bit.  There could be some run-time breakage [1] .  I 
can do build tests.

J.

[1] * R now uses a stringsAsFactors = FALSE default, and hence by
  default no longer converts strings to factors in calls to
  data.frame() and read.table().

  A large number of packages relied on the previous behaviour and
  so have needed/will need updating.


signature.asc
Description: PGP signature

FreeBSD Port: emacs-23.4_2,1

[Joseph Mingrone]

Hi ashish;

After upgrading to 23.4 from 23.3 I'm seeing errors with with faces
and term-mode is not functional.  The build output can be found here:
http://gly.ath.cx/misc/emacs_build.out.
I suspect the lines below are related to the problem.

===>>> Creating a backup package for old version emacs-24.3,3
Creating package for emacs-24.3,3
pkg: (emacs-24.3,3) /usr/local/bin/emacs - shared library
libncurses.so.5.9 not found
pkg: (emacs-24.3,3) /usr/local/bin/emacs - shared library
libtinfo.so.5.9 not found
pkg: (emacs-24.3,3) /usr/local/bin/emacs-24.3 - shared library
libncurses.so.5.9 not found
pkg: (emacs-24.3,3) /usr/local/bin/emacs-24.3 - shared library
libtinfo.so.5.9 not found

I can confirm that devel/ncurses is installed (5.9_1).

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: emacs-23.4_2,1

[Joseph Mingrone]

Hi Ashish;

It looks like the problem was caused by this line:

(setq ansi-term-color-vector [unspecified "black" "red3" "green3"
"yellow3" "DodgerBlue1" "magenta3" "cyan3" "white"])

which I used to set colours in term/multi-term.

It looks like other people hit the same problem when upgrading to 24.3.

In any case, my apologies for bugging you with something unrelated to the port.


Thanks,

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Another Firefox 21.0 crash

[Joseph Mingrone]

Ted Faber  writes:

> I'm seeing a repeatable, consistent segmentation fault before the first
> window appears (though firefox -ProfileManager brings up the
> profile manager, but crashes when I try to actually start the browser).
>
> I've deleted ~/.mozilla and just about everything I can think to get rid
> of.  
>
> The system is a 9.1 i386 system: FreeBSD ylum.lunabase.org 9.1-STABLE
> FreeBSD 9.1-STABLE #28 r250528: Sat May 11 17:19:54 PDT 2013
> r...@ylum.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386
>

I had a 9.1-STABLE i368 (sources grabbed a few months ago) and I was
seeing the same problems.  flo on irc suggested trying with gcc46 and
that worked.  Just put USE_GCC = 4.6 in the port's makefile.

Joseph

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Another Firefox 21.0 crash

[Joseph Mingrone]

Ted Faber  writes:
> gcc46 gives me a compilation error:
>
> /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream.cpp:
>  In member function 'virtual nsresult nsMultiplexInputStream::Seek(int32_t, 
> int64_t)':
> /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream.cpp:532:86:
>  error: no matching function for call to 'XPCOM_MIN(int64_t&, 
> __gnu_cxx::__enable_if::__type)'
> /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream.cpp:532:86:
>  note: candidate is:
> ../../dist/include/nsAlgorithm.h:34:1: note: template const
> T& XPCOM_MIN(const T&, const T&)

I'm on 9.1-STABLE #0 r246915 and configured firefox as follows:
Options: 
DBUS: off
DEBUG: off
GCONF: off
GIO: off
GNOMEUI: off
GNOMEVFS2: off
GSTREAMER: on
LIBPROXY: off
LOGGING: off
OPTIMIZED_CFLAGS: off
PGO: off
WEBRTC: off
ALSA: off
OSS: on
PULSEAUDIO: off

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD ports which are currently scheduled for deletion

[Joseph Mingrone]

Hi;

lini...@freebsd.org writes:

> The ports, and the reason and date that they have been scheduled
> for removal, are listed below.  If no one has stepped forward before
> that time to propose a way to fix the problems (such as via a PR),
> the ports will be deleted.
>

> portname:   sysutils/sge62
> description:Sun Grid Engine, a batch queueing system
> maintainer: po...@freebsd.org
> deprecated because: Ancient and unsupported release
> expiration date:2013-03-01
> build errors:
> http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/sge-6.2.2.1_3.log
>  (Mar 14 02:20:26 UTC 2013)
> overview:
> http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=sge62

Our group relies heavily on this port and it compiles and works for us.
Is it possible to reconsider this removal?  I don't see an alternative
in the ports tree?

Thanks,

Joseph

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: lang/sbcl

[Joseph Mingrone]

Hi,

After upgrading sbcl to 1.1.12, stumpwm no longer compiles.  I'm
compiling stumpwm from the git repository, which hasn't changed in quite
awhile.

If there is anything I can test or any other information I can provide,
please let me know.

Joseph

% gmake
/usr/local/bin/sbcl --load ./make-image.lisp
This is SBCL 1.1.12, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
WARNING:
   compiling # completed without its input 
file #P"/usr/local/lib/sbcl/sb-bsd-sockets/NEWS"
WARNING:
   loading # completed without its input 
file #P"/usr/local/lib/sbcl/sb-bsd-sockets/NEWS"
WARNING:
   compiling # completed without its input 
file #P"/usr/local/lib/sbcl/sb-bsd-sockets/TODO"
WARNING:
   loading # completed without its input 
file #P"/usr/local/lib/sbcl/sb-bsd-sockets/TODO"

debugger invoked on a ASDF/FIND-SYSTEM:MISSING-COMPONENT:
  Component STUMPWM not found

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY   ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file 
"/usr/home/jrm/scm/stumpwm.git/./make-image.lisp".
  2: [ABORT   ] Abort loading file 
"/usr/home/jrm/scm/stumpwm.git/./make-image.lisp".
  3:Ignore runtime option --load "./make-image.lisp".
  4:Skip rest of --eval and --load options.
  5:Skip to toplevel READ/EVAL/PRINT loop.
  6: [EXIT] Exit SBCL (calling #'EXIT, killing the process).

((:METHOD ASDF/OPERATE:OPERATE (SYMBOL T)) ASDF/LISP-ACTION:LOAD-OP STUMPWM) 
[fast-method]
0] 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Considering removal of math/libR and math/libRmath

[Joseph Mingrone]

Hello,

Neither of these ports are depended on by other ports and the option to include
libR with math/R is already there (with an option).  Is anyone using either of
these ports?  Do you foresee any problems if they are swallowed by math/R?

Joseph


signature.asc
Description: PGP signature

Re: Considering removal of math/libR and math/libRmath

[Joseph Mingrone]

Fernando Herrero Carrón  writes:
> From math/R's perspective it would be nice to see them go away. The
> Makefile handling of both is somewhat cumbersome as it stands.

The cumbersome handling of the slave ports was changed in math/R.  See 210866.

See 210990 and 210987 for possible changes to math/libR and math/libRmath.

Joseph


signature.asc
Description: PGP signature

math/R slave ports and shared library

[Joseph Mingrone]

After some surgery, math/R is in more manageable shape.  But, the surgery broke 
two slave ports, math/libR and math/libRmath.  They have each been marked 
broken since June or July and I posted to ports@ about deleting them, but 
didn't get a response.

math/libRmath
I'm not sure how widely used math/libRmath is today, but it's still described 
in R's main installation document 
(https://cran.r-project.org/doc/manuals/r-release/R-admin.html#The-standalone-Rmath-library).
  It *should* be straightforward to just incorporate math/libRmath's four files 
into math/R and then delete math/libRmath.  The directory for libRmath is under 
WRKSRC, but it's not included in the main Makefile, so I'd have to either patch 
the main Makefile or do something with post-build and post-install.  Is this 
palatable?

---
post-build:
${SETENV} ${MAKE_ENV} ${MAKE_CMD} -C ${WRKSRC}/src/nmath/standalone

post-install
.for f in libRmath.a libRmath.so libRmath.so.${RMATH_SOVERSION}
${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/${f} ${STAGEDIR}/lib/
.endfor 
${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/Rmath.h 
${STAGEDIR}/include/
---

math/libR
Right now, unlike upstream, math/R's shared library option is turned on by 
default.  This was done only in late June because a dependency, 
math/rkward-kde4, required it.  Upstream turns it off, for the reasons 
described in [1].  I'm inclined to remove the libR option from math/R's 
OPTIONS_DEFAULT and resurrect math/libR (or maybe math/R-libR by using 
PKGNAMESUFFIX) as a very simple slave port that just installs math/R with that 
option on.  math/rkward-kde4 could then depend on math/libR.  One issue is 
that, I believe, R's installed packages (packages installed from within R) and 
many of R's dependencies would have to be rebuilt after turning off the libR 
option.

Opinions?

Joseph

[1] "--enable-R-shlib causes the make process to build R as a dynamic (shared) 
library, typically called libR.so, and link the main R executable R.bin against 
that library. This can only be done if all the code (including system 
libraries) can be compiled into a dynamic library, and there may be a 
performance [47] penalty. So you probably only want this if you will be using 
an application which embeds R. Note that C code in packages installed on an R 
system linked with --enable-R-shlib is linked against the dynamic library and 
so such packages cannot be used from an R system built in the default way. 
Also, because packages are linked against R they are on some OSes also linked 
against the dynamic libraries R itself is linked against, and this can lead to 
symbol conflicts."

[47] We have measured 15-20% on i686 Linux and around 10% on x86_64 Linux.


signature.asc
Description: PGP signature

Re: math/R slave ports and shared library

[Joseph Mingrone]

Fernando Herrero Carrón  writes:
> All in all, I don't see much use for a standalone libRmath, but it cannot
> be excluded. The truth being told, I would expect newer scientific software
> coming from python+scipy+numpy rather than from R embedded in C/C++.

Given that 1) the port has been marked broken for so long and 2) only you 
responded to the last call for deletion back in July with a similar response, 
I'm feeling more comfortable about removing math/libRmath.

> math/libR
> I have done some little benchmarking myself with and without dynamic libR
> and have not seen any noticeable differences in performance (though I have
> left it off to be safe), but don't take this as conclusive, more testing
> should be done. Packages certainly do need to be rebuilt after switching
> from dynamic libR to static. I can't tell what happens the other way
> around. Ports-installed packages could be automatically recompiled, but
> recompiling user-installed packages is a different story.

> I think having two separate installations, whose packages would be mutually
> exclusive is too dangerous and too easy for the user to mess up. I can
> perform some more extensive benchmarks and see if having it enabled by
> default really hurts.

The same applies for math/libR.  For now, users who don't want the shared 
library can easily build their own port.

Thanks for your input Fernando,

Joseph


signature.asc
Description: PGP signature

net/wpa-gui: pkg-message

[Joseph Mingrone]

The message says wpa-gui "expects the running wpa_supplicant from the port
security/wpa_supplicant".  When I tested, it seemed to work fine with the base
wpa_supplicant.  Is the note still necessary?

Thanks,

Joseph


signature.asc
Description: PGP signature

FreeBSD Port: ghc-7.10.2_1

[Joseph Mingrone]

Hello,

Building lang/ghc fails in poudriere (11 jail).

http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2016-11-30_23h22m02s/logs/errors/ghc-7.10.2_1.log

Joseph


signature.asc
Description: PGP signature

FreeBSD Port: octave-3.8.1_2

[Joseph Mingrone]

Hello,

Building octave on a laptop (i5/8G ram running 9.2-STABLE amd64) seems
to run indefinitely (e.g. overnight and it's still building), but on a
similarly configured desktop (9.2-STABLE 32G ram) it takes no time
(15-20 minutes).  Here is a log from the build on the laptop:
https://ftfl.ca/octave_3.8.1_2_build_log.txt.

Once the build is killed, the following is output:

mv -f corefcn/.deps/corefcn_libtex_parser_la-oct-tex-parser.Tpo 
corefcn/.deps/corefcn_libtex_parser_la-oct-tex-parser.Plo
mv: rename corefcn/.deps/corefcn_libtex_parser_la-oct-tex-parser.Tpo to 
corefcn/.deps/corefcn_libtex_parser_la-oct-tex-parser.Plo: No such file or 
directory
gmake[3]: *** [corefcn/corefcn_libtex_parser_la-oct-tex-parser.lo] Error 1
gmake[3]: Leaving directory 
`/wrkdirs/usr/ports/math/octave/work/octave-3.8.1/libinterp'
gmake[2]: *** [all] Error 2
Killed

I tried turning off tmpfs and setting vfs.zfs.arc_max to 500M, but it
didn't make any difference.

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Packages with versions in their names (e.g. py37- or -emacs26-)

[Joseph Mingrone]

The major version of editors/emacs will soon be updated from 26 to 27.
This means, with the way our flavored packages are now named, packages
like pdf-tools-emacs26-0.90.41 will change to pdf-tools-emacs27-0.90.41.

If users just do `pkg upgrade`, even with a PORTREVISION bump,
pdf-tools-emacs26-0.90.41, e.g., will not be upgraded.  Users must first
do something like

   pkg set -yn "pdf-tools-emacs26-0.90.41":"pdf-tools-emacs27-0.90.41"

I can think of a few ways we could make it, so that users do not have to
complete this extra `pkg set -yn...` step.

1. Change the way the packages are named, so that the Emacs major
version is not included in the package name.  We could change the
packages name like this:

- pdf-tools-emacs27-0.90.41 -> pdf-tools-emacs-0.90.41
- pdf-tools-emacs28-0.90.41 -> pdf-tools-emacs-devel-0.90.41
- tablist-emacs28_nox-1.0_2 -> tablist-emacs-devel_nox-1.0_2
- auctex-emacs26_canna-12.2 -> auctex-emacs_canna-12.2

The downside to this solution is that it's more churn and some package
names would become longer.

2. Hack up pkg, so that it somehow recognizes, that for the same port
origin, only emacs26 changed to emacs27 in the package name, so do the
upgrade.  I am not familiar with pkg's internals, so there may be
constraints that I'm not aware of.

3. Automatically run the `pkg set -yn..` command when emacs is upgraded.
This is probably a bad idea.

Maybe it's best to just continue with the way things are?

What do you think?

Joe


signature.asc
Description: PGP signature

FreeBSD Port: grpc-1.22.0_4,2

[Joseph Mingrone]

Hi Sunpoet,

Are we able to update devel/grpc?

I can see from the commit logs that there were some constraints with
updates in the past, but we are now running into trouble, because other
ports in the tree require newer versions of grpc.  For example,
devel/bear requires gRPC >= 1.26.  If necessary, I can /try/ to create a
separate port, say devel/grpc13.

Regards,

Joseph


signature.asc
Description: PGP signature

Re: FreeBSD Port: grpc-1.22.0_4,2

[Joseph Mingrone]

On Tue, 2020-10-06 at 07:21, Matthias Fechner  wrote:

> Dear Joseph,

> Am 05.10.2020 um 18:58 schrieb Joseph Mingrone:
>> Are we able to update devel/grpc?

>> I can see from the commit logs that there were some constraints with
>> updates in the past, but we are now running into trouble, because other
>> ports in the tree require newer versions of grpc.  For example,
>> devel/bear requires gRPC >= 1.26.  If necessary, I can/try/  to create a
>> separate port, say devel/grpc13.

> maybe you want to help, there is currently an issue with grpc, please see 
> here:
> https://github.com/grpc/grpc/issues/22845

> I currently test a rubygem-grpc update I received from sunpoet, but have 
> currently another problem, that blocks me from continue testing:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250140

> So if you want to help us, you are more than welcome ;)

> Gruß
> Matthias

Hello Matthias and Sunpoet,

Thanks for filling me in.  It looks like you made progress on bug
#250140.  It's a shame that upstream grpc won't do more to support
FreeBSD.

Joe


signature.asc
Description: PGP signature

emacssurvey.org

[Joseph Mingrone]

Hello all,

Emacs ports maintainers here. Over the past few years we have made some
changes to the Emacs ports, which hopefully improve the user
experience. For example, we now update editors/emacs-devel to the latest
upstream commit about every two weeks and we eat our own dog
food. Thanks to users, we were able to catch and report bugs before they
could reach a stable release. Upstream has been receptive to our
reports, though few if any core Emacs developers run FreeBSD. If you
care about Emacs on FreeBSD, please let the Emacs community know by
filling out the Emacs Survey at

emacssurvey.org.

It's open until November 30.

Regards,

Ashish and Joe


signature.asc
Description: PGP signature

Re: [CFT] editors/emacs to 24.1

[Joseph Mingrone]

Hello Ashish;

The patches applied successfully and the port installation was also
successful, but when I try to run emacs with emacsclient -c, my system
becomes semi-unresponsive.  I can still hit the power button on my
laptop for a clean shutdown but a C-c won't stop emacs and I can't log
out of X.  My best guess is this is related to the new Intel driver
with GEM/KMS (although this has been my first problem after running it
for a few months).  Running emacsclient -t works fine.  If I start
emacs with just "% emacs", and I don't wait to long, I can kill it
with a C-c and the warning/error messages below appear in xterm:

% emacs
^C
(process:1589): GLib-WARNING **: In call to g_spawn_sync(), exit
status of a child process was requested but SIGCHLD action was set to
SIG_IGN and ECHILD was received by waitpid(), so exit status can't be
returned. This is a bug in the program calling g_spawn_sync(); ei
ther don't request the exit status, or don't set the SIGCHLD action.

(process:1589): GLib-GIO-CRITICAL **: g_dbus_connection_add_filter:
assertion `G_IS_DBUS_CONNECTION (connection)' failed


I'm on 9.0-STABLE amd64.

Please let me know if I can provide any other information.

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] editors/emacs to 24.1

[Joseph Mingrone]

On Mon, Jul 30, 2012 at 6:09 AM, Ashish SHUKLA  wrote:
> Could you please provide contents of /var/db/ports/emacs/options ? I'm not
> sure if it's to do with Intel GEM/KMS, but I remember seeing it with
> SYNC_INPUT=off as well, as Raphael pointed out in his earlier reply.

I turned off gconf and switched to using xaw (I turn off the menu bar
and the tool bar so I use the lightest option for X widgets).

% cat /var/db/ports/emacs/options
# This file is auto-generated by 'make config'.
# Options for emacs-24.1,2
_OPTIONS_READ=emacs-24.1,2
_FILE_COMPLETE_OPTIONS_LIST=CANNA DBUS GCONF GIF GNUTLS GSETTINGS JPEG
M17N MAGICK OTF PNG SCROLLBARS SOUND SOURCES SVG SYNC_INPUT TIFF XFT
XIM XML XPM GTK2 GTK3 XAW XAW3D MOTIF
OPTIONS_FILE_UNSET+=CANNA
OPTIONS_FILE_SET+=DBUS
OPTIONS_FILE_UNSET+=GCONF
OPTIONS_FILE_SET+=GIF
OPTIONS_FILE_SET+=GNUTLS
OPTIONS_FILE_SET+=GSETTINGS
OPTIONS_FILE_SET+=JPEG
OPTIONS_FILE_SET+=M17N
OPTIONS_FILE_SET+=MAGICK
OPTIONS_FILE_SET+=OTF
OPTIONS_FILE_SET+=PNG
OPTIONS_FILE_SET+=SCROLLBARS
OPTIONS_FILE_SET+=SOUND
OPTIONS_FILE_SET+=SOURCES
OPTIONS_FILE_SET+=SVG
OPTIONS_FILE_SET+=SYNC_INPUT
OPTIONS_FILE_SET+=TIFF
OPTIONS_FILE_SET+=XFT
OPTIONS_FILE_SET+=XIM
OPTIONS_FILE_SET+=XML
OPTIONS_FILE_SET+=XPM
OPTIONS_FILE_UNSET+=GTK2
OPTIONS_FILE_UNSET+=GTK3
OPTIONS_FILE_SET+=XAW
OPTIONS_FILE_UNSET+=XAW3D
OPTIONS_FILE_UNSET+=MOTIF
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] editors/emacs to 24.1

[Joseph Mingrone]

On Mon, Jul 30, 2012 at 11:25 AM, Herbert J. Skuhra  wrote:
> Two options:
>
> 1) Try to build Emacs without dbus/gconf/gsettings.
>
> 2) Launch dbus properly:
>
> I run fvwm2 and I had to add the following line to my ~/.xinitrc:
>
> exec ck-launch-session dbus-launch --exit-with-session fvwm2
>

Thanks Herbert;

Both options worked.  Does that mean if one wanted to run dbus, the
script in /usr/local/etc/rc.d/ isn't necessary?

Ashish, when building with the dbus, gconf and gtk options turned off,
emacs still depends on the dbus/gconf2/gtk2 ports.  Is this intended?

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] editors/emacs to 24.1

[Joseph Mingrone]

On Mon, Jul 30, 2012 at 4:37 PM, Ashish SHUKLA  wrote:
> On Mon, 30 Jul 2012 15:00:25 -0300, Joseph Mingrone  said:
>> Ashish, when building with the dbus, gconf and gtk options turned off,
>> emacs still depends on the dbus/gconf2/gtk2 ports.  Is this intended?
>
> No, that's not intended. Could you paste output of following command-lines?
>
> % make -V CONFIGURE_ARGS
> % make -V USE_GNOME
> % make -V BUILD_DEPENDS
> % cat /var/db/ports/emacs/options

% make -V CONFIGURE_ARGS
--localstatedir=/var --with-x-toolkit=athena --without-xaw3d
--with-xft --with-m17n-flt --with-otf --with-imagemagick
--without-gsettings --without-gconf --with-xim --with-sound
--without-dbus --with-xml2 --with-gnutls
--x-libraries=/usr/local/lib --x-includes=/usr/local/include
--prefix=/usr/local ${_LATE_CONFIGURE_ARGS}

% make -V USE_GNOME
librsvg2 libxml2

% make -V BUILD_DEPENDS
gmake:/usr/ports/devel/gmake
/usr/local/libdata/pkgconfig/xaw7.pc:/usr/ports/x11-toolkits/libXaw
/usr/local/libdata/pkgconfig/xpm.pc:/usr/ports/x11/libXpm
/usr/local/libdata/pkgconfig/xft.pc:/usr/ports/x11-fonts/libXft
/usr/local/bin/intltool-extract:/usr/ports/textproc/intltool
pkgconf:/usr/ports/devel/pkgconf

cat /var/db/ports/emacs/options
# This file is auto-generated by 'make config'.
# Options for emacs-24.1,2
_OPTIONS_READ=emacs-24.1,2
_FILE_COMPLETE_OPTIONS_LIST=CANNA DBUS GCONF GIF GNUTLS GSETTINGS JPEG
M17N MAGICK OTF PNG SCROLLBARS SOUND SOURCES SVG SYNC_INPUT TIF
F XFT XIM XML XPM GTK2 GTK3 XAW XAW3D MOTIF
OPTIONS_FILE_UNSET+=CANNA
OPTIONS_FILE_UNSET+=DBUS
OPTIONS_FILE_UNSET+=GCONF
OPTIONS_FILE_SET+=GIF
OPTIONS_FILE_SET+=GNUTLS
OPTIONS_FILE_UNSET+=GSETTINGS
OPTIONS_FILE_SET+=JPEG
OPTIONS_FILE_SET+=M17N
OPTIONS_FILE_SET+=MAGICK
OPTIONS_FILE_SET+=OTF
OPTIONS_FILE_SET+=PNG
OPTIONS_FILE_SET+=SCROLLBARS
OPTIONS_FILE_SET+=SOUND
OPTIONS_FILE_SET+=SOURCES
OPTIONS_FILE_SET+=SVG
OPTIONS_FILE_SET+=SYNC_INPUT
OPTIONS_FILE_SET+=TIFF
OPTIONS_FILE_SET+=XFT
OPTIONS_FILE_SET+=XIM
OPTIONS_FILE_SET+=XML
OPTIONS_FILE_SET+=XPM
OPTIONS_FILE_UNSET+=GTK2
OPTIONS_FILE_UNSET+=GTK3
OPTIONS_FILE_SET+=XAW
OPTIONS_FILE_UNSET+=XAW3D
OPTIONS_FILE_UNSET+=MOTIF
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] editors/emacs to 24.1

[Joseph Mingrone]

I should also mention that I'm using pkgng in case it's relevant.

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] editors/emacs to 24.1

[Joseph Mingrone]

On Mon, Jul 30, 2012 at 5:10 PM, Ashish SHUKLA  wrote:
> There is nothing here which hints at gconf2/gtk2/dbus being used. Why do you
> think those options are used or Emacs depends on them?

% pkg info -d emacs (note there is no underscore, that the pkgng tool)
emacs-24.1,2 depends on:
ImageMagick-6.7.8.6
ORBit2-2.14.19
atk-2.0.1
bitstream-vera-1.10_5
cairo-1.10.2_4,2
compositeproto-0.4.2
damageproto-1.2.1
dbus-glib-0.94
dbus-1.4.14_3
dconf-0.5.1_4
djvulibre-3.5.25.3
eggdbus-0.6_1
encodings-1.0.4,1
expat-2.0.1_2
fftw3-3.3.2
fixesproto-5.0
font-bh-ttf-1.0.3
font-misc-ethiopic-1.0.3
font-misc-meltho-1.0.3
font-util-1.2.0
fontconfig-2.9.0,1
freetype2-2.4.9_1
fribidi-0.19.2_1
gamin-0.1.10_4
gconf2-2.32.0_3
gd-2.0.35_8,1
gdk-pixbuf-2.23.5_3
gettext-0.18.1.1
ghostscript9-9.05_5
giflib-4.2.0_2
gio-fam-backend-2.28.8_1
glib-2.28.8_4
gmp-5.0.5
gnome_subr-1.0
gnomehier-2.3_12
gnutls-2.12.18
gobject-introspection-0.10.8_2
gsfonts-8.11_5
gtk-engines2-2.20.2_1
gtk-update-icon-cache-2.24.6_1
gtk-2.24.6_2
hicolor-icon-theme-0.12
inputproto-2.0.2
jasper-1.900.1_10
jbig2dec-0.11_1
jbigkit-1.6
jpeg-8_3
kbproto-1.0.5
lcms2-2.3
libICE-1.0.7,1
libIDL-0.8.14_1
libSM-1.2.0,1
libX11-1.4.4,1
libXau-1.0.6
libXaw-1.0.9,2
libXcomposite-0.4.3,1
libXcursor-1.1.12
libXdamage-1.1.3
libXdmcp-1.1.0
libXext-1.3.0_1,1
libXfixes-5.0
libXft-2.1.14
libXi-1.4.5,1
libXinerama-1.1.1,1
libXmu-1.1.0,1
libXp-1.0.1,1
libXpm-3.5.9
libXrandr-1.3.2
libXrender-0.9.6
libXt-1.1.1,1
libcroco-0.6.2_1
libffi-3.0.9
libfontenc-1.1.0
libfpx-1.2.0.12_2
libgee-0.6.2.1
libgpg-error-1.10
libgsf-1.14.21_1
libiconv-1.14
libidn-1.22
liblqr-1-0.4.1_2
libltdl-2.4.2
libotf-0.9.12
libpaper-1.1.24_1
libpthread-stubs-0.3_3
librsvg2-2.34.1_1
libtasn1-2.13
libwmf-0.2.8.4_7
libxcb-1.7
libxml2-2.7.8_3
m17n-db-1.6.3
m17n-lib-1.6.3_1
mkfontdir-1.0.6
mkfontscale-1.0.9
nettle-2.5
p11-kit-0.13
pango-1.28.4_1
pcre-8.31
perl-5.16.0
pixman-0.24.2
pkg-config-0.25_1
pkgconf-0.8.5
png-1.5.12
polkit-0.99
printproto-1.0.5
python27-2.7.3_3
randrproto-1.3.2
renderproto-0.11.1
shared-mime-info-1.0_1
svgalib-1.4.3_6
tiff-4.0.2
webp-0.1.3_1
xcb-util-renderutil-0.3.8
xcb-util-0.3.8,1
xextproto-7.2.0
xineramaproto-1.2.1
xorg-fonts-truetype-7.5.1
xproto-7.0.22

> And as you mention you're using pkgng, it's irrelevant unless you're using
> installing from package. Are you?

No, I'm installing from source.

Cheers,

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] editors/emacs to 24.1

[Joseph Mingrone]

Could this be a result of other dependencies pulling in
dbus/gconf/gtk?  For example editors/emacs depends on devel/libgsf and
libgsf depends on dbus/gconf/gtk.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] editors/emacs to 24.1

[Joseph Mingrone]

Hello again Ashish;

I played around with the port options and it does indeed look like
dbus/gconf/gtk were being installed because they were "indirect
dependencies".   For example, with these options selected (shown
below) the run dependencies were limited to

% make run-depends-list
/usr/ports/devel/pkgconf
/usr/ports/graphics/jpeg
/usr/ports/graphics/png
/usr/ports/graphics/tiff
/usr/ports/print/freetype2
/usr/ports/print/libotf
/usr/ports/security/gnutls
/usr/ports/textproc/libxml2
/usr/ports/x11-fonts/libXft
/usr/ports/x11-toolkits/libXaw
/usr/ports/x11/libXpm.

The list no longer contains devel/libgsf, which pulls in
dbus/gconf/gtk.  I was confused when I turned off options like dbus
and saw that it was still getting installed.

Thanks for enduring all my emails and thanks for the hard work
involved with updating the port.

Cheers,

Joseph

% pkg info -f emacs
Name   : emacs
Version: 24.1,2
Origin : editors/emacs
Prefix : /usr/local
Categories : ipv6 editors
Licenses   : GPLv3
Maintainer : ash...@freebsd.org
WWW: http://www.gnu.org/software/emacs/
Comment: GNU editing macros
Options:
CANNA: off
DBUS: off
GCONF: off
GIF: off
GNUTLS: on
GSETTINGS: off
JPEG: on
M17N: off
MAGICK: off
OTF: on
PNG: on
SCROLLBARS: off
SOUND: on
SOURCES: on
SVG: off
SYNC_INPUT: on
TIFF: on
XFT: on
XIM: on
XML: on
XPM: on
GTK2: off
GTK3: off
XAW: on
XAW3D: off
MOTIF: off
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] editors/emacs to 24.1

[Joseph Mingrone]

On Wed, Aug 1, 2012 at 6:39 PM, Ashish SHUKLA  wrote:
> Weird. Do you've any idea from where devel/libgsf was getting included in
> dependencies list?

There were a few different combinations.  One I recall was selecting
the ImageMagick option.  That pulls in devel/libgsf and devel/dbus.
Then devel/libgsf pulls in devel/gconf2 and that's when you get
something like 40 extra ports installed.

I've found the make targets run-depends-list, build-depends-list and
missing are useful.

> No problems. Ports are updated now. Let me know if you see any issues.

So far things are working quite well. :)

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: fusefs-encfs-1.7.4_1

[Joseph Mingrone]

Hello;

I have been using encfs successfully for many months.

% encfs ~/.crypt ~/files/crypt

Today, I tried to mount the same way as usual.  My password was
accepted, but the directory ~/files/crypt disappeared after the mount.
 That is, before the command above I see the ~/files/crypt directory,
but after it doesn't show up with an ls -la.  However, when I do ls
~/files/crypt I see the message "ls: crypt: Bad file descriptor".  The
~/.crypt directory seems unchanged.  The only thing I can think of
that might have changed in the past few days: I may have updated a
dependent port (e.g. /deve/icu).  I'm running 9-STABLE amd64 with port
version 1.7.4_1.

Thanks for any suggestions.

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: fusefs-encfs-1.7.4_1

[Joseph Mingrone]

On Wed, Sep 26, 2012 at 5:42 PM, Joseph Mingrone  wrote:
> Hello;
>
> I have been using encfs successfully for many months.
>
> % encfs ~/.crypt ~/files/crypt
>
> Today, I tried to mount the same way as usual.  My password was
> accepted, but the directory ~/files/crypt disappeared after the mount.
>  That is, before the command above I see the ~/files/crypt directory,
> but after it doesn't show up with an ls -la.  However, when I do ls
> ~/files/crypt I see the message "ls: crypt: Bad file descriptor".  The
> ~/.crypt directory seems unchanged.  The only thing I can think of
> that might have changed in the past few days: I may have updated a
> dependent port (e.g. /deve/icu).  I'm running 9-STABLE amd64 with port
> version 1.7.4_1.
>

It looks like encfs is crashing.

% encfs -d /usr/home/jrm/.crypt /usr/home/jrm/files/crypt
EncFS Password:
FUSE library version: 2.9.1
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
unique: 0, opcode: INIT (26), nodeid: 0, insize: 56, pid: 1426
INIT: 7.19
flags=0x
max_readahead=0x
   INIT: 7.19
   flags=0x0011
   max_readahead=0x
   max_write=0x0002
   max_background=0
   congestion_threshold=0
NOTIFY: code=0 length=40

unique: 0, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 1431
fgetattr[0] /
zsh: segmentation fault (core dumped)  encfs -d /usr/home/jrm/.crypt
/usr/home/jrm/files/crypt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: fusefs-kmod-0.3.9.p1.20080208_7

[Joseph Mingrone]

Hello,

I've been trying to update this port from the 6th to the 7th patch
level, but the error below occurs.  Is this something you've seen
before?  I've seen PR 151296, but it's from last October and I'm not
sure if it is still relevant.  If there is any other information I can
provide. please let know.

Joey

:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk fuse.ko  export_syms | xargs
-J% objcopy % fuse.ko
objcopy --strip-debug fuse.ko
===> mount_fusefs (all)
Warning: Object directory not changed from original
/usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/mount_fusefs
cc -O2 -pipe -fno-strict-aliasing  -I/usr/src/sbin/mount -I../include
-std=gnu99 -fstack-protector  -c mount_fusefs.c
mount_fusefs.c:79: error: 'MNT_NFS4ACLS' undeclared here (not in a function)
mount_fusefs.c: In function 'main':
mount_fusefs.c:400: warning: implicit declaration of function
'init_backgrounded'
*** Error code 1

Stop in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/mount_fusefs.
*** Error code 1

Stop in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0.
*** Error code 1

Stop in /usr/ports/sysutils/fusefs-kmod.
*** Error code 1

Stop in /usr/ports/sysutils/fusefs-kmod.

===>>> make failed for sysutils/fusefs-kmod
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: p5-DBD-mysql-4.018

[Joseph Mingrone]

Hello,

I see the following error during the build:

dbdimp.c: In function 'mysql_db_FETCH_attrib':
dbdimp.c:2447: error: 'sv_undef' undeclared (first use in this function)

% uname -a
FreeBSD awarnach.mathstat.dal.ca 8.0-RELEASE-p4 FreeBSD 8.0-RELEASE-p4
#0: Mon Jul 12 20:55:11 UTC 2010
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

If any other information is helpful or if you would like me to create
a PR, just let me know.

Best regards,

Joseph
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: suitesparse-3.6.1

[Joseph Mingrone]

Hello,

Building the recent port update failed.

% uname -a
FreeBSD gly 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Tue Feb 22 13:28:46
AST 2011 root@gly:/usr/obj/usr/src/sys/GLY_2011-02-22  i386


Portion of output from the build:

gmake[4]: Entering directory
`/usr/ports/math/suitesparse/work/SuiteSparse/CCOLAMD/Lib'
gmake[4]: Nothing to be done for `default'.
gmake[4]: Leaving directory
`/usr/ports/math/suitesparse/work/SuiteSparse/CCOLAMD/Lib'
gmake[3]: Leaving directory
`/usr/ports/math/suitesparse/work/SuiteSparse/CCOLAMD'
gcc45 -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc45 -fno-strict-aliasing
-DNPARTITION -o cholmod_demo -I../Include -I../../UFconfig
cholmod_demo.c ../Lib/libcholmod.a ../../AMD/Lib/libamd.a
../../COLAMD/Lib/libcolamd.a ../../CCOLAMD/Lib/libccolamd.a
../../CAMD/Lib/libcamd.a  -L/usr/local/lib -pthread -lalapack_r
-L/usr/local/lib -pthread -lptf77blas -lptcblas -latlas_r -lgfortran
-lgfortranbegin  -lm
/usr/local/bin/ld: cholmod_demo: hidden symbol `__powidf2' in
/usr/local/lib/gcc45/gcc/i386-portbld-freebsd8.2/4.5.4/libgcc.a(_powidf2.o)
is referenced by DSO
/usr/local/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
gmake[2]: *** [cholmod_demo] Error 1
gmake[2]: Leaving directory
`/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD/Demo'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory
`/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD'
gmake: *** [default] Error 2
*** Error code 2

Stop in /usr/ports/math/suitesparse.

Please let me know if you need any other information.

Joey
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: skype-2.1.0.81,1

[Joseph Mingrone]

Hello;

After installing net-im/skpe, the application starts up fine, but when
I try to connect it times out after a few minutes and tells me "P2P
Connect failed". In syslog I see
Code:

kernel: linux: pid 3175 (skype): ioctl fd=11, cmd=0x564a ('V',74) is
not implemented.

% uname -a:
Code:

FreeBSD phe.ath.cx 8.3-RC1 FreeBSD 8.3-RC1 #0: Sun Mar  4 00:42:38 UTC
2012 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386.

% kldstat:
Code:

Id Refs AddressSize Name
 1   39 0xc040 c68d94   kernel
 21 0xc1069000 f9d4 if_iwi.ko
 31 0xc1079000 7120 snd_ich.ko
 42 0xc1081000 57908sound.ko
 51 0xc10d9000 4f90 atapicam.ko
 61 0xc10de000 4a64 cuse4bsd.ko
 71 0xc575f000 8000 linprocfs.ko
 81 0xc5777000 28000linux.ko
 91 0xc581d000 4000 fdescfs.ko
101 0xc598b000 3iwi_bss.ko
111 0xc5c2d000 68000radeon.ko
121 0xc5c96000 14000drm.ko

net-im/skype-devel connects and generally seems to work fine, but
video unfortunately doesn't work with the devel port.  I've tried
moving ~/.Skype, but no luck. I also tried creating a new skype
account from the client, but this also times out. Αm I doing something
wrong?

Cheers,

J
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: skype-2.1.0.81,1

[Joseph Mingrone]

Hi Matthia, ports;

Thanks for you reply.  I think I'm getting closer to finding out
what's going on.

I have a small LAN, which normally just has a single laptop and a
skype phone behind a Buffalo wireless access point / router.  The
skype phone is usually on all the time and I haven't had problems with
it for the two or three years I've owned it.  Last night when I was
testing the skype client on my laptop I turned the phone off.

So this morning when I got your message, I uninstalled
net-im/skype-devel and reinstalled net-im/skype and it signed in
immediately.  But now, the skype phone has the problem the client had
last night:  it won't sign in.  Even when I sign out with both the
client and the phone and try the phone it won't sign in, but the
client has no problems at all today.  I thought there must be a
problem with the router, so I rebooted, but the result is the same:
client has no problems, but no luck with the phone.

Is this a networking issue on my end or is it something to do with skype?

J
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: skype-2.1.0.81,1

[Joseph Mingrone]

On Sun, Mar 11, 2012 at 14:33, Matthias Apitz  wrote:
> It sounds a bit like some NAT issue in the router and the first client
> connecting to Skype wins. No sure, though.

I'm going on a few assumptions that I'll have to verify, but a reboot
of the router should flush the "first" client, but as of today,it's
always the laptop client who wins and the phone who fails.

Thanks for your help.

J
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: skype-2.1.0.81,1

[Joseph Mingrone]

On Sun, Mar 11, 2012 at 15:39, Mel Flynn  wrote:
> I've had issues like this when I was still using Skype. Very hard to
> trace, but I had the feeling that a login gets bound to a client-id or
> client version and that failed attempts to log in mark a
> client-id/client version invalid. When this happened to me, I used the
> website password reset feature and it would then let me sign on with the
> new client.

Thanks Mel.  This seems plausible, but for the moment won't be
necessary because to reset anything because after about an hour the
phone successfully signed in while the laptop client was already
signed in.  I'm starting to understand why you stopped using skype.
Searching for alternatives has moved a few places up my priority list.

Thanks again Mel and Matthias.

J
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"