Re: cups-client broken on ia64, blocks 70 ports, please help

2014-04-08 Thread Anton Shterenlikht
From b...@passap.ru Mon Apr  7 21:41:34 2014

 The errors are from cups-image now:
  http://eis.bris.ac.uk/~mexas/logs/cups-image-1.7.1.log

Please test the attached patch (apply to print/cups-base and
test print/cups-image).

yes, fixes the problem, thank you.

 Also, if you are interested, here are 2 more CUPS
 build failures:
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=188336
 http://www.freebsd.org/cgi/query-pr.cgi?pr=188337

Can you followup to those PRs with URLs to full config.log?

done for the first one, gtk20.

However, for the second one, qt4-gui, it didn't even
get to config.log, at least I cannot find it under
poudriere workdirs: 

data/wrkdirs/ia64-11-default/default/work/qt-everywhere-opensource-src-4.8.5

Many thanks

Anton

___
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: print/hpijs + new cups + foomatic not working with hpijs-pcl3e printer.

2014-04-08 Thread Boris Samorodov
08.04.2014 08:05, Robert Backhaus пишет:
  I've got a printing problem with the new cups. A brother laser using
 Foomatic/hpijs-pcl5e, is printing '%PDF-1.3' instead of the required page.
 Examining the log file, It is trying to print it using texttops, before
 handing that to ghostscript, never detecting that it was PDF.
 Interestingly, if i print from libreoffice with .pdf print format enabled,
 I get %PDF-1.4 with %¿ as the next line.
 If I print without it, so it sends postscript, I get %PDF-1.3, again, with
 %¿ on the next line. So it seems like it is first converting the print
 document to .pdf, but not detecting that it is pdf for the next step.
 Hmm, another clue - I have a HP inkjet using Foomatic/hpijs, and it is
 working OK, with both pdf and ps input. But the hpijs-pcl5e Brother is
 failing. So the Hp inkjet is using a .ppd from the hpijs port, and the
 brother is using the ppd from the foomatic-db port.
 
 All the print ports are up to date.
 
 I think the bit that is messing up is the foomatic filter, which, if I
 understand it, decides what filters to put the file through. But the hpijs
 printer is working fine, while the hpijs-pcl5e  one is messing up, even
 though they come from the same port. I don't understand the difference, so
 I am stuck working out where it is going wrong.
 
 Any help would be greatly appreciated.

You use print/hpijs. AFAIC HP now produces it's capability at
print/hplip. Please, consider trying the latter.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: cups-client broken on ia64, blocks 70 ports, please help

2014-04-08 Thread Boris Samorodov
08.04.2014 10:47, Anton Shterenlikht пишет:
From b...@passap.ru Mon Apr  7 21:41:34 2014

 The errors are from cups-image now:
  http://eis.bris.ac.uk/~mexas/logs/cups-image-1.7.1.log

 Please test the attached patch (apply to print/cups-base and
 test print/cups-image).
 
 yes, fixes the problem, thank you.

A fix is committed.

 Also, if you are interested, here are 2 more CUPS
 build failures:

 http://www.freebsd.org/cgi/query-pr.cgi?pr=188336
 http://www.freebsd.org/cgi/query-pr.cgi?pr=188337

 Can you followup to those PRs with URLs to full config.log?
 
 done for the first one, gtk20.
 
 However, for the second one, qt4-gui, it didn't even
 get to config.log, at least I cannot find it under
 poudriere workdirs: 
 
 data/wrkdirs/ia64-11-default/default/work/qt-everywhere-opensource-src-4.8.5

Replied at another thread (seems that for you it's a good idea to
upgrade to a recent CURRENT).

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: print/hpijs + new cups + foomatic not working with hpijs-pcl3e printer.

2014-04-08 Thread Patrick Lamaiziere
Le Tue, 8 Apr 2014 14:05:00 +1000,
Robert Backhaus rob...@robbak.com a écrit :

  I've got a printing problem with the new cups.

I've got a similar problem with cups 1.7 and a Lexmark T640
using the foomatic filters. I've to use Generic Postcript printer to
make it works again.

That worked fine with cups 1.5. With 1.7 the printer prints nothing.
I guess something is broken.

Regards.
___
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


Building Apache22 against OpenSSL port

2014-04-08 Thread Egoitz Aurrekoetxea
Hi, 

Have tried building Apache on a recently upgraded ports collection for linking 
Apache, php and all against openssl new port…. but no way of ending up that 
way….

I see always : 

ldd /usr/local/libexec/apache22/mod_ssl.so 
/usr/local/libexec/apache22/mod_ssl.so:
libssl.so.7 = /usr/lib/libssl.so.7 (0x80163)
libcrypto.so.7 = /lib/libcrypto.so.7 (0x801899000)
libthr.so.3 = /lib/libthr.so.3 (0x801c84000)
libc.so.7 = /lib/libc.so.7 (0x80081d000)


Have tried with : 

make WITH_OPENSSL_PORT=yes

inserting in /etc/make.conf… but no way….

has anyone suffered this same issue?

Regards,
___
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: print/hpijs + new cups + foomatic not working with hpijs-pcl3e printer.

2014-04-08 Thread Boris Samorodov
08.04.2014 13:55, Patrick Lamaiziere пишет:
 Le Tue, 8 Apr 2014 14:05:00 +1000,
 Robert Backhaus rob...@robbak.com a écrit :
 
  I've got a printing problem with the new cups.
 
 I've got a similar problem with cups 1.7 and a Lexmark T640
 using the foomatic filters. I've to use Generic Postcript printer to
 make it works again.
 
 That worked fine with cups 1.5. With 1.7 the printer prints nothing.
 I guess something is broken.

