Re: Discussion concerning: New dialog for ports

2012-11-30 Thread Lars Engels
On Thu, Nov 29, 2012 at 05:12:55PM +0400, Ilya A. Arkhipov wrote:
> Hi Folks,
> 
> Few week ago I started work on new dialog for ports, main idea it's adding 
> functionality, I guess you know ;)
> I took checklist.c from libdialog and modified it for us. Regarding license, 
> I discussed with Thomas E. Dickey(author dialog) he said I can't change LGPL 
> to BSD but it should not be a problem.
> What we have now:
> - check + radio lists in on box (and yes we can put off radiobox)
> - separate line with text
> - dynamic width/height size
> - all features from checklist.c :)
> -- mouse support
> -- hotkey for find a lines
> My plan:
> - add Help button/F1/alt-h/esc-1 (actually don't know how will be better)
> - button for license
> - fixing bugs >_<
> - start work on parsing receiving data, after that should be ready for 
> testing.
> 
> Regarding parsing data I want discuss here. Wanna correct understand what 
> will be better, now I have few variants:
> 1. Get all data from env. variables
> 2. Use the same with old dialog style, I mean receive from STDIN
> 3. From file? <- guess bad idea
> Your ideas?
> 
> And certainly screeshots:
> Big description(just for test);
>   In X -- http://imm.io/NkVR
>   In Terminal -- 
> https://www.dropbox.com/s/bzt8zszpk40jrso/2012-11-29%2014.59.53.jpg
> With license button:
>   in X -- http://imm.io/Nl9K
> 
> You can find my repo there: https://bitbucket.org/m1cro/d4p/. I'll be happy 
> for all response ;)
> 


That look very good! :)


pgpHEKTfpARw9.pgp
Description: PGP signature


Re: /archivers/ is missing after svn...

2012-11-30 Thread Ronald Klop
On Thu, 29 Nov 2012 20:04:08 +0100, Jeffrey Bouquet  
 wrote:





--- On Thu, 11/29/12, Warren Block  wrote:

From: Warren Block 
Subject: Re: /archivers/ is missing after svn...
To: "Jeffrey Bouquet" 
Cc: freebsd-ports@freebsd.org
Date: Thursday, November 29, 2012, 7:00 AM

On Thu, 29 Nov 2012, Jeffrey Bouquet wrote:


UPDATE:

OTOH I can svn it independently to elsewhere than ports, any canonical  
way

to move that /tmp/archivers to /usr/ports/archivers ?

DONE:
moved that /tmp/archivers to /usr/ports/archivers, strangely I did not  
find its

.svn after the move.


Multiple partial checkouts is not the same as one big checkout.  The
.svn directory only exists in the base directory of the checkout.

Back up /usr/ports (for local changes), delete the entire directory,
then check out the entire directory.
___
Done.
Unfortunately I forgot to relocate /packages/ and /distfiles/ first, so
they have been restored from yesterday's backup.
Also there is an INDEX-9.move_distfiles  (zero length file) for the next
time, as a reminder, as I'd move INDEX* out of the way first.
___
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 and distfiles are cache directories to save on network bandwidth.  
If your internet is not very slow or on a data limit then it is harmless  
to delete their content. The files will get downloaded when they are  
needed again.


You sound to me like you moved the content of /usr/ports to another place  
per file or per directory.

I hope you did something like this.
mv /usr/ports /usr/ports-old
svn checkout svn+ssh://svn.freebsd.org/ports/head /usr/ports

This will restore a complete and consistent ports directory. And you don't  
need the reminders, etc.


Regards,
Ronald.
___
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: editors/libreoffice pkg_add error

2012-11-30 Thread Jakub Lach
Broken archive?



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/editors-libreoffice-pkg-add-error-tp5765455p5765507.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
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: Chromium ISSUE with GCC 4.8

2012-11-30 Thread Jakub Lach
You are forcing developer version of compiler, it's not even
released yet. 4.7.2 was released 2 months ago.

