> Amazing, this worked.
Nope, built but still fails. :-(
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/net-avahi-app-core-dumps-signal-11-tp5878518p5880958.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
> People who deleted all ports, removed /usr/local and reinstalled
> have reported that they do not have the problem.
>
> I have deleted the contents of /usr/local/lib and am running a portupgrade
> -afu
>
> I'll report back if that is a quicker fix.
Amazing, this worked.
Apparently, some Gnom
Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD
i386 10.0 Release.
A)
Clang does not need to to be installed first.
> B)
> FreeBSD 10's change to pkg(8) (a.k.a. PKGNG) affects the portupgrade tools
> as
> well as the package tools.
> Even if you are not using package
On Mon, Jan 27, 2014 at 04:14:14PM +0100, Herbert J. Skuhra wrote:
> Den 27.01.2014 11:48, skrev O. Hartmann:
> > On all FreeBSD 9.2-STABLE oboxes, the update of port lang/ruby19 fails
> > with
> >
> > checking for nroff... /usr/bin/nroff
> > .ext/include/amd64-freebsd9/ruby/config.h updated
> > r
On Mon, Jan 27, 2014 at 12:11:52PM -0600, Edwin L. Culp W. wrote:
> ===> Building for ruby-1.9.3.484_1,1
> make: don't know how to make OPENSSL_CFLAGS. Stop
> *** [do-build] Error code 1
>
> I just want to be sure that it isn't me, hopefully.
I'm unable to reproduce, and based on other responses
Hi Ports subscribers,
I've been trying out a recent build of what may become the FreeBSD 10.0
release for ARM ("FreeBSD 10.0-RELEASE (RPI-B) #0 r261135"). There
aren't any non-x86 pkg builds available yet, so I used portsnap to
install ports.
All the ports I have tried to install (tmux, curl
body {}
.blocktitle{color:#1b1515; font-family: Arial; font-size: 12px; margin:1px 0 0
28px;}
.blocktitle div{color:#1b1515; font-family: Arial; font-size: 12px;}
.blocktitle a{color:#1b1515; font-family: Arial; font-size: 12px;
text-decoration:none;}
.bc{display:inline; margin:6px 5px 0 6px;}
.
Hello,
On Tue, Jan 28, 2014 at 5:53 PM, Koop Mast wrote:
>
> Hmm the element warnings seem to be harmless, but the but the above gvfs
> warning seems to be more interesting. Could you rebuild/install gvfs and see
> if that would fix this?
reinstalling gvfs does not fix this.
> I assume you have
Am 28.01.2014 15:10, schrieb Baptiste Daroussin:
> On Tue, Jan 28, 2014 at 03:07:46PM +0100, Rainer Hurling wrote:
>> Am 28.01.2014 13:48 (UTC+1) schrieb Dag-Erling Smørgrav:
>>> Dag-Erling Smørgrav writes:
Actually, the file *is* 2696168 bytes long. With the following patch,
fetch(1) w
On 27-1-2014 20:45, Torfinn Ingolfsen wrote:
(g-ir-compiler:83467): GVFS-RemoteVolumeMonitor-WARNING **: cannot
open directory /usr/local/share/gvfs/remote-volume-monitors: Error
opening directory '/usr/local/share/gvfs/remote-volume-monitors': No
such file or directory
Is this a known issue?
El 28/01/2014 16:04, "Daniel Siechniewicz"
escribió:
>
> Hi,
>
> Just a little stick in this anthill:
>
> - I've seen a few people volunteering, but so far the reaction seems
> to be: "oh, yeah, well, ah, cool". I'd expect, with all the talk about
> how much they are needed, that they will be "sna
Dimitry Andric wrote:
>
> --Apple-Mail=_442D467F-1929-40CE-90B7-0CAD6B1BC540
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> charset=us-ascii
>
> On 28 Jan 2014, at 16:28, Julian H. Stacey wrote:
> > Hi po...@freebsd.org
> > I'm looking for ports/math/hexcalc or replacement
On 1/28/14, 10:04 AM, Daniel Siechniewicz wrote:
Hi,
Just a little stick in this anthill:
- I've seen a few people volunteering, but so far the reaction seems
to be: "oh, yeah, well, ah, cool". I'd expect, with all the talk about
how much they are needed, that they will be "snatched" immediat
On Tue, 28 Jan 2014 15:10:49 +0100
Dag-Erling Smørgrav wrote:
> Rainer Hurling writes:
> > In the meantime, the author of fotoxx, Michael Cornelison, answered
> > to me two times. Mike confirms, that the file is fetchable from
> > different Linux systems and that in his eyes, there is no problem
Hi po...@freebsd.org
I'm looking for ports/math/hexcalc or replacement it dissapeared after
8.2-RELEASE, it's not in http://www.freebsd.org/ports/math.html
How should one find:
Why it dissapeared ?
(eg maybe it just lacked a maintainer & I have to re-port it? Or ... ?
What to replace
On 28 Jan 2014, at 16:28, Julian H. Stacey wrote:
> Hi po...@freebsd.org
> I'm looking for ports/math/hexcalc or replacement it dissapeared after
> 8.2-RELEASE, it's not in http://www.freebsd.org/ports/math.html
>
> How should one find:
> Why it dissapeared ?
> (eg maybe it just lacked a
Hi,
Just a little stick in this anthill:
- I've seen a few people volunteering, but so far the reaction seems
to be: "oh, yeah, well, ah, cool". I'd expect, with all the talk about
how much they are needed, that they will be "snatched" immediately and
coerced into doing unspeakable things (like p
Support stage
Use options helpers
Modernize lib_depends
-
Build ID: 20140128134000-26024
Job owner: b...@freebsd.org
Buildtime: 36 minutes
Enddate: Tue, 28 Jan 2014 14:16:11 GMT
Revisi
On Tue, Jan 28, 2014 at 03:07:46PM +0100, Rainer Hurling wrote:
> Am 28.01.2014 13:48 (UTC+1) schrieb Dag-Erling Smørgrav:
> > Dag-Erling Smørgrav writes:
> >> Actually, the file *is* 2696168 bytes long. With the following patch,
> >> fetch(1) will still hang getting the last 1018 bytes, but the
Rainer Hurling writes:
> In the meantime, the author of fotoxx, Michael Cornelison, answered to
> me two times. Mike confirms, that the file is fetchable from different
> Linux systems and that in his eyes, there is no problem with reported
> and de facto file length.
>
> Trying to load fotoxx-14.
Am 28.01.2014 13:48 (UTC+1) schrieb Dag-Erling Smørgrav:
> Dag-Erling Smørgrav writes:
>> Actually, the file *is* 2696168 bytes long. With the following patch,
>> fetch(1) will still hang getting the last 1018 bytes, but the file will
>> be complete and the download will be successful.
>
> Compl
Dag-Erling Smørgrav writes:
> Actually, the file *is* 2696168 bytes long. With the following patch,
> fetch(1) will still hang getting the last 1018 bytes, but the file will
> be complete and the download will be successful.
Completely fixed (no hang, no missing data) in head@261230.
DES
--
Da
Take care of CONFIGURE_ARGS and PKGNAMEPREFIX also.
-
Build ID: 20140128120800-48820
Job owner: k...@freebsd.org
Buildtime: 9 minutes
Enddate: Tue, 28 Jan 2014 12:17:23 GMT
Revision:
Make use of ${_MYSQL_SERVER} to support Percona/MariaDB along with MySQL.
PR: ports/186116
Submitted by: fluffy
-
Build ID: 20140128115800-52658
Job owner: k...@freebsd.org
Buildtime:
Am 28.01.2014 11:04 (UTC+1) schrieb Dag-Erling Smørgrav:
> Michael Gmelin writes:
>> His web server reports a content length of 2696186, but only provides
>> 2696168 bytes of data. Tools like wget and curl just stop downloading
>> data, while fetch hangs waiting for those 18 extra bytes.
>
> Actu
Michael Gmelin writes:
> His web server reports a content length of 2696186, but only provides
> 2696168 bytes of data. Tools like wget and curl just stop downloading
> data, while fetch hangs waiting for those 18 extra bytes.
Actually, the file *is* 2696168 bytes long. With the following patch,
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
On 01/28/14 00:06, Baptiste Daroussin wrote:
On Mon, Jan 27, 2014 at 11:25:18PM +0100, Andrea Venturoli wrote:
Hello.
The box is 9.1p10/i386.
As per subject, since the upgrade to 1.0.5_3, xmms started crashing
whenever I added a wma file to the playlist.
"portupgrade -Rf xmms-wma" did not hel
I can confirm this issue for other ports, too: security/openssl fails
with "don't know how to make WHOLE_ARCHIVE_FLAG" and www/lynx fails
with "don't know how to make helpdir."
As far as I can see, svn revision 341159 still works, at least for lang/ruby19.
___
29 matches
Mail list logo