Anything suspicious at /var/log/messages, /var/log/cups/*?
OS version and which cups / foomatic ports are installed?

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: Building Apache22 against OpenSSL port

2014-04-08 Thread Egoitz Aurrekoetxea
This seems to be an Apache issue when being built…. I say this because Postfix 
por example runs at first attempt as it should….

ldd /usr/local/libexec/postfix/smtpd
/usr/local/libexec/postfix/smtpd:
libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x800889000)
libssl.so.8 = /usr/local/lib/libssl.so.8 (0x800af2000)
libcrypto.so.8 = /usr/local/lib/libcrypto.so.8 (0x800d58000)
libc.so.7 = /lib/libc.so.7 (0x801154000)
libthr.so.3 = /lib/libthr.so.3 (0x8014ed000)

El 08/04/2014, a las 12:03, Egoitz Aurrekoetxea ego...@ramattack.net escribió:

 Hi, 
 
 Have tried building Apache on a recently upgraded ports collection for 
 linking Apache, php and all against openssl new port…. but no way of ending 
 up that way….
 
 I see always : 
 
 ldd /usr/local/libexec/apache22/mod_ssl.so 
 /usr/local/libexec/apache22/mod_ssl.so:
   libssl.so.7 = /usr/lib/libssl.so.7 (0x80163)
   libcrypto.so.7 = /lib/libcrypto.so.7 (0x801899000)
   libthr.so.3 = /lib/libthr.so.3 (0x801c84000)
   libc.so.7 = /lib/libc.so.7 (0x80081d000)
 
 
 Have tried with : 
 
 make WITH_OPENSSL_PORT=yes
 
 inserting in /etc/make.conf… but no way….
 
 has anyone suffered this same issue?
 
 Regards,
 ___
 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@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

2014-04-08 Thread Mikhail T.
On 08.04.2014 08:00, freebsd-ports-requ...@freebsd.org wrote:
 If people are using a port, then I would agree it should be kept
 regardless of maintainer status. But that doesn't mean keeping
 everything forever as long as it compiles.
Why not? Why not keep everything forever as long as it compiles? Where
is this idea coming from, that stuff must be continuously updated to be
considered usable?
 It's certainly possible that antoine@ has been a little overzealous in
 deprecating ports, but I don't think it's unreasonable to expect to have
 some evidence that any particular port has actually *worked* in the last
 ten or fifteen years.
There is no evidence it has NOT worked either. And the burden of proof,
that a change is necessary (or even desirable), is on whoever is
suggesting the change.

The most recent list included not only software for interfacing with old
video-cameras -- various modules for xmms, for example, are on the
chopping block too, for just another example. Why?..

-mi

P.S. Please, CC me on any follow-ups -- I'm only getting digests of
freebsd-ports@ making replying difficult.
___
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: Building Apache22 against OpenSSL port

2014-04-08 Thread Dr. Rolf Jansen
Perhaps it is an option for you to switch to Apache 24.

On my machine Apache 24 picks OpenSSL from the ports without any special 
adjustments:

 ldd /usr/local/libexec/apache24/mod_ssl.so
/usr/local/libexec/apache24/mod_ssl.so:
libssl.so.8 = /usr/local/lib/libssl.so.8 (0x801238000)
libcrypto.so.8 = /usr/local/lib/libcrypto.so.8 (0x80149f000)
libcrypt.so.5 = /lib/libcrypt.so.5 (0x801883000)
libthr.so.3 = /lib/libthr.so.3 (0x801aa2000)
libc.so.7 = /lib/libc.so.7 (0x80081b000)

Best regards

Rolf


Am 08.04.2014 um 10:59 schrieb Egoitz Aurrekoetxea ego...@ramattack.net:

 This seems to be an Apache issue when being built…. I say this because 
 Postfix por example runs at first attempt as it should….
 
 ldd /usr/local/libexec/postfix/smtpd
 /usr/local/libexec/postfix/smtpd:
   libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x800889000)
   libssl.so.8 = /usr/local/lib/libssl.so.8 (0x800af2000)
   libcrypto.so.8 = /usr/local/lib/libcrypto.so.8 (0x800d58000)
   libc.so.7 = /lib/libc.so.7 (0x801154000)
   libthr.so.3 = /lib/libthr.so.3 (0x8014ed000)
 
 El 08/04/2014, a las 12:03, Egoitz Aurrekoetxea ego...@ramattack.net 
 escribió:
 
 Hi, 
 
 Have tried building Apache on a recently upgraded ports collection for 
 linking Apache, php and all against openssl new port…. but no way of ending 
 up that way….
 
 I see always : 
 
 ldd /usr/local/libexec/apache22/mod_ssl.so 
 /usr/local/libexec/apache22/mod_ssl.so:
  libssl.so.7 = /usr/lib/libssl.so.7 (0x80163)
  libcrypto.so.7 = /lib/libcrypto.so.7 (0x801899000)
  libthr.so.3 = /lib/libthr.so.3 (0x801c84000)
  libc.so.7 = /lib/libc.so.7 (0x80081d000)
 
 
 Have tried with : 
 
 make WITH_OPENSSL_PORT=yes
 
 inserting in /etc/make.conf… but no way….
 
 has anyone suffered this same issue?
 
 Regards,
 ___
 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@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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Suggestion for port maintainers

2014-04-08 Thread Dave Duchscher
Port Maintainers,

Just a suggestion: If you are going to remove an option from your port, it 
would be nice if you would make the port break when that option is used.  We 
build our own packages with custom options and this little issue just caused 
some issues for us.  We can’t watch updates to every port we build and we just 
got bit by the option APACHE being removed from lang/php5 port.

—
DaveD

___
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

2014-04-08 Thread Christian Weisgerber
On 2014-04-08, Mikhail T. mi+t...@aldan.algebra.com wrote:

 The most recent list included not only software for interfacing with old
 video-cameras -- various modules for xmms, for example, are on the
 chopping block too, for just another example. Why?..

I was wondering about the XMMS modules, too, since I'm listed as
maintainer for some.  It turns out that XMMS itself is marked as
FORBIDDEN and scheduled for deletion.

I'm fixing XMMS now.

-- 
Christian naddy Weisgerber  na...@mips.inka.de
___
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

2014-04-08 Thread Tijl Coosemans
On Tue, 08 Apr 2014 09:57:48 -0400 Mikhail T. wrote:
 On 08.04.2014 08:00, freebsd-ports-requ...@freebsd.org wrote:
 If people are using a port, then I would agree it should be kept
 regardless of maintainer status. But that doesn't mean keeping
 everything forever as long as it compiles.
 Why not? Why not keep everything forever as long as it compiles? Where
 is this idea coming from, that stuff must be continuously updated to be
 considered usable?

It doesn't have to be updated continuously, but it has to be used.
Keeping a port requires effort.  It needs to be kept up to date with
infrastructural changes (like staging) and if nobody is using the port
that's just a waste of effort.
___
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


[QAT] 350635: 4x leftovers

2014-04-08 Thread Ports-QAT
Add a port of system clock synchronization client and server (chrony).

WWW: http://chrony.tuxfamily.org/

PR: ports/174263
-

  Build ID:  20140408170800-59209
  Job owner: da...@freebsd.org
  Buildtime: 3 minutes
  Enddate:   Tue, 08 Apr 2014 17:11:04 GMT

  Revision:  350635
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=350635

-

Port:net/chrony 1.29.1

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~da...@freebsd.org/20140408170800-59209-314410/chrony-1.29.1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~da...@freebsd.org/20140408170800-59209-314411/chrony-1.29.1.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~da...@freebsd.org/20140408170800-59209-314412/chrony-1.29.1.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~da...@freebsd.org/20140408170800-59209-314413/chrony-1.29.1.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20140408170800-59209
redports https://qat.redports.org/
___
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

2014-04-08 Thread Mikhail T.
On 08.04.2014 12:55, Tijl Coosemans wrote:
 On Tue, 08 Apr 2014 09:57:48 -0400 Mikhail T. wrote:
  On 08.04.2014 08:00, freebsd-ports-requ...@freebsd.org wrote:
  If people are using a port, then I would agree it should be kept
  regardless of maintainer status. But that doesn't mean keeping
  everything forever as long as it compiles.
  Why not? Why not keep everything forever as long as it compiles? Where
  is this idea coming from, that stuff must be continuously updated to be
  considered usable?
 It doesn't have to be updated continuously, but it has to be used.
 Keeping a port requires effort.  It needs to be kept up to date with
 infrastructural changes (like staging) and if nobody is using the port
 that's just a waste of effort.
Tijl, there is no indication whatsoever, that ports on the chopping block are
not used. The argument put forth by the proponents of the removals is thus: The
upstream authors haven't made a new release in a long time, therefor the
software must be neither any good, nor see much use.

I find this logic flawed -- some of my favorite books are more than 2000 years
old, for example... Their authors certainly aren't making new releases, yet they
continue to be maintained, built (published), and used by generations.

The closest we've ever come to estimating usage is the following: If there is
any user-base to speak of, then there should be a person among them willing to
maintain the port -- or pay someone to maintain it. This, too, is flawed in my
opinion -- expecting a graphics-artist, a biologist, or an audiophile to also be
a half-decent software engineer is a stretch; expecting them to pay for
port-maintainership is also not fair, when the entire OS is free, done for fun,
rather than profit.

Though I agree, that unmaintained ports should be dropped when they break due to
things like security bugs or compiler-upgrades, the self-inflicted wounds like
infrastructure changes do not qualify. Volunteers taking it upon themselves to
perform such changes, should be prepared to deal with all that's required for 
them.

Yours,

-mi

___
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


Clang with libc++ on 9.x and nghttp2

2014-04-08 Thread Melvyn Sopacua

Hi,

seeing r350552 I fixed something related locally as below. I don't think
the fix is 100% correct (cause I haven't the faintest clue how
compiler.mk actually sets compiler flags), but it does the job and gets
rid of lang/gcc.

I do think that the testing for _CXXINTERNAL in Uses/compiler.mk is
incorrect, at least if one truely wants to test for clang being capable
of c++11 features.


diff -r 14e2c13e58e1 -r e0ade5980519 Mk/Uses/compiler.mk
--- a/Mk/Uses/compiler.mk   Sat Apr 05 08:07:55 2014 +0200
+++ b/Mk/Uses/compiler.mk   Sat Apr 05 20:46:45 2014 +0200
@@ -101,7 +101,7 @@
 .endif

 .if ${_COMPILER_ARGS:Mfeatures}
-_CXXINTERNAL!= ${CXX} -\#\#\# /dev/null 21
+_CXXINTERNAL!= ${CXX} -std=c++11 -stdlib=libc++ -\#\#\# /dev/null 21
 .if ${_CXXINTERNAL:M\-lc++\}
 COMPILER_FEATURES= libc++
 .else
diff -r 14e2c13e58e1 -r e0ade5980519 www/nghttp2/Makefile
--- a/www/nghttp2/Makefile  Sat Apr 05 08:07:55 2014 +0200
+++ b/www/nghttp2/Makefile  Sat Apr 05 20:46:45 2014 +0200
@@ -3,6 +3,7 @@

 PORTNAME=  nghttp2
 PORTVERSION=   0.3.2
+PORTREVISION=  1
 CATEGORIES=www net
 MASTER_SITES=  
https://github.com/tatsuhiro-t/${PORTNAME}/releases/download/v${PORTVERSION}/ \
LOCAL/sunpoet
@@ -30,7 +31,7 @@
 USE_GNOME= libxml2
 USE_LDCONFIG=  yes
 USE_OPENSSL=   yes
-USES=  compiler:c++11-lang pathfix pkgconfig tar:xz
+USES=  compiler:c++11-lib pathfix pkgconfig tar:xz

 PORTDOCS=  *

@@ -41,6 +42,8 @@

 .if ${OSVERSION}  100  !defined(WITH_OPENSSL_PORT)
 IGNORE=nghttp2 requires OpenSSL 1.0.1+
+.elif ${OSVERSION}  100
+CXXFLAGS+= -stdlib=libc++
 .endif

 post-build:

___
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: Suggestion for port maintainers

2014-04-08 Thread John Marino
On 4/8/2014 16:30, Dave Duchscher wrote:
 Port Maintainers,
 
 Just a suggestion: If you are going to remove an option from your
 port, it would be nice if you would make the port break when that
 option is used.  We build our own packages with custom options and
 this little issue just caused some issues for us.  We can’t watch
 updates to every port we build and we just got bit by the option
 APACHE being removed from lang/php5 port.

However, it is totally within your control have a script monitor every
port that you build for changes in options.  You could even run it as a
poudriere hook.

There are hundreds of maintainers; you aren't going to reach all of them
even if they all *all* agree with this suggestion.  (I don't think I do.
 How long do I have to keep this non-option broken?  1 month?  1 year?
forever?  too much trouble.)

John
___
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: smplayer-14.3.0

2014-04-08 Thread Dave Babb

Good Afternoon,


I don't know if you are aware of it, but SMPlayer 14.3 is broken. The 
underlying mplayer still works fine if launched from the CLI.


Here is my post with the error codes, along with another having the 
issue: https://forums.freebsd.org/viewtopic.php?f=19t=45843


I am not skilled enough to sort through the code in the ports tree and 
see what is going on.


Is there any chance you are aware of this issue and can guide us how to 
restore functionality?



Thank You!


Sincerely and respectfully,


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

2014-04-08 Thread Chris Rees

On 04/08/14 18:12, Mikhail T. wrote:

On 08.04.2014 12:55, Tijl Coosemans wrote:

On Tue, 08 Apr 2014 09:57:48 -0400 Mikhail T. wrote:

On 08.04.2014 08:00, freebsd-ports-requ...@freebsd.org wrote:

If people are using a port, then I would agree it should be kept
regardless of maintainer status. But that doesn't mean keeping
everything forever as long as it compiles.

Why not? Why not keep everything forever as long as it compiles? Where
is this idea coming from, that stuff must be continuously updated to be
considered usable?

It doesn't have to be updated continuously, but it has to be used.
Keeping a port requires effort.  It needs to be kept up to date with
infrastructural changes (like staging) and if nobody is using the port
that's just a waste of effort.

Tijl, there is no indication whatsoever, that ports on the chopping block are
not used. The argument put forth by the proponents of the removals is thus: The
upstream authors haven't made a new release in a long time, therefor the
software must be neither any good, nor see much use.

I find this logic flawed -- some of my favorite books are more than 2000 years
old, for example... Their authors certainly aren't making new releases, yet they
continue to be maintained, built (published), and used by generations.

The closest we've ever come to estimating usage is the following: If there is
any user-base to speak of, then there should be a person among them willing to
maintain the port -- or pay someone to maintain it. This, too, is flawed in my
opinion -- expecting a graphics-artist, a biologist, or an audiophile to also be
a half-decent software engineer is a stretch; expecting them to pay for
port-maintainership is also not fair, when the entire OS is free, done for fun,
rather than profit.

Though I agree, that unmaintained ports should be dropped when they break due to
things like security bugs or compiler-upgrades, the self-inflicted wounds like
infrastructure changes do not qualify. Volunteers taking it upon themselves to
perform such changes, should be prepared to deal with all that's required for 
them.




Hi Mikhail,

I think the term self-inflicted is a little strong... we can't really 
expect the tree to stand still.  I would expect people to loudly 
complain if their favourite port were dropped-- it's really not much 
effort to bring back, and some do come back.


If I have 1000 ports to fix, and decide to drop 50 of them because 
they're ancient and probably unused, it's no effort to restore and fix 
three if someone yells, and I've saved the effort of fixing 47 unused ports.


Chris

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: Repair pkgng

2014-04-08 Thread Melvyn Sopacua

Hi,

On Wed, 2 Apr 2014, Jakob Breivik Grimstveit wrote:



/var/db/pkg only contains these files:

$ find /var/db/pkg
[...]
/var/db/pkg/libyaml-0.1.6
/var/db/pkg/libyaml-0.1.6/distfiles
/var/db/pkg/gcc-ecj-4.5
/var/db/pkg/gcc-ecj-4.5/distfiles
/var/db/pkg/cmake-modules-2.8.10.2
/var/db/pkg/cmake-modules-2.8.10.2/distfiles
[...]


Why do you have files that portmaster sticks in /var/db/ports in
/var/db/pkg?
Did you perhaps switch those directories on restore or have a faulty
value in PORT_DBDIR?
If so, does +CONTENTS exist in /var/db/ports/libyaml-0.1.6?
___
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


Owner/group or permissions for directories

2014-04-08 Thread Melvyn Sopacua

Hello,

is there a way to have parent directories of files be created with same
owner or permissions as the files?

In addition:
@mode a+w
...
@mode

behaves unexpected. chmod a+w doesn't clear r and x, yet mode in
pkg-plist does so I end up with files that have -w--w--w-. And of course
their parents still have 755 with root/wheel.

I prefer not to resort to @exec or post install scripts but I don't see
I have a choice here.

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


Quickly cleanroom building and installing software from ports

2014-04-08 Thread Chris Rees

Hi all,

I really enjoy using pkgng, and I love that all my packages are build on 
a clean system without any possible quirks.


I found that installing from ports is a bit of a pain on these machines 
however, because I don't have any of the development packages installed 
(gcc47 etc).  I found I ended up installing these, but didn't like the 
'pollution'.


I chucked together two scripts, buildthis and upgradethis and figured 
people might find them useful.


All you need do is install it and Tinderbox and either:

# buildthis category/port [category2/port2 ]

or

# cd /usr/ports/category/port  buildthis

A build will be created for Tinderbox if necessary and the port will 
have a package built and installed.


Requires Tinderbox, if people want it around poudriere then please let 
me know.


Caveat emptor: I just wanted this to work for me... the code quality 
isn't anything special


http://www.bayofrum.net/cgi-bin/fossil/buildthis/tarball/buildthis-d503b895e8cc3883.tar.gz?uuid=d503b895e8cc3883dc5c6f2ed006b22ed10547ff

Chris

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: Retroshare 5.5a broken.

2014-04-08 Thread Peter Klett

Am 2014-04-02 19:34, schrieb Juergen Lock:

Hi!

 This just came up on irc (before I saw this thread), and I got the 
current

port to build on 10.0 and also with clang34 from ports using the patch
below, maybe it helps. :)  (I didn't run-test other than starting it 
once tho.)


Juergen


[patch snipped]

Hello Juergen,
great work!

I was able to apply your patch cleanly.
I have some patches for 0.5.5b and 0.5.5c and also for clang,
unfortunately I'm still unable to have images/icons in the b and
c releases :-( see screenshot at http://i62.tinypic.com/2v0kikm.jpg
regardless of QT4 or QT5.

I don't think there will be another 0.5.5 release, b/c they are hard
working on a 0.6 release.

So I think I will apply your patch to the 0.5.5a version and submit
a PR so RetroShare will at least compile on FreeBSD-10 and
wait for the 0.6 version. Hopefully the images will return with
0.6.


Peter
___
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: Building Apache22 against OpenSSL port

2014-04-08 Thread olli hauer
On 2014-04-08 12:03, Egoitz Aurrekoetxea wrote:
 Hi, 
 
 Have tried building Apache on a recently upgraded ports collection for 
 linking Apache, php and all against openssl new port…. but no way of ending 
 up that way….
 
 I see always : 
 
 ldd /usr/local/libexec/apache22/mod_ssl.so 
 /usr/local/libexec/apache22/mod_ssl.so:
   libssl.so.7 = /usr/lib/libssl.so.7 (0x80163)
   libcrypto.so.7 = /lib/libcrypto.so.7 (0x801899000)
   libthr.so.3 = /lib/libthr.so.3 (0x801c84000)
   libc.so.7 = /lib/libc.so.7 (0x80081d000)
 
 
 Have tried with : 
 
 make WITH_OPENSSL_PORT=yes
 
 inserting in /etc/make.conf… but no way….
 
 has anyone suffered this same issue?
 
 Regards,




Hi Egoitz,

Have you also build devel/apr1 with 'WITH_OPENSSL_PORT=yes' in /etc/make.conf?
apache22/24 uses only the information from apr-1-config to calculate the path 
to openssl
As far as I know more and more crypto/ssl stuff will will be relocated from 
httpd source to apr/apu.


Here are some outputs from apu-1-config, build with OpenSSL from base / ports
so you can compare it with the output from apr-1-config on your system.


OpenSSL base:
=
$ usr/local/bin/apu-1-config --includes
 -I/usr/local/include/apr-1 -I/usr/include -I/usr/local/include 
-I/usr/local/include/db5

/usr/local/bin/apu-1-config --ldflags
 -L/usr/lib -L/usr/local/lib -L/usr/local/lib/db5


OpenSSL ports:
=
$ /usr/local/bin/apu-1-config --includes
 -I/usr/local/include/apr-1 -I/usr/local/include -I/usr/local/include/db5

$ /usr/local/bin/apu-1-config --ldflags
 -L/usr/local/lib -L/usr/local/lib/db5


And also important '/usr/local/share/apr/build-1/apr_rules.mk'

diff -nru base_1.5.0.1.5.3/usr/local/share/apr/build-1/apr_rules.mk 
ports_1.5.0.1.5.3/usr/local/share/apr/build-1/apr_rules.mk
--- base_1.5.0.1.5.3/usr/local/share/apr/build-1/apr_rules.mk   2014-04-08 
23:00:48.0 +0200
+++ ports_1.5.0.1.5.3/usr/local/share/apr/build-1/apr_rules.mk  2014-04-08 
23:00:46.0 +0200
@@ -42,8 +42,8 @@
 # configure adds to them for tests, but we restore them at the end.
 #
 CFLAGS=-O2 -pipe -fno-strict-aliasing
-CPPFLAGS=-I/usr/include
-LDFLAGS= -L/usr/lib -Wl,-rpath,/usr/lib:/usr/local/lib
+CPPFLAGS=-I/usr/local/include -I/usr/local/include
+LDFLAGS= -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib
 LIBS=
 DEFS=-DHAVE_CONFIG_H



-- 
HTH,

olli
___
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: Quickly cleanroom building and installing software from ports

2014-04-08 Thread Steven Hartland

Look at poudriere its really good for exactly this, can even cross build
different versions.

   Regards
   Steve

- Original Message - 
From: Chris Rees cr...@physics.org

To: po...@freebsd.org
Sent: Tuesday, April 08, 2014 9:45 PM
Subject: Quickly cleanroom building and installing software from ports



Hi all,

I really enjoy using pkgng, and I love that all my packages are build on a 
clean system without any possible quirks.

I found that installing from ports is a bit of a pain on these machines however, because I don't have any of the development 
packages installed (gcc47 etc).  I found I ended up installing these, but didn't like the 'pollution'.


I chucked together two scripts, buildthis and upgradethis and figured people 
might find them useful.

All you need do is install it and Tinderbox and either:

# buildthis category/port [category2/port2 ]

or

# cd /usr/ports/category/port  buildthis

A build will be created for Tinderbox if necessary and the port will have a 
package built and installed.

Requires Tinderbox, if people want it around poudriere then please let me know.

Caveat emptor: I just wanted this to work for me... the code quality isn't 
anything special

http://www.bayofrum.net/cgi-bin/fossil/buildthis/tarball/buildthis-d503b895e8cc3883.tar.gz?uuid=d503b895e8cc3883dc5c6f2ed006b22ed10547ff

Chris

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Python install catch 22

2014-04-08 Thread Willem Jan Withagen
On 6-4-2014 4:22, Kubilay Kocak wrote:
 On 5/04/2014 9:12 PM, Willem Jan Withagen wrote:


 Op 5 apr. 2014 om 05:48 heeft Shane Ambler free...@shaneware.biz het 
 volgende geschreven:

 On 04/04/2014 22:42, Willem Jan Withagen wrote:
 Hi,

 I've tried to upgrade my python 2.7 which did not work.
 Then I deinstalled all python stuff and tried to install python3 (aka 3.3)

 You can install both versions of python (2.7  3.3) at the same time,
 but currently you can only install a module to one of the versions at a
 time.

 Sorry,

 I did not explain  the situation clear enough.

 I was at 2.7, and wanted to install a 2.7 upgrade because of a bug.
 If memory serves me, from 2.7.3 to 2.7.6

 But that started mounting about missing db stuff, and having to install a 
 py/db of choice.
 That is where I ran into the catch22, installing a db required py-tools, 
 which in turn starts to try to upgrade python from 2.7.3 to 2.7.6.
 
 Hi Willem,
 
 a) Can you clarify/confirm whether you tried installing/upgrading Python
 via ports or packages.
 
 b) Tell us exactly (method  commands) how you attempted to upgrade
 Python 2.7 to Python 3.3
 
 b) If via ports, it would be helpful to know how and why the dbm module
 fails to build for python33
 
 Either attach a complete build log here, or join us on IRC
 #freebsd-python on freenode so we can help you isolate.
 
 Koobs
 
 
 Then I cleaned/removed al python stuff, and tried again.
 First with 2.7 and when that did not work, I tried 3.3 with the same result.
 I tried with portinstall/portupgrade as well as make  make install, but 
 both fail for the same reason.

 So atm I have no python at al.

 So far there are still many modules that don't work with 3.x so you may
 want to use 2.7 if you want python with more than the default modules.

 The default python is still 2.7, if you want to use 3.3 then you might
 want to add
 DEFAULT_VERSIONS=PYTHON=3.3 PYTHON3=3.3
 to your /etc/make.conf

 The system everytime refuses to install because of missing a database:

 pkg-static:
 lstat(/home2/usr/ports/lang/python33/work/stage/usr/local/lib/python3.3/lib-dynload/_dbm.so):
 No such file or directory
 *** [fake-pkg] Error code 74

 [ replace python33 by python27 te get the similar error for 2.7 ]

 This would indicate that the dbm module wasn't built. It should be built
 and is a module that gives access to others that may be installed from
 the list below. The db modules below don't need to be installed first
 for _dbm.so to be built.

 This is an error compiling not related to the other modules. If your
 using a gui then scrollback in the terminal to see the error - increase
 scrollback limit if needed, from cli maybe use script to keep a log of
 the build to look through.

 Using command line in putty.
 I will try again, and scan de build output for more errors. So there should 
 be an error building the part in the stage tree?



 gettext libiconv and gmake are the only things that need to be installed
 before python to build.

 So where does it get the DBMS stuff from?

 Maybe there is an issue with you not building
 from /usr/ports ?

 That would be a first. This config is like this for about 6 years.
 And /user/ports links to this tree.


 And then hints:
 
 Note that some of the standard modules are provided as separate
 ports since they require extra dependencies:

 gdbmdatabases/py-gdbm
 sqlite3 databases/py-sqlite3
 tkinter x11-toolkits/py-tkinter

 Install them as needed.
 

 Which is nasty catch22, because one needs a recent/working python to
 actually be able to do this.

 How do other cope with this?


 Could using pkg to install a prebuilt binary package be an option?

 That would be the alternative, but I only do that, if nothing else works.
 I've grown to always build my stuff.


 What FreeBSD version are you using?

 I386 9.2-STABLE

Did a more thorow investigation during the build:


building 'dbm' extension
cc -fPIC -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -DNDEBUG
-DHAVE_NDBM_H -I. -IInclude -I./../Include -I/usr/local/include
-I/home2/usr/ports/lang/python27/work/Python-2.7.6/Include
-I/home2/usr/ports/lang/python27/work/Python-2.7.6/portbld.static -c
/home2/usr/ports/lang/python27/work/Python-2.7.6/Modules/dbmmodule.c -o
build/temp.freebsd-9.2-STABLE-i386-2.7/home2/usr/ports/lang/python27/work/Python-2.7.6/Modules/dbmmodule.o
cc -shared -L/usr/local/lib -pthread -L/usr/local/lib -pthread -O2 -pipe
-fno-strict-aliasing -I/usr/local/include
build/temp.freebsd-9.2-STABLE-i386-2.7/home2/usr/ports/lang/python27/work/Python-2.7.6/Modules/dbmmodule.o
-L/usr/local/lib -lgdbm_compat -o
build/lib.freebsd-9.2-STABLE-i386-2.7/dbm.so
*** WARNING: renaming dbm since importing it failed:
/usr/local/lib/libgdbm_compat.so.4: Undefined symbol gdbm_errno

Python build finished, but the necessary bits to build these modules
were not found:
linuxaudiodev  spwd   sunaudiodev
To find the necessary bits, look in 

FreeBSD Port: apache-hadoop-1.2.1_1

2014-04-08 Thread Steve Gailey
Hi,

I understand that you are the maintainer of the Hadoop port on FreeBSD. I was 
wondering if there were any plans to port Hadoop 2.2.x to FreeBSD? I'd be 
willing to help if I can, though may not have the right skills…

Very best regards.

Steve


[http://www.splunk.com/web_assets/v5/promos/SIG-email-101.jpg]http://www.splunk.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: FreeBSD Port: apache-hadoop-1.2.1_1

2014-04-08 Thread Pedro Giffuni
Hi Steve;

I've been very busy lately on other projects. I did look at porting the new 
hadoop and despite of the fact that you have to fetch a bunch of dependencies, 
it is not terribly difficult.

It is completely different to the existing port though so it should probably be 
a new port (hadoop2).

If you want to give it a try take a look at the Porter's Handbook:

http://www.freebsd.org/doc/en/books/porters-handbook/

I will be glad to help you if you get stuck somewhere.

Pedro.

On Tuesday, 8 April 2014, 15:08, Steve Gailey sgai...@splunk.com wrote:
 
Hi,


I understand that you are the maintainer of the Hadoop port on FreeBSD. I was 
wondering if there were any plans to port Hadoop 2.2.x to FreeBSD? I'd be 
willing to help if I can, though may not have the right skills…


Very best regards.


Steve


___
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: apache-hadoop-1.2.1_1

2014-04-08 Thread Steve Gailey
Thanks. I'll take a look and let you know how it goes...

Steve

Sent from my iPad

On 8 Apr 2014, at 22:46, Pedro Giffuni 
p...@apache.orgmailto:p...@apache.org wrote:

Hi Steve;

I've been very busy lately on other projects. I did look at porting the new 
hadoop and despite of the fact that you have to fetch a bunch of dependencies, 
it is not terribly difficult.

It is completely different to the existing port though so it should probably be 
a new port (hadoop2).

If you want to give it a try take a look at the Porter's Handbook:

http://www.freebsd.org/doc/en/books/porters-handbook/

I will be glad to help you if you get stuck somewhere.

Pedro.

On Tuesday, 8 April 2014, 15:08, Steve Gailey 
sgai...@splunk.commailto:sgai...@splunk.com wrote:
Hi,

I understand that you are the maintainer of the Hadoop port on FreeBSD. I was 
wondering if there were any plans to port Hadoop 2.2.x to FreeBSD? I'd be 
willing to help if I can, though may not have the right skills…

Very best regards.

Steve

___
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

2014-04-08 Thread Tijl Coosemans
On Tue, 08 Apr 2014 13:12:48 -0400 Mikhail T. wrote:
 On 08.04.2014 12:55, Tijl Coosemans wrote:
 On Tue, 08 Apr 2014 09:57:48 -0400 Mikhail T. wrote:
 On 08.04.2014 08:00, freebsd-ports-requ...@freebsd.org wrote:
 If people are using a port, then I would agree it should be kept
 regardless of maintainer status. But that doesn't mean keeping
 everything forever as long as it compiles.
 Why not? Why not keep everything forever as long as it compiles? Where
 is this idea coming from, that stuff must be continuously updated to be
 considered usable?
 It doesn't have to be updated continuously, but it has to be used.
 Keeping a port requires effort.  It needs to be kept up to date with
 infrastructural changes (like staging) and if nobody is using the port
 that's just a waste of effort.
 Tijl, there is no indication whatsoever, that ports on the chopping block are
 not used. The argument put forth by the proponents of the removals is thus: 
 The
 upstream authors haven't made a new release in a long time, therefor the
 software must be neither any good, nor see much use.
 
 I find this logic flawed -- some of my favorite books are more than 2000 years
 old, for example... Their authors certainly aren't making new releases, yet 
 they
 continue to be maintained, built (published), and used by generations.
 
 The closest we've ever come to estimating usage is the following: If there is
 any user-base to speak of, then there should be a person among them willing to
 maintain the port -- or pay someone to maintain it. This, too, is flawed in 
 my
 opinion -- expecting a graphics-artist, a biologist, or an audiophile to also 
 be
 a half-decent software engineer is a stretch; expecting them to pay for
 port-maintainership is also not fair, when the entire OS is free, done for 
 fun,
 rather than profit.
 
 Though I agree, that unmaintained ports should be dropped when they break due 
 to
 things like security bugs or compiler-upgrades, the self-inflicted wounds like
 infrastructure changes do not qualify. Volunteers taking it upon themselves to
 perform such changes, should be prepared to deal with all that's required for 
 them.

Volunteer time should not be wasted on ports nobody uses.  Removing such
ports is a good thing.

It's impossible to prove that a port is really unused, but if there are
enough indications that it is potentially unused it becomes reasonable to
assume that it is.  Lack of upstream development is one such indicator
and by itself it may not be enough but in the examples you've given it
isn't the only indicator.  For qvplay for instance the main argument is
that it is support software for a 250 kilopixel camera from the nineties.
For xmms there's xmms2, audacious and numerous other multimedia players.

Then, once it is reasonable to assume that a port is unused it is first
marked deprecated which gives users some time to step forward.  Only if
nobody shows up in the given time frame is a port actually removed and
even then it can still be restored in case some user does still show up.
___
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

2014-04-08 Thread A.J. 'Fonz' van Werven
Tijl Coosemans wrote:

 For xmms there's xmms2

That's no comparison. Not even fracking close. I for one am very glad that
Christian Weisgerber is having a look at the XMMS-related ports.

AvW

P.S. I do agree with your message as a whole, just not with this
particular example.

-- 
I'm not completely useless, I can be used as a bad example.


pgpEHwA2su5jt.pgp
Description: PGP signature


Re: Building Apache22 against OpenSSL port

2014-04-08 Thread olli hauer
On 2014-04-08 12:03, Egoitz Aurrekoetxea wrote:
 Hi, 
 
 Have tried building Apache on a recently upgraded ports collection for 
 linking Apache, php and all against openssl new port…. but no way of ending 
 up that way….
 
 I see always : 
 
 ldd /usr/local/libexec/apache22/mod_ssl.so 
 /usr/local/libexec/apache22/mod_ssl.so:
   libssl.so.7 = /usr/lib/libssl.so.7 (0x80163)
   libcrypto.so.7 = /lib/libcrypto.so.7 (0x801899000)
   libthr.so.3 = /lib/libthr.so.3 (0x801c84000)
   libc.so.7 = /lib/libc.so.7 (0x80081d000)
 
 
 Have tried with : 
 
 make WITH_OPENSSL_PORT=yes
 
 inserting in /etc/make.conf… but no way….
 
 has anyone suffered this same issue?
 
 Regards,

Hi Egoitz,

in case you are running on FreeBSD-10, then the update to apache22-2.2.27_1 
should fix the issue.

-- 
Regards,
olli
___
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: tex-kpathsea

2014-04-08 Thread Dewayne Geraghty
Please use the Problem Reporting system to advise your issue and enable
a volunteer to effectively work with you to resolve.

A common method is http://www.freebsd.org/send-pr.html

Often its useful to check if the problem has already been raised, and a
fix or workaround provided, by searching here
http://www.freebsd.org/cgi/query-pr-summary.cgi

Good luck.
Regards, Dewayne.
___
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: tex-kpathsea

2014-04-08 Thread Mark Linimon
Other useful resources:

http://portsmon.freebsd.org/portoverview.py?category=develportname=tex-kpathsea
http://www.freshports.org/devel/tex-kpathsea

mcl
___
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: print/hpijs + new cups + foomatic not working with hpijs-pcl3e printer.

2014-04-08 Thread Naram Qashat

On 04/08/14 07:08, Boris Samorodov wrote:

08.04.2014 13:55, Patrick Lamaiziere пишет:

Le Tue, 8 Apr 2014 14:05:00 +1000,
Robert Backhaus rob...@robbak.com a écrit :


  I've got a printing problem with the new cups.


I've got a similar problem with cups 1.7 and a Lexmark T640
using the foomatic filters. I've to use Generic Postcript printer to
make it works again.

That worked fine with cups 1.5. With 1.7 the printer prints nothing.
I guess something is broken.


Anything suspicious at /var/log/messages, /var/log/cups/*?
OS version and which cups / foomatic ports are installed?


Something that I think needs to be brought up. It appears that since CUPS 1.6.x, 
cups-filters is required for it to work with most printers. Since we are now on 
1.7.1, that means that print/cups-filters should also be installed. I ran into 
the same problem with my printer after the upgrade and installing cups-filters 
fixed it. I even put in an update for print/cups-filters just yesterday (trying 
to take over maintainership of it). I don't know if this means that 
print/cups-filters should be made into a libdepends on cups-base or not. My gut 
feeling is that it probably should, though, if CUPS is now useless without it.


Thanks,
Naram Qashat
___
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: Repair pkgng

2014-04-08 Thread Kevin Oberman
On Tue, Apr 8, 2014 at 12:44 PM, Melvyn Sopacua mel...@magemana.nl wrote:

 Hi,

 On Wed, 2 Apr 2014, Jakob Breivik Grimstveit wrote:


  /var/db/pkg only contains these files:

 $ find /var/db/pkg
 [...]
 /var/db/pkg/libyaml-0.1.6
 /var/db/pkg/libyaml-0.1.6/distfiles
 /var/db/pkg/gcc-ecj-4.5
 /var/db/pkg/gcc-ecj-4.5/distfiles
 /var/db/pkg/cmake-modules-2.8.10.2
 /var/db/pkg/cmake-modules-2.8.10.2/distfiles
 [...]


 Why do you have files that portmaster sticks in /var/db/ports in
 /var/db/pkg?
 Did you perhaps switch those directories on restore or have a faulty
 value in PORT_DBDIR?
 If so, does +CONTENTS exist in /var/db/ports/libyaml-0.1.6?


No, once you run pkgng, these files are in /var/db/pkg. The only files in
/var/db/ports are options files.

What a large number of people seem to miss is that pkgng no longer uses
/var/db/pkg/PORTNAME. It uses only /var/db/pkg/local.sqlite. All of the
stuff that used to be in the /var/db/pkg/PORTNAME directories like
+CONTENTS is obsolete. If you have it, it's leftovers from before
converting to pkgng except for distfiles.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.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: FreeBSD ports which are currently scheduled for deletion

2014-04-08 Thread Kevin Oberman
On Tue, Apr 8, 2014 at 3:20 PM, Tijl Coosemans t...@coosemans.org wrote:

 On Tue, 08 Apr 2014 13:12:48 -0400 Mikhail T. wrote:
  On 08.04.2014 12:55, Tijl Coosemans wrote:
  On Tue, 08 Apr 2014 09:57:48 -0400 Mikhail T. wrote:
  On 08.04.2014 08:00, freebsd-ports-requ...@freebsd.org wrote:
  If people are using a port, then I would agree it should be kept
  regardless of maintainer status. But that doesn't mean keeping
  everything forever as long as it compiles.
  Why not? Why not keep everything forever as long as it compiles?
 Where
  is this idea coming from, that stuff must be continuously updated to be
  considered usable?
  It doesn't have to be updated continuously, but it has to be used.
  Keeping a port requires effort.  It needs to be kept up to date with
  infrastructural changes (like staging) and if nobody is using the port
  that's just a waste of effort.
  Tijl, there is no indication whatsoever, that ports on the chopping
 block are
  not used. The argument put forth by the proponents of the removals is
 thus: The
  upstream authors haven't made a new release in a long time, therefor the
  software must be neither any good, nor see much use.
 
  I find this logic flawed -- some of my favorite books are more than 2000
 years
  old, for example... Their authors certainly aren't making new releases,
 yet they
  continue to be maintained, built (published), and used by generations.
 
  The closest we've ever come to estimating usage is the following: If
 there is
  any user-base to speak of, then there should be a person among them
 willing to
  maintain the port -- or pay someone to maintain it. This, too, is
 flawed in my
  opinion -- expecting a graphics-artist, a biologist, or an audiophile to
 also be
  a half-decent software engineer is a stretch; expecting them to pay for
  port-maintainership is also not fair, when the entire OS is free, done
 for fun,
  rather than profit.
 
  Though I agree, that unmaintained ports should be dropped when they
 break due to
  things like security bugs or compiler-upgrades, the self-inflicted
 wounds like
  infrastructure changes do not qualify. Volunteers taking it upon
 themselves to
  perform such changes, should be prepared to deal with all that's
 required for them.

 Volunteer time should not be wasted on ports nobody uses.  Removing such
 ports is a good thing.

 It's impossible to prove that a port is really unused, but if there are
 enough indications that it is potentially unused it becomes reasonable to
 assume that it is.  Lack of upstream development is one such indicator
 and by itself it may not be enough but in the examples you've given it
 isn't the only indicator.  For qvplay for instance the main argument is
 that it is support software for a 250 kilopixel camera from the nineties.
 For xmms there's xmms2, audacious and numerous other multimedia players.


Happily, a fix for xmms is in the offing. But you should realize that xmms2
is in no way a replacement for xmms, though the authors seemed to have
believed that it was.  Instead it is a needlessly complex client/server
system for playing  audio files. I'm sure that someone found xmms2 useful,
but for simply playing music, it is both overkill and complex to use.
Besides, DLNA has made it pretty obsolete as a media server.

If a port, say xmms, is believed obsolete, deprecation with a revision bump
so people who use it see that it was deprecated, I think you would hear if
you happened to be wrong about how obsolete it is.. :-) I that how it is
being done? If it is marked AND revision bumped, it is much more likely
that you will find out that a port is still being used BEFORE it is
removed. (I don't know whether or not this is the procedure.)
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.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