If you care enough, bug gcc as already you should know

"Please submit a full bug report, 
with preprocessed source if appropriate. 
See  for instructions."



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Chromium-ISSUE-with-GCC-4-8-tp5765309p5765510.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
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: How to handle WITH_CLANG_IS_CC in ports

2012-11-30 Thread Nikolai Lifanov

On 11/29/2012 05:46 PM, Yamaya Takashi wrote:

On 2012/11/30 06:30, Dimitry Andric wrote:

On 2012-11-29 20:47, Tobias Rehbein wrote:> Am Fri, Nov 30, 2012 at
02:51:31AM +0900 schrieb Yamaya Takashi:


Include Mk/bsd.compiler.mk, and
.if ${COMPILER_TYPE} == "clang"
clang specific code
.endif



Thanks. This is exactly what I was looking for. It is available in
CURRENT only though.


FYI, I merged bsd.compiler.mk and the rest of the COMPILER_TYPE logic to
stable/9 in r243041.  It will not be in 9.1-RELEASE, though...


I am NOT committer.
Please commit Mk/bsd.compiler.mk.

[usr/ports/]Mk/bsd.compiler.mk is differ from
[usr/src/]share/mk/bsd.compiler.mk.
Ports version accepts another compiler, e.g. CC=icc, but Base version not.





Should it be sufficient to use logic like COMPILER_TYPE in combination 
with OSVERSION?


___
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: How to handle WITH_CLANG_IS_CC in ports

2012-11-30 Thread Yamaya Takashi
On 2012/11/30 22:26, Nikolai Lifanov wrote:
> On 11/29/2012 05:46 PM, Yamaya Takashi wrote:
>> On 2012/11/30 06:30, Dimitry Andric wrote:
>>> On 2012-11-29 20:47, Tobias Rehbein wrote:> Am Fri, Nov 30, 2012 at
>>> 02:51:31AM +0900 schrieb Yamaya Takashi:
>
> Include Mk/bsd.compiler.mk, and
> .if ${COMPILER_TYPE} == "clang"
> clang specific code
> .endif
>

 Thanks. This is exactly what I was looking for. It is available in
 CURRENT only though.
>>>
>>> FYI, I merged bsd.compiler.mk and the rest of the COMPILER_TYPE
>>> logic to
>>> stable/9 in r243041.  It will not be in 9.1-RELEASE, though...
>>>
>> I am NOT committer.
>> Please commit Mk/bsd.compiler.mk.
>>
>> [usr/ports/]Mk/bsd.compiler.mk is differ from
>> [usr/src/]share/mk/bsd.compiler.mk.
>> Ports version accepts another compiler, e.g. CC=icc, but Base version
>> not.
>>
>>
>>
>
> Should it be sufficient to use logic like COMPILER_TYPE in combination
> with OSVERSION?
>
>
>
No.

.include "${PORTSDIR}/Mk/bsd.compiler.mk"
#Now, COMPILER_TYPE is defined.

___
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: ports/173258: graphics/gnash port has dependency problem with libxul19

2012-11-30 Thread Thomas Mueller
> Hi Folks,

> Few week ago I started work on new dialog for ports, main idea it's adding 
> functionality, I guess you know ;)
> I took checklist.c from libdialog and modified it for us. Regarding license, 
> I discussed with Thomas E. Dickey(author dialog) he said I can't change LGPL 
> to
> +BSD but it should not be a problem.
> What we have now:
> - check + radio lists in on box (and yes we can put off radiobox)
> - separate line with text
> - dynamic width/height size
> - all features from checklist.c :)
> -- mouse support
> -- hotkey for find a lines
> My plan:
> - add Help button/F1/alt-h/esc-1 (actually don't know how will be better)
> - button for license
> - fixing bugs >_<
> - start work on parsing receiving data, after that should be ready for 
> testing.

> Regarding parsing data I want discuss here. Wanna correct understand what 
> will be better, now I have few variants:
> 1. Get all data from env. variables
> 2. Use the same with old dialog style, I mean receive from STDIN
> 3. From file? <- guess bad idea
> Your ideas?

> And certainly screeshots:
> Big description(just for test);
>   In X -- http://imm.io/NkVR
>   In Terminal -- 
> https://www.dropbox.com/s/bzt8zszpk40jrso/2012-11-29%2014.59.53.jpg
> With license button:
>   in X -- http://imm.io/Nl9K

> You can find my repo there: https://bitbucket.org/m1cro/d4p/. I'll be happy 
> for all response ;)

> With Best Regards,
> Ilya A. Arkhipov

I'd like a dialog, if there is to be a dialog rather than setting options in 
/etc/make.conf, that would not mess up when the user keeps a log of a build 
using tee or script.

One possibility would be to do the dialog in a virtual terminal separate from 
the ports build.

Configuration dialog has to work from nongraphical interface, since FreeBSD 
base system, where a user would start, has no graphical interface.

I like the idea of putting port options in a file, as NetBSD pkgsrc does using 
/etc/mk.conf, or possibly /usr/pkg/etc/mk.conf when on a non-NetBSD platform.


Tom
___
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"


Dealing with options in dependent ports

2012-11-30 Thread Paul Schmehl
I'm working on a port that has an option for a build_depends on another 
port.  If that option is selected, the dependent port MUST be built with an 
option that is not selected by default.


Is there a way to either force that option to be selected in the dependent 
port?  Or, failing that, is it possible to pop up a message warning the 
installer that they must select that option before building the dependent 
port or, if they've already installed it without the option, they must 
deinstall and reinstall after selecting that option?


--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell

___
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 ports you maintain which are out of date

2012-11-30 Thread portscout
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
devel/arm-rtems-gdb | 7.2 | 7.5.1
+-+
devel/cross-gdb | 7.2 | 7.5.1
+-+
devel/i386-rtems-gdb| 7.2 | 7.5.1
+-+
devel/k8048 | 1.04| 2.00
+-+
devel/m68k-rtems-gdb| 7.2 | 7.5.1
+-+
devel/mips-rtems-gdb| 7.2 | 7.5.1
+-+
devel/powerpc-rtems-gdb | 7.2 | 7.5.1
+-+
devel/sh-rtems-gdb  | 7.2 | 7.5.1
+-+
devel/sparc-rtems-gdb   | 7.2 | 7.5.1
+-+
www/xist| 3.25| 4.5
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

If wish to stop receiving portscout reminders, please contact
portsc...@portscout.freebsd.org

Thanks.
___
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: Dealing with options in dependent ports

2012-11-30 Thread Thierry Thomas
Hello,

Le ven 30 nov 12 à 16:36:32 +0100, Paul Schmehl 
 écrivait :
> I'm working on a port that has an option for a build_depends on another 
> port.  If that option is selected, the dependent port MUST be built with an 
> option that is not selected by default.
> 
> Is there a way to either force that option to be selected in the dependent 
> port?  Or, failing that, is it possible to pop up a message warning the 
> installer that they must select that option before building the dependent 
> port or, if they've already installed it without the option, they must 
> deinstall and reinstall after selecting that option?
> 

I'd suggest to make a slave port where you force the required option.
However, to enforce the right dependency, this option have to produce a
different plist.
-- 
Th. Thomas.
___
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: Dealing with options in dependent ports

2012-11-30 Thread Emanuel Haupt
Thierry Thomas  wrote:
> Hello,
> 
> Le ven 30 nov 12 à 16:36:32 +0100, Paul Schmehl
>  écrivait :
> > I'm working on a port that has an option for a build_depends on
> > another port.  If that option is selected, the dependent port MUST
> > be built with an option that is not selected by default.
> > 
> > Is there a way to either force that option to be selected in the
> > dependent port?  Or, failing that, is it possible to pop up a
> > message warning the installer that they must select that option
> > before building the dependent port or, if they've already installed
> > it without the option, they must deinstall and reinstall after
> > selecting that option?
> > 
> 
> I'd suggest to make a slave port where you force the required option.
> However, to enforce the right dependency, this option have to produce
> a different plist.
> -- 
> Th. Thomas.

I was in the same situation with dns/ldns requiring python bindings
which are not built by default. I solved the problem by creating a stub
port dns/py-ldns.

Emanuel
___
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: Dealing with options in dependent ports

2012-11-30 Thread Paul Schmehl
--On November 30, 2012 4:47:40 PM +0100 Thierry Thomas 
 wrote:



Hello,

Le ven 30 nov 12 à 16:36:32 +0100, Paul Schmehl
  écrivait :

I'm working on a port that has an option for a build_depends on another
port.  If that option is selected, the dependent port MUST be built with
an  option that is not selected by default.

Is there a way to either force that option to be selected in the
dependent  port?  Or, failing that, is it possible to pop up a message
warning the  installer that they must select that option before building
the dependent  port or, if they've already installed it without the
option, they must  deinstall and reinstall after selecting that option?



I'd suggest to make a slave port where you force the required option.
However, to enforce the right dependency, this option have to produce a
different plist.


Thanks.  I think that's probably the right answer.

--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell

___
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: Dealing with options in dependent ports

2012-11-30 Thread Alberto Villa
On Fri, Nov 30, 2012 at 4:47 PM, Thierry Thomas  wrote:
> However, to enforce the right dependency, this option have to produce a
> different plist.

Really? Isn't enough to depend on the package name instead of a file?
--
Alberto Villa, FreeBSD committer 
http://people.FreeBSD.org/~avilla
___
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: Dealing with options in dependent ports

2012-11-30 Thread Thierry Thomas
Le ven 30 nov 12 à 19:07:20 +0100, Alberto Villa 
 écrivait :
> On Fri, Nov 30, 2012 at 4:47 PM, Thierry Thomas  wrote:
> > However, to enforce the right dependency, this option have to produce a
> > different plist.
> 
> Really? Isn't enough to depend on the package name instead of a file?

xxx_DEPENDS=   specific_file:slave_ports
-- 
Th. Thomas.
___
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: databases/mongodb on FreeBSD 9

2012-11-30 Thread Wesley Shields
On Fri, Nov 30, 2012 at 06:22:28AM -0800, Patrick wrote:
> Has anyone had any issues building the mongodb port on FreeBSD 9?
> 
> I'm running 9.0-RELEASE-p5 on i386:
> 
> It's bailing for me here:
> 
> c++ -o
> build/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo/shell/linenoise.o
> -c -Wnon-virtual-dtor -Woverloaded-virtual -fno-omit-frame-pointer -fPIC
> -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare
> -Wno-unknown-pragmas -Winvalid-pch -O3 -D_SCONS -DMONGO_EXPOSE_MACROS
> -DSUPPORT_UTF8 -D__freebsd__ -D_FILE_OFFSET_BITS=64 -DJS_C_STRINGS_ARE_UTF8
> -DMONGO_SSL -DMONGO_HAVE_HEADER_UNISTD_H -DMONGO_HAVE_EXECINFO_BACKTRACE
> -Ibuild/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm -Isrc
> -Ibuild/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo
> -Isrc/mongo
> -Ibuild/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo/cpp
> -Isrc/mongo/cpp -I/usr/local/include src/mongo/shell/linenoise.cpp
> In file included from src/mongo/shell/linenoise.cpp:115:
> src/mongo/shell/linenoise_utf8.h: In member function 'void
> linenoise_utf8::UtfStringMixin::swap(linenoise_utf8::UtfStringMixin&)':
> src/mongo/shell/linenoise_utf8.h:145: error: 'swap' is not a member of 'std'
> src/mongo/shell/linenoise_utf8.h:146: error: 'swap' is not a member of 'std'
> src/mongo/shell/linenoise_utf8.h:147: error: 'swap' is not a member of 'std'
> scons: ***
> [build/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo/shell/linenoise.o]
> Error 1
> scons: building terminated because of errors.
> *** Error code 2

It builds fine for me. Can you check what version of boost and it's
related packages you are building against?

-- WXS
___
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: Dealing with options in dependent ports

2012-11-30 Thread Paul Schmehl
--On November 30, 2012 7:07:20 PM +0100 Alberto Villa  
wrote:



On Fri, Nov 30, 2012 at 4:47 PM, Thierry Thomas 
wrote:

However, to enforce the right dependency, this option have to produce a
different plist.


Really? Isn't enough to depend on the package name instead of a file?


No.  The dependency installs files that are not otherwise installed, so the 
pkg-plist has to reflect that.  Here's how I did it in the port I just 
created a slave for.


Created this section in the main port's Makefile:
.if defined(SLAVE)
OPTIONS_DEFINE+=BROCCOLI
OPTIONS_DEFAULT+=   BROCCOLI
BROCCOLI_DESC=  Build support for libbroccoli communications
.endif

This adds the option and enforces it being selected if you install the 
slave port.


Then created this section in the main port's Makefile:
.if ${PORT_OPTIONS:MBROCCOLI}
PLIST_SUB+= BROCCOLI=""
pre-configure:
   (cd ${WRKSRC}/aux/broccoli && ./configure)
pre-build:
   (cd ${WRKSRC}/aux/broccoli && ${MAKE})
post-build:
   patch ${BUILD_WRKSRC}/cmake_install.cmake ${FILESDIR}/broccoli.patch
.else
PLIST_SUB+= BROCCOLI="@comment "
.endif

The PLIST_SUB section allows you to add files to the pkg-plist that are 
provisional, based on the install of the slave port.


Then the pkg_plist sub has the files included with the macro:
%%BROCCOLI%%include/broccoli.h
%%BROCCOLI%%lib/libbinpac.a
%%BROCCOLI%%lib/libbroccoli.a
%%BROCCOLI%%lib/libbroccoli.so
%%BROCCOLI%%lib/libbroccoli.so.5
%%BROCCOLI%%lib/libbroccoli.so.5.1.0

Those only get removed if the option was selected, so deinstall won't throw 
errors if you install the main port without that option.




--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell

___
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"


Thunderbird 17.0.1_1 Seg Fault 11's on Enigmail and Lightning

2012-11-30 Thread Joseph a Nagy Jr
Okay, I have a .core and .txt file with all the info anyone would need,
I imagine, if it would help in solving this issue.

When I run Thunderbird 17.0.1_1 and try to select the "Generate" option
when I open "Key Management" from the OpenPGP menu (Enigmail 1.4.6) or
dismiss even reminders from Lightning (1.9b1), Thunderbird will exit
with segmentation fault: 11(core dumped) leaving behind a 116MB core file.

Running

thunderbird > thunderbird.debug 2>&1

captures any errors but I have no idea what to look for. I can put both
files on a http server in short-order, just let me know what you all need.


FreeBSD alex-laptop.localhost 9.0-RELEASE-p5 FreeBSD 9.0-RELEASE-p5 #0:
Sat Nov 24 10:20:42 CST 2012
root@alex-laptop.localhost:/usr/obj/usr/src/sys/ALEX-LAPTOP  i386
-- 
Yours in Christ,

Joseph A Nagy Jr
"Whoever loves instruction loves knowledge, But he who hates correction
is stupid." -- Proverbs 12:1
Emails are not formal business letters, whatever businesses may want.
Original content CopyFree (F) under the OWL http://owl.apotheon.org


signature.asc
Description: OpenPGP digital signature