Re: The vim port needs a refresh

[John Marino]

On 5/28/2013 02:44, Martin Wilke wrote:


On the first note, complain about the patches to the upstream, not to us. This 
patches problem has been around since forever and so long the upstream
is not changing anything about it, nor do we.


Hi Martin,
This statement is hand-waives the entire discussion, which took as a 
*given* that upstream is the problem who crazy policies will not change. 
 I already said that "95%" of the blame (probably more) should get 
allocated there.


The whole discussion started because upstream will clearly not change.

About rolling your own distfile, I completely disagree because we do not 
know what the maintaner has changed,

and seeing it from the security view, I prefer to get all my patches from the 
original mirrors.


1. Yes, some amount of trust is necessary but hopefully we don't have 
maintainers that aren't trusted.


2. A trivial script can verify the roll-up contains only official 
patches, which could be executed by the committer prior to committing 
changes to distfile.  That's a pretty easy "security" issue to address.


I get your point but that issue could be solved.
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"

Re: The vim port needs a refresh

[Jeremy Messenger]

On Sat, May 25, 2013 at 3:50 AM, Chris Rees  wrote:
> On 24 May 2013 22:23, Kenta Suzumoto  wrote:
>>
>> Hello all. The editors/vim port is currently a mess and needs some changes.
>>
>> - It fetches almost 700 patches from what seems like a dial-up connection in 
>> AUSTRALIA.
>>
>> You might as well be downloading a 1080p movie from a rock in the north 
>> pole, because that's about how fast it is.
>> This can be very easily avoided by putting all the patches into a single 
>> tarball and hosting it anywhere decent. I've
>> seen someone in ##freebsd on freenode handing out a tarball with all the 
>> patches many times, and everyone asks
>> "why isn't this the default? why is some random guy giving me distfiles?" 
>> etc. Seems like a no-brainer.
>>
>> - By default, it builds lots of gui stuff that certainly almost no one wants
>>
>> It almost seems like the vim-lite port should be renamed vim and the vim 
>> port should be renamed gvim. I had to
>> google to come up with this solution, because I can't even disable that 
>> stuff in "make config" (another problem!)
>>
>> .if ${.CURDIR}=="/usr/ports/editors/vim"
>> WITH_VIM_OPTIONS=yes
>> WITHOUT_X11=yes
>> .endif
>>
>> People shouldn't have to find this hack to be able to install vim normally 
>> (and no, telling them to use vim-lite isn't normal).
>> I'm surprised that none of these changes have been made yet. I've heard it's 
>> "because the maintainer won't listen to reason"
>> but I have no way to know if that's the case or not. I also heard bapt@ had 
>> an optionsNG patch that he wouldn't
>> integrate into the port for some reason. Please, let's get this stuff fixed 
>> once and for all. None of it requires a large amount
>> of work on anyone's part.
>
> I'm very sad to talk of a fellow developer like this, but I'm afraid
> the maintainer of vim is a contrarian who thinks he knows better than
> everyone else on the matter.
>
> For years, people have been begging him to get over his fear of
> OPTIONS, and he sits in the way of progress against almost everyone's
> wishes.

FYI, the OPTIONS is not required to have. I agree with him pretty much
everything about the OPTIONS. I have refused to add OPTIONS in any of
my ports before I gave up a lot of them long time ago. All of his
thought of OPTIONS are very valid. The OPTIONS still has bugs.

BTW: I always have BATCH=yes in my make.conf, because I hate OPTIONS a lot.

> He has also impeded progress on the bash port, resulting in the
> ridiculous situation where we now have two bash ports, where one will
> do.  For historical reasons, people seem reluctant to confront him
> about this, and he ignores all attempts to reason about it.
>
> It's far beyond time to remove David O'Brien from MAINTAINER lines--
> he doesn't do the job properly anyway; several PRs he's timed out on
> for his ports:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177597
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174965
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175447
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/178462
>
> Last time I timed him out on a PR I was subjected to a tirade from
> him, with questionable justification, but I may process these too when
> I have time.
>
> Alternatively, perhaps we need an editors/vim-options port
>
> Chris


--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: The vim port needs a refresh

[RW]

On Tue, 28 May 2013 02:02:00 +0200
John Marino wrote:

> On 5/28/2013 01:48, RW wrote:
> > On Tue, 28 May 2013 01:13:43 +0200
> >> No.  That's not what those words mean.
> >> Please stop assuming that somebody builds Vim repeatedly and start
> >> assuming it's built for the very first time.
> >
> > Why wouldn't I? Are you seriously suggesting that it's the norm to

> 2. Every software built from source is built "the first time" on each 
> server.

That's not the same as first time, you do have access to other distfile
directories. This is what I suspected from the start, that this is
almost completely about laziness.
___
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: The vim port needs a refresh

[Martin Wilke]

On the first note, complain about the patches to the upstream, not to us. This 
patches problem has been around since forever and so long the upstream
is not changing anything about it, nor do we. About rolling your own distfile, 
I completely disagree because we do not know what the maintaner has changed,
and seeing it from the security view, I prefer to get all my patches from the 
original mirrors.

- Martin

P.S. This is solely my personal view and does not reflect the official 
portmgr's stand.

On May 28, 2013, at 8:02 AM, John Marino  wrote:

> On 5/28/2013 01:48, RW wrote:
>> On Tue, 28 May 2013 01:13:43 +0200
>>> No.  That's not what those words mean.
>>> Please stop assuming that somebody builds Vim repeatedly and start
>>> assuming it's built for the very first time.
>> 
>> Why wouldn't I? Are you seriously suggesting that it's the norm to build
>> a port once and then never build it again?
> 
> 1. Yes, that can happen.  I'm working on some servers with 1600 days uptime 
> (should be 2300 days but the data center relocated them a few years ago) and 
> most of the software on them is from 2007.
> 
> 2. Every software built from source is built "the first time" on each server.
> 
> 3. It is nice to cater to new users.
> 
> 4. It's good practice to target the lowest common denominator
> 
> 
>> They add up to 3 MB which is noticeable to someone on dialup even
>> when compressed. Ordinarily, it wouldn't matter, but as I said before
>> VIM is something that could be part of a very minimal build - something
>> that might be maintained even over very slow dial-up.
> 
> If you are going to use dialup as an example, then it's much, much worse to 
> download them all individually.  Unless you're building vim repeatedly and 
> often, the opportunity for double-downloads isn't that high.  If it's a real 
> worry then the 100-patch rollups would be better than the full aggregates.
> 
> 
> 
>> Some people may find ftp faster or more reliable - it depends on your
>> circumstances.
> 
> That's not my experience but for the sake of argument I'll accept the point.  
> It still seems like overkill though.
> 
> 
>>> It validated my story as more than anecdotal.
>> 
>> No it didn't because I already told you that there unreliable servers
>> then.
> 
> That doesn't invalidate what I said.  You can't assume everyone portsnaps 
> daily.  A commit in January might not trickle down for months.  All you can 
> say is, "yes, that was the case but a PR was written against it and since 
> closed, please try again with a current port tree".  Plus I think you said it 
> after I told the story.
> ___
> 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"
> 

+-oOO--(_)--OOo-+
With best Regards,
   Martin Wilke (miwi_(at)_FreeBSD.org)

Mess with the Best, Die like the Rest

___
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

[Cy Schubert]

In message <20130525230731.ga93...@mail.lunabase.org>, Ted Faber writes:
> 
> --O5XBE6gyVG5Rl6Rj
> Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK"
> Content-Disposition: inline
> 
> 
> --YZ5djTAD1cGYuMQK
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> 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. =20
> 
> 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/GENERI=
> C  i386
> 
> Firefox is built under the most recent clang port.  Firefox options are
> all the defaults (make rmconfig).
> 
> I rebuilt all the ports from scratch within the last week.
> 
> I've attached  a gdb trace from just running the firefox binary under
> gdb.  I'm not sure I believe it, but clues are scarce on the ground.  I
> can get a ktrace if it will help.
> 
> Let me know if you have any suggestions.

No suggestions. Just a me too.

Compiling with -g results in address space memory exhaustion.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.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: The vim port needs a refresh

[John Marino]

On 5/28/2013 01:48, RW wrote:

On Tue, 28 May 2013 01:13:43 +0200

No.  That's not what those words mean.
Please stop assuming that somebody builds Vim repeatedly and start
assuming it's built for the very first time.


Why wouldn't I? Are you seriously suggesting that it's the norm to build
a port once and then never build it again?


1. Yes, that can happen.  I'm working on some servers with 1600 days 
uptime (should be 2300 days but the data center relocated them a few 
years ago) and most of the software on them is from 2007.


2. Every software built from source is built "the first time" on each 
server.


3. It is nice to cater to new users.

4. It's good practice to target the lowest common denominator



They add up to 3 MB which is noticeable to someone on dialup even
when compressed. Ordinarily, it wouldn't matter, but as I said before
VIM is something that could be part of a very minimal build - something
that might be maintained even over very slow dial-up.


If you are going to use dialup as an example, then it's much, much worse 
to download them all individually.  Unless you're building vim 
repeatedly and often, the opportunity for double-downloads isn't that 
high.  If it's a real worry then the 100-patch rollups would be better 
than the full aggregates.





Some people may find ftp faster or more reliable - it depends on your
circumstances.


That's not my experience but for the sake of argument I'll accept the 
point.  It still seems like overkill though.




It validated my story as more than anecdotal.


No it didn't because I already told you that there unreliable servers
then.


That doesn't invalidate what I said.  You can't assume everyone 
portsnaps daily.  A commit in January might not trickle down for months. 
 All you can say is, "yes, that was the case but a PR was written 
against it and since closed, please try again with a current port tree". 
 Plus I think you said it after I told the story.

___
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: The vim port needs a refresh

[RW]

On Tue, 28 May 2013 01:13:43 +0200
John Marino wrote:

> On 5/28/2013 01:05, RW wrote:
> > On Mon, 27 May 2013 22:33:53 +0200
> > John Marino wrote:

> > In other words downloading every patch twice.
> 
> No.  That's not what those words mean.
> Please stop assuming that somebody builds Vim repeatedly and start 
> assuming it's built for the very first time.  

Why wouldn't I? Are you seriously suggesting that it's the norm to build
a port once and then never build it again?


> Also, given these
> patches are a couple of kilobytes at most, a compressed tarball of
> 100 patches (or even 700 patches) is negligible.  Even if somebody
> with a cache downloaded it twice, so what?   It's not even noticeable.

They add up to 3 MB which is noticeable to someone on dialup even
when compressed. Ordinarily, it wouldn't matter, but as I said before
VIM is something that could be part of a very minimal build - something
that might be maintained even over very slow dial-up.

> >> At the very, very least maybe only HTTP hosts are listed for VIM (I
> >> just checked bsd.sites.mk, the ftp sites are all at the end of the
> >> list now)
> >
> > All 13 http links would  have to fail before the ftp links are
> > tried.
> 
> 
> So what's the point of having them on the list?  Isn't 13 mirrors
> enough?

Some people may find ftp faster or more reliable - it depends on your
circumstances.

> >> I may have still been on the old bsd.sites.mk with a site>  10
> >> seconds per file.  (this is yet another data point)
> >
> > We already knew that it was slow before January, so that's
> > irrelevant.
> 
> 
> It validated my story as more than anecdotal.

No it didn't because I already told you that there unreliable servers
then.

___
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] r319234: 4x leftovers

[Ports-QAT]

Do not try to remove directories not created by the port
-

  Build ID:  20130527131401-45390
  Job owner: b...@freebsd.org
  Buildtime: 10 hours
  Enddate:   Mon, 27 May 2013 23:18:25 GMT

  Revision:  r319234
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=319234

-

Port:www/p5-HTML-TreeBuilder-LibXML 0.22

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20130527131401-45390-143852/p5-HTML-TreeBuilder-LibXML-0.22.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20130527131401-45390-143853/p5-HTML-TreeBuilder-LibXML-0.22.log

  Buildgroup: 8.3-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20130527131401-45390-143854/p5-HTML-TreeBuilder-LibXML-0.22.log

  Buildgroup: 8.3-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20130527131401-45390-143855/p5-HTML-TreeBuilder-LibXML-0.22.log


--
Buildarchive URL: 
redports 
___
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: The vim port needs a refresh

[John Marino]

On 5/28/2013 01:05, RW wrote:

On Mon, 27 May 2013 22:33:53 +0200
John Marino wrote:


On 5/27/2013 22:09, RW wrote:

On Mon, 27 May 2013 20:38:11 +0200
John Marino wrote:


No, that's something you just made up. It is however vague and
anecdotal. We have only one data point that we know is from this
year and not self-inflicted, even if the others are, for all we
know it could still be fast most of the time.

Some monitoring would be useful.



However you slice it, a distinfo file with 1000+ entries is
completely absurd.  95% of the blame goes to Vim developers.
However, it is within the realm of feasibility to pre-package patches
in batches of 100 (or conversely 1 tarball of patches rolled for
every time patch count hits multiple of 100).


In other words downloading every patch twice.


No.  That's not what those words mean.
Please stop assuming that somebody builds Vim repeatedly and start 
assuming it's built for the very first time.  Also, given these patches 
are a couple of kilobytes at most, a compressed tarball of 100 patches 
(or even 700 patches) is negligible.  Even if somebody with a cache 
downloaded it twice, so what?   It's not even noticeable.





At the very, very least maybe only HTTP hosts are listed for VIM (I
just checked bsd.sites.mk, the ftp sites are all at the end of the
list now)


All 13 http links would  have to fail before the ftp links are
tried.



So what's the point of having them on the list?  Isn't 13 mirrors enough?



I may have still been on the old bsd.sites.mk with a site>  10
seconds per file.  (this is yet another data point)


We already knew that it was slow before January, so that's irrelevant.



It validated my story as more than anecdotal.
___
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: Is latest portsnap snapshot corrupted?

[RW]

On Mon, 27 May 2013 22:15:29 +0100
Bruce Cran wrote:

> On 27/05/2013 22:13, Gökşin Akdeniz wrote:
> > Ia am not a dev, but portstree snapshot is fixed. Simply run
> >
> > '# portsnap fetch extract && portsdb -u'
> >
> > and you will get a fresh snapshot of ports tree.
> >
> 
> Is '# portsnap fetch update' not sufficient? It seemed to work here.
> 

Extract shouldn't be needed, the problem was in the snapshot, not the
portstree.
___
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: The vim port needs a refresh

[RW]

On Mon, 27 May 2013 22:33:53 +0200
John Marino wrote:

> On 5/27/2013 22:09, RW wrote:
> > On Mon, 27 May 2013 20:38:11 +0200
> > John Marino wrote:
> >
> >
> > No, that's something you just made up. It is however vague and
> > anecdotal. We have only one data point that we know is from this
> > year and not self-inflicted, even if the others are, for all we
> > know it could still be fast most of the time.
> >
> > Some monitoring would be useful.
> >
> 
> However you slice it, a distinfo file with 1000+ entries is
> completely absurd.  95% of the blame goes to Vim developers.
> However, it is within the realm of feasibility to pre-package patches
> in batches of 100 (or conversely 1 tarball of patches rolled for
> every time patch count hits multiple of 100).

In other words downloading every patch twice. 


> At the very, very least maybe only HTTP hosts are listed for VIM (I
> just checked bsd.sites.mk, the ftp sites are all at the end of the
> list now)

All 13 http links would  have to fail before the ftp links are
tried.
 
> It looks like some of this was addressed in January though:

I already told you that.

> 
> I may have still been on the old bsd.sites.mk with a site > 10
> seconds per file.  (this is yet another data point) 

We already knew that it was slow before January, so that's irrelevant. 
___
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"

Ranking Number 1 on Google is the goal of every website owner

[Blue Shark Solution]

 __

Sent To [1]po...@freebsd.org
[2]Unsubscribe from this list

  Blue Shark Solution · 3rd Floor, Shakti Complex, N/R APC, Anand -
   Vidhyanagar Road, ANAND - 388 001  Ph: +91-2692-249586
[3][logo.png]

References

   Visible links
   1. mailto:po...@freebsd.org
   2. 
http://www.bluesharksolution.in/bssmailing//unsubscribes.php?email=po...@freebsd.org
   3. http://www.bluesharksolution.com/

   Hidden links:
   4. http://www.seoservicescompany-bss.com/
   5. mailto:i...@bluesharksolution.com
   6. http://www.seoservicescompany-bss.com/guaranteed-seo-services.php
   7. http://www.seoservicescompany-bss.com/all-in-one-seo-packages.php
   8. http://www.seoservicescompany-bss.com/search-engine-optimization.php
   9. http://www.seoservicescompany-bss.com/pay-per-click.php
  10. http://www.seoservicescompany-bss.com/social-media-marketing.php
  11. http://www.seoservicescompany-bss.com/request-quotes.php
  12. mailto:i...@bluesharksolution.com
  13. http://www.bluesharksolution.com/
  14. http://www.seoservicescompany-bss.com/
  15. https://www.facebook.com/SeoServicesCompanyBSS
  16. https://twitter.com/BssSeoservices
___
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: Is latest portsnap snapshot corrupted?

[Kimmo Paasiala]

On Tue, May 28, 2013 at 12:15 AM, Bruce Cran  wrote:
> On 27/05/2013 22:13, Gökşin Akdeniz wrote:
>>
>> Ia am not a dev, but portstree snapshot is fixed. Simply run
>>
>> '# portsnap fetch extract && portsdb -u'
>>
>> and you will get a fresh snapshot of ports tree.
>>
>
> Is '# portsnap fetch update' not sufficient? It seemed to work here.
>
> --
> Bruce Cran
>

The portsdb tool is not part of the base system if anyone is
wondering, it comes from ports-mgmt/portupgrade. Not everyone is using
portupgrade so if you post any instructions like this make sure you
mention the extra tools involved and what they relate to.

-Kimmo
___
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: textproc/libvisio

[Baptiste Daroussin]

On Mon, May 27, 2013 at 01:10:52PM -0400, Mike Jakubik wrote:
> Hello,
> 
> I am unable to compile this port, below is the output from gcc48 and 
> clang 3.2.
> 
> 9.1-STABLE FreeBSD 9.1-STABLE #0: Wed May 15 17:07:33 EDT 2013
> 
> gmake[4]: Entering directory 
> `/usr/ports/textproc/libvisio/work/libvisio-0.0.27/src/conv/raw'
>CXX  vsd2raw.o
>CXXLDvsd2raw
> ../../lib/.libs/libvisio-0.0.so: undefined reference to 
> `std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, 
> std::__detail::_List_node_base*)'
> ../../lib/.libs/libvisio-0.0.so: undefined reference to 
> `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
> ../../lib/.libs/libvisio-0.0.so: undefined reference to 
> `std::__detail::_List_node_base::_M_unhook()'
> /usr/local/lib/libwpd-0.9.so: undefined reference to 
> `std::__detail::_List_node_base::_M_unhook()@GLIBCXX_3.4.15'
> /usr/local/lib/libwpd-0.9.so: undefined reference to 
> `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@GLIBCXX_3.4.15'
> ../../lib/.libs/libvisio-0.0.so: undefined reference to 
> `std::ctype::_M_widen_init() const'
> collect2: error: ld returned 1 exit status
> gmake[4]: *** [vsd2raw] Error 1
> 
> 
> gmake[4]: Entering directory 
> `/usr/ports/textproc/libvisio/work/libvisio-0.0.27/src/conv/raw'
>CXX  vsd2raw.o
>CXXLDvsd2raw
> /usr/local/lib/libwpd-0.9.so: undefined reference to 
> `std::__detail::_List_node_base::_M_unhook()@GLIBCXX_3.4.15'
> /usr/local/lib/libwpd-0.9.so: undefined reference to 
> `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@GLIBCXX_3.4.15'
> /usr/local/lib/libwpg-0.2.so: undefined reference to 
> `std::ctype::_M_widen_init() const'
> clang++: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> gmake[4]: *** [vsd2raw] Error 1
> 
> Thanks.
> ___
> freebsd-off...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-office
> To unsubscribe, send any mail to "freebsd-office-unsubscr...@freebsd.org"

you are mixing different incompatibles version of libstdc++ there is nothing we
can do about it, if you decide to use custom compilers you have tp be careful
that the whole chain is using the same libstdc++, either the one from gcc48 or
the one from base.

regards,
Bapt


pgpnklsbRZ_v6.pgp
Description: PGP signature

Re: Is latest portsnap snapshot corrupted?

[Jakub Lach]

Indeed snapshot looks fixed, thanks for all replies!

I don't use INDEX.db so should be fine without portsdb...



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Is-latest-portsnap-snapshot-corrupted-tp5815448p5815588.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: Why does Samba requires 777 permissions on /tmp

[sindrome]

Chris,

That did it!  Thanks so much for the help.  Just in case if anyone else is
reading this long thread, you cannot have a colon period (:.) at the end of
your pathmeaning do not include the current directory as part of the
$path



On Mon, May 27, 2013 at 3:54 PM, Chris Rees  wrote:

>
> On 27 May 2013 20:45, "sindrome"  wrote:
> >
> > Hi Guys,
> >
> > I just got home from being out of town and the problem still persists
> even
> > after I removed . from my path.
> >
> > echo $PATH
> >
> /bin:/usr/lib:/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/home/sindrome/.gnupg:/home/sindrome/bin:/home/sindrome/docs:/home/sindrome/docs/info:/home/sindrome/docs/config:/sbin:/bin:/etc:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:
>
> Remove the trailing : too?
>
> Chris
>
> > Here's what I get when I portupgrade an outdated port.
> >
> >
> > /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
> > Insecure world writable dir /tmp/ in PATH, mode 041777
> > /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:1170: warning:
> > Insecure world writable dir /tmp/ in PATH, mode 041777
> > /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgmisc.rb:108: warning:
> > Insecure world writable dir /tmp/ in PATH, mode 041777
> > /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
> > Insecure world writable dir /tmp/ in PATH, mode 041777
> >
> >
> >
> > On Mon, May 20, 2013 at 4:58 PM, Simon Wright 
> wrote:
> >
> > > On 20/05/2013 15:38, Bob Eager wrote:
> > >
> > >> On Mon, 20 May 2013 08:03:09 -0500
> > >> sindrome  wrote:
> > >>
> > >> What I think is happening is that portupgrade is building and running
> > >> shell scripts in /tmp. It's running them with (in ruby):
> > >>
> > >>system('/tmp/script') [roughly]
> > >>
> > >> The ruby runtime is checking the *path-to-the-command* and THAT is
> what
> > >> it's complaining about.
> > >>
> > >> Try setting PKG_TMPDIR (in pkgtools.conf) to some suitable non world
> > >> writable temporary directory.
> > >>
> > >> I have an older ports tree on this machine or I'd try it myself. I had
> > >> to download the latest sources to check all this,
> > >>
> > >
> > > Trying to summarise what I've tested here with the results.
> > >
> > > My PKG_TMPDIR and TMPDIR are set to /var/tmp:
> > >
> > > pkgtools.conf:
> > >
> > >   ENV['TMPDIR'] ||= '/var/tmp'
> > >   ENV['PKG_TMPDIR'] ||= '/var/tmp'
> > >   ENV['PORTSDIR'] ||= '/usr/ports'
> > >   ENV['PACKAGES'] ||= ENV['PORTSDIR'] + '/packages'
> > >
> > > from /usr/local/etc/sudoers:
> > > # Uncomment if needed to preserve environmental variables related to
> the
> > > # FreeBSD pkg_* utilities and fetch.
> > > Defaultsenv_keep += "PKG_PATH PKG_DBDIR PKG_TMPDIR TMPDIR
> > > PACKAGEROOT PACKAGESITE PKGDIR FTP_PASSIVE_MODE"
> > >
> > > [simon@vmserver04 ~]$ ls -ld /var/tmp
> > > drwxrwxr-t  9 root  wheel  33280 May 20 23:02 /var/tmp/
> > >
> > > Note: /var/tmp is not world writeable
> > >
> > > [simon@vmserver04 ~]$ echo $PATH
> > > /sbin:/bin:/usr/sbin:/usr/bin:**/usr/games:/usr/local/sbin:/**
> > > usr/local/bin:/usr/X11R6/bin:/**usr/local/scripts:
> > >
> > > root@vmserver04:/root # echo $PATH
> > > /sbin:/bin:/usr/sbin:/usr/bin:**/usr/games:/usr/local/sbin:/**
>
> > > usr/local/bin:/root/bin
> > >
> > > I run portupgrade via sudo but both $PATH's show no /tmp or .
> > >
> > > [simon@vmserver04 ~]$ ruby -v
> > > ruby 1.8.7 (2012-10-12 patchlevel 371) [amd64-freebsd9]
> > >
> > > portupgrade-2.4.10.5_1,2 FreeBSD ports/packages administration and
> > > management tool s
> > >
> > > Other (not likely) relevant stuff:
> > > - I have /usr/ports mounted rw with NFS
> > > - I have the packages directory mounted rw with NFS and amd then
> redefine
> > > $PACKAGES to point to the mount point
> > > This has been working for several years with no issues
> > >
> > > [simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
> > > --->  Reading default options: -v -D -l /var/tmp/portupgrade.results_
>
> > > 20130520-22:**56:25 -L /var/tmp/portupgrade/%s::%s.**log
> > > --->  Session started at: Mon, 20 May 2013 22:56:26 +0200
> > > ** None has been installed or upgraded.
> > > --->  Saving the results to '/var/tmp/portupgrade.results_20130520-22
> **
> > > :56:25'
> > > /usr/local/lib/ruby/site_ruby/**1.8/pkgtools/pkgtools.rb:483: warning:
>
> > > Insecure world writable dir /tmp/ in PATH, mode 041777
> > >
> > > Still the complaint about /tmp/
> > >
> > > [simon@vmserver04 ~]$ sudo chmod 1775 /tmp
> > >
> > > [simon@vmserver04 ~]$ ls -ld /tmp
> > > drwxrwxr-t  9 root  wheel  1024 May 20 23:16 /tmp/
> > >
> > > [simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
> > > --->  Reading default options: -v -D -l /var/tmp/portupgrade.results_
>
> > > 20130520-23:**16:07 -L /var/tmp/portupgrade/%s::%s.**log
> > > --->  Session started at: Mon, 20 May 2013 23:16:07 +0200
> > > ** None has been installed or upgraded.
> > > --->  Saving the results to '/var/tmp
> > > /portupgrade.results_2

Re: Is latest portsnap snapshot corrupted?

[Bruce Cran]

On 27/05/2013 22:13, Gökşin Akdeniz wrote:

Ia am not a dev, but portstree snapshot is fixed. Simply run

'# portsnap fetch extract && portsdb -u'

and you will get a fresh snapshot of ports tree.



Is '# portsnap fetch update' not sufficient? It seemed to work here.

--
Bruce Cran
___
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: Is latest portsnap snapshot corrupted?

[Gökşin Akdeniz]

Mon, 27 May 2013 11:32:22 -0700 (PDT) tarihinde
Jakub Lach  yazmış:

> Could some dev chime in?

Ia am not a dev, but portstree snapshot is fixed. Simply run 

'# portsnap fetch extract && portsdb -u'

and you will get a fresh snapshot of ports tree.

-- 
Gökşin Akdeniz 


pgpMix2fXkQzY.pgp
Description: PGP signature

Re: Why does Samba requires 777 permissions on /tmp

[Chris Rees]

On 27 May 2013 20:45, "sindrome"  wrote:
>
> Hi Guys,
>
> I just got home from being out of town and the problem still persists even
> after I removed . from my path.
>
> echo $PATH
>
/bin:/usr/lib:/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/home/sindrome/.gnupg:/home/sindrome/bin:/home/sindrome/docs:/home/sindrome/docs/info:/home/sindrome/docs/config:/sbin:/bin:/etc:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:

Remove the trailing : too?

Chris

> Here's what I get when I portupgrade an outdated port.
>
>
> /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
> Insecure world writable dir /tmp/ in PATH, mode 041777
> /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:1170: warning:
> Insecure world writable dir /tmp/ in PATH, mode 041777
> /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgmisc.rb:108: warning:
> Insecure world writable dir /tmp/ in PATH, mode 041777
> /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
> Insecure world writable dir /tmp/ in PATH, mode 041777
>
>
>
> On Mon, May 20, 2013 at 4:58 PM, Simon Wright 
wrote:
>
> > On 20/05/2013 15:38, Bob Eager wrote:
> >
> >> On Mon, 20 May 2013 08:03:09 -0500
> >> sindrome  wrote:
> >>
> >> What I think is happening is that portupgrade is building and running
> >> shell scripts in /tmp. It's running them with (in ruby):
> >>
> >>system('/tmp/script') [roughly]
> >>
> >> The ruby runtime is checking the *path-to-the-command* and THAT is what
> >> it's complaining about.
> >>
> >> Try setting PKG_TMPDIR (in pkgtools.conf) to some suitable non world
> >> writable temporary directory.
> >>
> >> I have an older ports tree on this machine or I'd try it myself. I had
> >> to download the latest sources to check all this,
> >>
> >
> > Trying to summarise what I've tested here with the results.
> >
> > My PKG_TMPDIR and TMPDIR are set to /var/tmp:
> >
> > pkgtools.conf:
> >
> >   ENV['TMPDIR'] ||= '/var/tmp'
> >   ENV['PKG_TMPDIR'] ||= '/var/tmp'
> >   ENV['PORTSDIR'] ||= '/usr/ports'
> >   ENV['PACKAGES'] ||= ENV['PORTSDIR'] + '/packages'
> >
> > from /usr/local/etc/sudoers:
> > # Uncomment if needed to preserve environmental variables related to the
> > # FreeBSD pkg_* utilities and fetch.
> > Defaultsenv_keep += "PKG_PATH PKG_DBDIR PKG_TMPDIR TMPDIR
> > PACKAGEROOT PACKAGESITE PKGDIR FTP_PASSIVE_MODE"
> >
> > [simon@vmserver04 ~]$ ls -ld /var/tmp
> > drwxrwxr-t  9 root  wheel  33280 May 20 23:02 /var/tmp/
> >
> > Note: /var/tmp is not world writeable
> >
> > [simon@vmserver04 ~]$ echo $PATH
> > /sbin:/bin:/usr/sbin:/usr/bin:**/usr/games:/usr/local/sbin:/**
> > usr/local/bin:/usr/X11R6/bin:/**usr/local/scripts:
> >
> > root@vmserver04:/root # echo $PATH
> > /sbin:/bin:/usr/sbin:/usr/bin:**/usr/games:/usr/local/sbin:/**
> > usr/local/bin:/root/bin
> >
> > I run portupgrade via sudo but both $PATH's show no /tmp or .
> >
> > [simon@vmserver04 ~]$ ruby -v
> > ruby 1.8.7 (2012-10-12 patchlevel 371) [amd64-freebsd9]
> >
> > portupgrade-2.4.10.5_1,2 FreeBSD ports/packages administration and
> > management tool s
> >
> > Other (not likely) relevant stuff:
> > - I have /usr/ports mounted rw with NFS
> > - I have the packages directory mounted rw with NFS and amd then
redefine
> > $PACKAGES to point to the mount point
> > This has been working for several years with no issues
> >
> > [simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
> > --->  Reading default options: -v -D -l /var/tmp/portupgrade.results_
> > 20130520-22:**56:25 -L /var/tmp/portupgrade/%s::%s.**log
> > --->  Session started at: Mon, 20 May 2013 22:56:26 +0200
> > ** None has been installed or upgraded.
> > --->  Saving the results to '/var/tmp/portupgrade.results_20130520-22**
> > :56:25'
> > /usr/local/lib/ruby/site_ruby/**1.8/pkgtools/pkgtools.rb:483: warning:
> > Insecure world writable dir /tmp/ in PATH, mode 041777
> >
> > Still the complaint about /tmp/
> >
> > [simon@vmserver04 ~]$ sudo chmod 1775 /tmp
> >
> > [simon@vmserver04 ~]$ ls -ld /tmp
> > drwxrwxr-t  9 root  wheel  1024 May 20 23:16 /tmp/
> >
> > [simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
> > --->  Reading default options: -v -D -l /var/tmp/portupgrade.results_
> > 20130520-23:**16:07 -L /var/tmp/portupgrade/%s::%s.**log
> > --->  Session started at: Mon, 20 May 2013 23:16:07 +0200
> > ** None has been installed or upgraded.
> > --->  Saving the results to '/var/tmp
> > /portupgrade.results_20130520-23:16:07'
> > --->  Session ended at: Mon, 20 May 2013 23:16:08 +0200 (consumed
00:00:00)
> >
> > No more complaint.
> >
> > I can't read the portupgrade code well enough to see what it's doing
with
> > the script, but if Bob is right that Ruby is running the portupgrade
> > commands from /tmp then the error is within the checks in Ruby which is
> > saying the 777 permission on /tmp is not acceptable, 775 *is*
acceptable.
> > Which is strange since surely then everyone with 777 permissions on /tmp
> > would be seeing this message? Does th

Re: The vim port needs a refresh

[John Marino]

On 5/27/2013 22:09, RW wrote:

On Mon, 27 May 2013 20:38:11 +0200
John Marino wrote:


No, that's something you just made up. It is however vague and
anecdotal. We have only one data point that we know is from this year
and not self-inflicted, even if the others are, for all we know it
could still be fast most of the time.

Some monitoring would be useful.



However you slice it, a distinfo file with 1000+ entries is completely 
absurd.  95% of the blame goes to Vim developers.  However, it is within 
the realm of feasibility to pre-package patches in batches of 100 (or 
conversely 1 tarball of patches rolled for every time patch count hits 
multiple of 100).


At the very, very least maybe only HTTP hosts are listed for VIM (I just 
checked bsd.sites.mk, the ftp sites are all at the end of the list now)


It looks like some of this was addressed in January though:

Revision 309899 - (view) (download) (annotate) - [select for diffs]
Modified Thu Jan 3 17:38:30 2013 UTC (4 months, 3 weeks ago) by rm
File length: 63730 byte(s)
Diff to previous 309846
- sync list of vim mirrors with official list on 
http://www.vim.org/mirrors.php

- remove dead vim sites
- remove vim sites with missing files
- remove slow vim sites (> 10 seconds to serve a file) after repeated
  complaints by blakkheim (I'm not sure what's that)
PR: 174875
Submitted by:   4...@hushmail.com


I may have still been on the old bsd.sites.mk with a site > 10 seconds 
per file.  (this is yet another data point) so maybe the situation is 
much better now.

___
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: The vim port needs a refresh

[RW]

On Mon, 27 May 2013 20:38:11 +0200
John Marino wrote:


> >> It's obviously true since multiple users are seeing it.  (the whole
> >> 1080 movie analogy, remember?)
> >
> > It not obviously true that you aren't all either making this problem
> > with your make.conf settings or referring to a problem that existed
> > last year.
> 
> It was THIS year and it wasn't that long ago.  January in the worst 
> case.  But now you're explicitly telling multiple users that they
> didn't in fact experience this?


No, that's something you just made up. It is however vague and
anecdotal. We have only one data point that we know is from this year
and not self-inflicted, even if the others are, for all we know it
could still be fast most of the time. 

Some monitoring would be useful.

___
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: Why does Samba requires 777 permissions on /tmp

[sindrome]

Hi Bob,

I just went into /usr/local/etc/pkgtools.conf and changed the PKG_TMPDIR
variable to a non-world writable directory called /build and still see the
warnings below:

/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
Insecure world writable dir /tmp/ in PATH, mode 041777
/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:1170: warning:
Insecure world writable dir /tmp/ in PATH, mode 041777
/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgmisc.rb:108: warning:
Insecure world writable dir /tmp/ in PATH, mode 041777
/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
Insecure world writable dir /tmp/ in PATH, mode 041777


On Mon, May 27, 2013 at 2:54 PM, Bob Eager  wrote:

> Did you try changing PKG_TMPDIR as I suggested? (see below)
>
>
> On Mon, 27 May 2013 14:45:05 -0500
> sindrome  wrote:
>
> > Hi Guys,
> >
> > I just got home from being out of town and the problem still persists
> > even after I removed . from my path.
> >
> > echo $PATH
> >
> /bin:/usr/lib:/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/home/sindrome/.gnupg:/home/sindrome/bin:/home/sindrome/docs:/home/sindrome/docs/info:/home/sindrome/docs/config:/sbin:/bin:/etc:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:
> >
> > Here's what I get when I portupgrade an outdated port.
> >
> >
> > /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
> > Insecure world writable dir /tmp/ in PATH, mode 041777
> > /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:1170: warning:
> > Insecure world writable dir /tmp/ in PATH, mode 041777
> > /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgmisc.rb:108: warning:
> > Insecure world writable dir /tmp/ in PATH, mode 041777
> > /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
> > Insecure world writable dir /tmp/ in PATH, mode 041777
> >
> >
> >
> > On Mon, May 20, 2013 at 4:58 PM, Simon Wright 
> > wrote:
> >
> > > On 20/05/2013 15:38, Bob Eager wrote:
> > >
> > >> On Mon, 20 May 2013 08:03:09 -0500
> > >> sindrome  wrote:
> > >>
> > >> What I think is happening is that portupgrade is building and
> > >> running shell scripts in /tmp. It's running them with (in ruby):
> > >>
> > >>system('/tmp/script') [roughly]
> > >>
> > >> The ruby runtime is checking the *path-to-the-command* and THAT is
> > >> what it's complaining about.
> > >>
> > >> Try setting PKG_TMPDIR (in pkgtools.conf) to some suitable non
> > >> world writable temporary directory.
> > >>
> > >> I have an older ports tree on this machine or I'd try it myself. I
> > >> had to download the latest sources to check all this,
> > >>
> > >
> > > Trying to summarise what I've tested here with the results.
> > >
> > > My PKG_TMPDIR and TMPDIR are set to /var/tmp:
> > >
> > > pkgtools.conf:
> > >
> > >   ENV['TMPDIR'] ||= '/var/tmp'
> > >   ENV['PKG_TMPDIR'] ||= '/var/tmp'
> > >   ENV['PORTSDIR'] ||= '/usr/ports'
> > >   ENV['PACKAGES'] ||= ENV['PORTSDIR'] + '/packages'
> > >
> > > from /usr/local/etc/sudoers:
> > > # Uncomment if needed to preserve environmental variables related
> > > to the # FreeBSD pkg_* utilities and fetch.
> > > Defaultsenv_keep += "PKG_PATH PKG_DBDIR PKG_TMPDIR TMPDIR
> > > PACKAGEROOT PACKAGESITE PKGDIR FTP_PASSIVE_MODE"
> > >
> > > [simon@vmserver04 ~]$ ls -ld /var/tmp
> > > drwxrwxr-t  9 root  wheel  33280 May 20 23:02 /var/tmp/
> > >
> > > Note: /var/tmp is not world writeable
> > >
> > > [simon@vmserver04 ~]$ echo $PATH
> > > /sbin:/bin:/usr/sbin:/usr/bin:**/usr/games:/usr/local/sbin:/**
> > > usr/local/bin:/usr/X11R6/bin:/**usr/local/scripts:
> > >
> > > root@vmserver04:/root # echo $PATH
> > > /sbin:/bin:/usr/sbin:/usr/bin:**/usr/games:/usr/local/sbin:/**
> > > usr/local/bin:/root/bin
> > >
> > > I run portupgrade via sudo but both $PATH's show no /tmp or .
> > >
> > > [simon@vmserver04 ~]$ ruby -v
> > > ruby 1.8.7 (2012-10-12 patchlevel 371) [amd64-freebsd9]
> > >
> > > portupgrade-2.4.10.5_1,2 FreeBSD ports/packages administration and
> > > management tool s
> > >
> > > Other (not likely) relevant stuff:
> > > - I have /usr/ports mounted rw with NFS
> > > - I have the packages directory mounted rw with NFS and amd then
> > > redefine $PACKAGES to point to the mount point
> > > This has been working for several years with no issues
> > >
> > > [simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
> > > --->  Reading default options: -v -D
> > > -l /var/tmp/portupgrade.results_ 20130520-22:**56:25
> > > -L /var/tmp/portupgrade/%s::%s.**log --->  Session started at: Mon,
> > > 20 May 2013 22:56:26 +0200 ** None has been installed or upgraded.
> > > --->  Saving the results to
> > > '/var/tmp/portupgrade.results_20130520-22** :56:25'
> > > /usr/local/lib/ruby/site_ruby/**1.8/pkgtools/pkgtools.rb:483:
> > > warning: Insecure world writable dir /tmp/ in PATH, mode 041777
> > >
> > > Still the complaint about /tmp/
> > >
> > > [simon@vmserver04 ~]$ sudo chmod 1775 /tmp
> > >
> > > [simon@vmserver04 ~]$ ls -ld /

Re: Why does Samba requires 777 permissions on /tmp

[Bob Eager]

Did you try changing PKG_TMPDIR as I suggested? (see below)


On Mon, 27 May 2013 14:45:05 -0500
sindrome  wrote:

> Hi Guys,
> 
> I just got home from being out of town and the problem still persists
> even after I removed . from my path.
> 
> echo $PATH
> /bin:/usr/lib:/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/home/sindrome/.gnupg:/home/sindrome/bin:/home/sindrome/docs:/home/sindrome/docs/info:/home/sindrome/docs/config:/sbin:/bin:/etc:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:
> 
> Here's what I get when I portupgrade an outdated port.
> 
> 
> /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
> Insecure world writable dir /tmp/ in PATH, mode 041777
> /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:1170: warning:
> Insecure world writable dir /tmp/ in PATH, mode 041777
> /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgmisc.rb:108: warning:
> Insecure world writable dir /tmp/ in PATH, mode 041777
> /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
> Insecure world writable dir /tmp/ in PATH, mode 041777
> 
> 
> 
> On Mon, May 20, 2013 at 4:58 PM, Simon Wright 
> wrote:
> 
> > On 20/05/2013 15:38, Bob Eager wrote:
> >
> >> On Mon, 20 May 2013 08:03:09 -0500
> >> sindrome  wrote:
> >>
> >> What I think is happening is that portupgrade is building and
> >> running shell scripts in /tmp. It's running them with (in ruby):
> >>
> >>system('/tmp/script') [roughly]
> >>
> >> The ruby runtime is checking the *path-to-the-command* and THAT is
> >> what it's complaining about.
> >>
> >> Try setting PKG_TMPDIR (in pkgtools.conf) to some suitable non
> >> world writable temporary directory.
> >>
> >> I have an older ports tree on this machine or I'd try it myself. I
> >> had to download the latest sources to check all this,
> >>
> >
> > Trying to summarise what I've tested here with the results.
> >
> > My PKG_TMPDIR and TMPDIR are set to /var/tmp:
> >
> > pkgtools.conf:
> >
> >   ENV['TMPDIR'] ||= '/var/tmp'
> >   ENV['PKG_TMPDIR'] ||= '/var/tmp'
> >   ENV['PORTSDIR'] ||= '/usr/ports'
> >   ENV['PACKAGES'] ||= ENV['PORTSDIR'] + '/packages'
> >
> > from /usr/local/etc/sudoers:
> > # Uncomment if needed to preserve environmental variables related
> > to the # FreeBSD pkg_* utilities and fetch.
> > Defaultsenv_keep += "PKG_PATH PKG_DBDIR PKG_TMPDIR TMPDIR
> > PACKAGEROOT PACKAGESITE PKGDIR FTP_PASSIVE_MODE"
> >
> > [simon@vmserver04 ~]$ ls -ld /var/tmp
> > drwxrwxr-t  9 root  wheel  33280 May 20 23:02 /var/tmp/
> >
> > Note: /var/tmp is not world writeable
> >
> > [simon@vmserver04 ~]$ echo $PATH
> > /sbin:/bin:/usr/sbin:/usr/bin:**/usr/games:/usr/local/sbin:/**
> > usr/local/bin:/usr/X11R6/bin:/**usr/local/scripts:
> >
> > root@vmserver04:/root # echo $PATH
> > /sbin:/bin:/usr/sbin:/usr/bin:**/usr/games:/usr/local/sbin:/**
> > usr/local/bin:/root/bin
> >
> > I run portupgrade via sudo but both $PATH's show no /tmp or .
> >
> > [simon@vmserver04 ~]$ ruby -v
> > ruby 1.8.7 (2012-10-12 patchlevel 371) [amd64-freebsd9]
> >
> > portupgrade-2.4.10.5_1,2 FreeBSD ports/packages administration and
> > management tool s
> >
> > Other (not likely) relevant stuff:
> > - I have /usr/ports mounted rw with NFS
> > - I have the packages directory mounted rw with NFS and amd then
> > redefine $PACKAGES to point to the mount point
> > This has been working for several years with no issues
> >
> > [simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
> > --->  Reading default options: -v -D
> > -l /var/tmp/portupgrade.results_ 20130520-22:**56:25
> > -L /var/tmp/portupgrade/%s::%s.**log --->  Session started at: Mon,
> > 20 May 2013 22:56:26 +0200 ** None has been installed or upgraded.
> > --->  Saving the results to
> > '/var/tmp/portupgrade.results_20130520-22** :56:25'
> > /usr/local/lib/ruby/site_ruby/**1.8/pkgtools/pkgtools.rb:483:
> > warning: Insecure world writable dir /tmp/ in PATH, mode 041777
> >
> > Still the complaint about /tmp/
> >
> > [simon@vmserver04 ~]$ sudo chmod 1775 /tmp
> >
> > [simon@vmserver04 ~]$ ls -ld /tmp
> > drwxrwxr-t  9 root  wheel  1024 May 20 23:16 /tmp/
> >
> > [simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
> > --->  Reading default options: -v -D
> > -l /var/tmp/portupgrade.results_ 20130520-23:**16:07
> > -L /var/tmp/portupgrade/%s::%s.**log --->  Session started at: Mon,
> > 20 May 2013 23:16:07 +0200 ** None has been installed or upgraded.
> > --->  Saving the results to '/var/tmp
> > /portupgrade.results_20130520-23:16:07'
> > --->  Session ended at: Mon, 20 May 2013 23:16:08 +0200 (consumed
> > 00:00:00)
> >
> > No more complaint.
> >
> > I can't read the portupgrade code well enough to see what it's
> > doing with the script, but if Bob is right that Ruby is running the
> > portupgrade commands from /tmp then the error is within the checks
> > in Ruby which is saying the 777 permission on /tmp is not
> > acceptable, 775 *is* acceptable. Which is strange since surely then
> > everyone with 777 perm

Re: Why does Samba requires 777 permissions on /tmp

[sindrome]

Hi Guys,

I just got home from being out of town and the problem still persists even
after I removed . from my path.

echo $PATH
/bin:/usr/lib:/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/home/sindrome/.gnupg:/home/sindrome/bin:/home/sindrome/docs:/home/sindrome/docs/info:/home/sindrome/docs/config:/sbin:/bin:/etc:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:

Here's what I get when I portupgrade an outdated port.


/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
Insecure world writable dir /tmp/ in PATH, mode 041777
/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:1170: warning:
Insecure world writable dir /tmp/ in PATH, mode 041777
/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgmisc.rb:108: warning:
Insecure world writable dir /tmp/ in PATH, mode 041777
/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning:
Insecure world writable dir /tmp/ in PATH, mode 041777



On Mon, May 20, 2013 at 4:58 PM, Simon Wright  wrote:

> On 20/05/2013 15:38, Bob Eager wrote:
>
>> On Mon, 20 May 2013 08:03:09 -0500
>> sindrome  wrote:
>>
>> What I think is happening is that portupgrade is building and running
>> shell scripts in /tmp. It's running them with (in ruby):
>>
>>system('/tmp/script') [roughly]
>>
>> The ruby runtime is checking the *path-to-the-command* and THAT is what
>> it's complaining about.
>>
>> Try setting PKG_TMPDIR (in pkgtools.conf) to some suitable non world
>> writable temporary directory.
>>
>> I have an older ports tree on this machine or I'd try it myself. I had
>> to download the latest sources to check all this,
>>
>
> Trying to summarise what I've tested here with the results.
>
> My PKG_TMPDIR and TMPDIR are set to /var/tmp:
>
> pkgtools.conf:
>
>   ENV['TMPDIR'] ||= '/var/tmp'
>   ENV['PKG_TMPDIR'] ||= '/var/tmp'
>   ENV['PORTSDIR'] ||= '/usr/ports'
>   ENV['PACKAGES'] ||= ENV['PORTSDIR'] + '/packages'
>
> from /usr/local/etc/sudoers:
> # Uncomment if needed to preserve environmental variables related to the
> # FreeBSD pkg_* utilities and fetch.
> Defaultsenv_keep += "PKG_PATH PKG_DBDIR PKG_TMPDIR TMPDIR
> PACKAGEROOT PACKAGESITE PKGDIR FTP_PASSIVE_MODE"
>
> [simon@vmserver04 ~]$ ls -ld /var/tmp
> drwxrwxr-t  9 root  wheel  33280 May 20 23:02 /var/tmp/
>
> Note: /var/tmp is not world writeable
>
> [simon@vmserver04 ~]$ echo $PATH
> /sbin:/bin:/usr/sbin:/usr/bin:**/usr/games:/usr/local/sbin:/**
> usr/local/bin:/usr/X11R6/bin:/**usr/local/scripts:
>
> root@vmserver04:/root # echo $PATH
> /sbin:/bin:/usr/sbin:/usr/bin:**/usr/games:/usr/local/sbin:/**
> usr/local/bin:/root/bin
>
> I run portupgrade via sudo but both $PATH's show no /tmp or .
>
> [simon@vmserver04 ~]$ ruby -v
> ruby 1.8.7 (2012-10-12 patchlevel 371) [amd64-freebsd9]
>
> portupgrade-2.4.10.5_1,2 FreeBSD ports/packages administration and
> management tool s
>
> Other (not likely) relevant stuff:
> - I have /usr/ports mounted rw with NFS
> - I have the packages directory mounted rw with NFS and amd then redefine
> $PACKAGES to point to the mount point
> This has been working for several years with no issues
>
> [simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
> --->  Reading default options: -v -D -l /var/tmp/portupgrade.results_
> 20130520-22:**56:25 -L /var/tmp/portupgrade/%s::%s.**log
> --->  Session started at: Mon, 20 May 2013 22:56:26 +0200
> ** None has been installed or upgraded.
> --->  Saving the results to '/var/tmp/portupgrade.results_20130520-22**
> :56:25'
> /usr/local/lib/ruby/site_ruby/**1.8/pkgtools/pkgtools.rb:483: warning:
> Insecure world writable dir /tmp/ in PATH, mode 041777
>
> Still the complaint about /tmp/
>
> [simon@vmserver04 ~]$ sudo chmod 1775 /tmp
>
> [simon@vmserver04 ~]$ ls -ld /tmp
> drwxrwxr-t  9 root  wheel  1024 May 20 23:16 /tmp/
>
> [simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
> --->  Reading default options: -v -D -l /var/tmp/portupgrade.results_
> 20130520-23:**16:07 -L /var/tmp/portupgrade/%s::%s.**log
> --->  Session started at: Mon, 20 May 2013 23:16:07 +0200
> ** None has been installed or upgraded.
> --->  Saving the results to '/var/tmp
> /portupgrade.results_20130520-23:16:07'
> --->  Session ended at: Mon, 20 May 2013 23:16:08 +0200 (consumed 00:00:00)
>
> No more complaint.
>
> I can't read the portupgrade code well enough to see what it's doing with
> the script, but if Bob is right that Ruby is running the portupgrade
> commands from /tmp then the error is within the checks in Ruby which is
> saying the 777 permission on /tmp is not acceptable, 775 *is* acceptable.
> Which is strange since surely then everyone with 777 permissions on /tmp
> would be seeing this message? Does this get us any further?
>
> Thanks for all the input, it is appreciated.
>
> Cheers
>
> Simon.
>
> __**_
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-ports
> To u

ejabberd port: default config not working

[Matthew Pounsett]

I've just installed ejabberd from ports 

> sudo portversion -v ejabberd
ejabberd-2.1.11 =  up-to-date with port 

Just to get it running, I've put the sample configs in place as running 
configs.  I did a quick scan through them to look for any obvious changes that 
needed to be made for local configuration and started up the daemon. 

The only oddity I found is that ejabberdctl.cfg refers to 
/var/run/ejabberd/ejabberd.pid for the ejabberd PID file, but that directory 
wasn't created.  I tried creating it, but ejabberd writes nothing there.

> ps auxww | grep ejabberd
ejabberd  70497  0.0  0.1  8072  1236  ??  S 7:06PM   0:00.01 
/usr/local/lib/erlang/erts-5.9.3.1/bin/epmd -daemon

> ls -la /var/run/ejabberd/
total 4
drwxr-xr-x   2 ejabberd  ejabberd   512 May 24 18:39 .
drwxr-xr-x  12 root  wheel 1024 May 27 19:09 ..
 
Despite this the daemon seems to have started fine.  However, the control 
client isn't able to talk to ejabberd.  
 

> sudo ejabberdctl register matt conundrum.com [REDACTED]
Failed RPC connection to the node ejabberd@localhost: nodedown

Commands to start an ejabberd node:
  start  Start an ejabberd node in server mode
  debug  Attach an interactive Erlang shell to a running ejabberd node
  live   Start an ejabberd node in live (interactive) mode

Optional parameters when starting an ejabberd node:
  --config-dir dir   Config ejabberd:/usr/local/etc/ejabberd
  --config file  Config ejabberd:/usr/local/etc/ejabberd/ejabberd.cfg
  --ctl-config file  Config ejabberdctl: /usr/local/etc/ejabberd/ejabberdctl.cfg
  --logs dir Directory for logs: /var/log/ejabberd
  --spool dirDatabase spool dir: /var/spool/ejabberd
  --node nodenameejabberd node name: ejabberd@localhost

Is this just the missing PID file that's the problem?  I can't find a reference 
to a PID config in the ejabberd.cfg file, so I'm not sure if it's really 
expected to write something in that location or not.  I'm also unsure how 
ejabberdctl is trying to communicate with ejabberd .. whether the PID file is 
even important..

Anyone know what I'm missing here?
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: The vim port needs a refresh

[John Marino]

On 5/27/2013 19:36, RW wrote:

On Mon, 27 May 2013 18:44:55 +0200
John Marino wrote:




Great.  With the previous mirror I had it would have taken well over
an hour back when the patch count was 700.


By default it should be the same mirror if you tested it this year.
Slow and dead mirrors were removed at the beginning of January.

And you still haven't said whether you have any make.conf settings that
affect the order.


I didn't change any settings.
It may have been an FTP site rather than an HTTP site.  I seem to recall 
some work to move HTTP over FTP fairly recently.





It's obviously true since multiple users are seeing it.  (the whole
1080 movie analogy, remember?)


It not obviously true that you aren't all either making this problem
with your make.conf settings or referring to a problem that existed last
year.


It was THIS year and it wasn't that long ago.  January in the worst 
case.  But now you're explicitly telling multiple users that they didn't 
in fact experience this?

___
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: Is latest portsnap snapshot corrupted?

[Jakub Lach]

Thanks!

Could some dev chime in?



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Is-latest-portsnap-snapshot-corrupted-tp5815448p5815520.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: Proposal: do not show up the dialog(1) by default?

[Kevin Oberman]

On Mon, May 27, 2013 at 10:35 AM, Matthias Andree wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 23.05.2013 07:45, schrieb Baptiste Daroussin:
> > hi,
> >
> > A lot of people seems to be complaining about the configuration dialog
> popping
> > up all the time.
> >
> > What if we change the default behaviour to not pop up the dialog each
> time there
> > is a changed option but only when the user explicitly type make config?
> >
> > Just a proposal, please give your opinion.
> >
> > Of course make config-recursive behaviour won't change.
>
> This would subvert the whole options story.
>
> I propose to not show the dialog for standard options, such as DOCS (née
> PORTDOCS), EXAMPLES, NLS and thereabouts.
>
> And IF we show-on-changed, we need to highlight the changed options and
> place the cursor on the first displayed one, to not waste everybody's time.
>

YES! I get tired of looking through the long list of options for ports
like ffmpeg or apache trying to spot the change! Some highlight or visible
flag would be very nice.

-- 
R. Kevin Oberman, Network Engineer
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: Proposal: do not show up the dialog(1) by default?

[Matthias Andree]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 23.05.2013 07:45, schrieb Baptiste Daroussin:
> hi,
> 
> A lot of people seems to be complaining about the configuration dialog popping
> up all the time.
> 
> What if we change the default behaviour to not pop up the dialog each time 
> there
> is a changed option but only when the user explicitly type make config?
> 
> Just a proposal, please give your opinion.
> 
> Of course make config-recursive behaviour won't change.

This would subvert the whole options story.

I propose to not show the dialog for standard options, such as DOCS (née
PORTDOCS), EXAMPLES, NLS and thereabouts.

And IF we show-on-changed, we need to highlight the changed options and
place the cursor on the first displayed one, to not waste everybody's time.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGjmXkACgkQvmGDOQUufZVt+QCfarE1IN/djczxlJIqPTaP3kmR
W+YAn0eNI0bSqM2/7Ys9RyoAgqLJeFup
=6v6T
-END PGP SIGNATURE-
___
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: The vim port needs a refresh

[RW]

On Mon, 27 May 2013 18:44:55 +0200
John Marino wrote:



> Great.  With the previous mirror I had it would have taken well over
> an hour back when the patch count was 700.

By default it should be the same mirror if you tested it this year.
Slow and dead mirrors were removed at the beginning of January.

And you still haven't said whether you have any make.conf settings that
affect the order.

> It's obviously true since multiple users are seeing it.  (the whole
> 1080 movie analogy, remember?)

It not obviously true that you aren't all either making this problem
with your make.conf settings or referring to a problem that existed last
year.

___
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: [HEADSUP] default version of Ruby switched to 1.9

[Eitan Adler]

On 27 May 2013 15:26, Steve Wills  wrote:
> Hi All,
>
> Just a heads up, I've finally switched the default version of Ruby to 1.9.
> There is a note in UPDATING that should help. Let us know if you have any
> trouble.

Thank you, I'm sure this took an enormous amount of time and effort on
your part.

-- 
Eitan Adler
___
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: textproc/libvisio

[Mike Jakubik]

Hello,

I am unable to compile this port, below is the output from gcc48 and 
clang 3.2.


9.1-STABLE FreeBSD 9.1-STABLE #0: Wed May 15 17:07:33 EDT 2013

gmake[4]: Entering directory 
`/usr/ports/textproc/libvisio/work/libvisio-0.0.27/src/conv/raw'

  CXX  vsd2raw.o
  CXXLDvsd2raw
../../lib/.libs/libvisio-0.0.so: undefined reference to 
`std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, 
std::__detail::_List_node_base*)'
../../lib/.libs/libvisio-0.0.so: undefined reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
../../lib/.libs/libvisio-0.0.so: undefined reference to 
`std::__detail::_List_node_base::_M_unhook()'
/usr/local/lib/libwpd-0.9.so: undefined reference to 
`std::__detail::_List_node_base::_M_unhook()@GLIBCXX_3.4.15'
/usr/local/lib/libwpd-0.9.so: undefined reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@GLIBCXX_3.4.15'
../../lib/.libs/libvisio-0.0.so: undefined reference to 
`std::ctype::_M_widen_init() const'

collect2: error: ld returned 1 exit status
gmake[4]: *** [vsd2raw] Error 1


gmake[4]: Entering directory 
`/usr/ports/textproc/libvisio/work/libvisio-0.0.27/src/conv/raw'

  CXX  vsd2raw.o
  CXXLDvsd2raw
/usr/local/lib/libwpd-0.9.so: undefined reference to 
`std::__detail::_List_node_base::_M_unhook()@GLIBCXX_3.4.15'
/usr/local/lib/libwpd-0.9.so: undefined reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@GLIBCXX_3.4.15'
/usr/local/lib/libwpg-0.2.so: undefined reference to 
`std::ctype::_M_widen_init() const'
clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)

gmake[4]: *** [vsd2raw] Error 1

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: The vim port needs a refresh

[John Marino]

On 5/27/2013 18:36, RW wrote:



Like 4 patches
per minute slow.  You have no sympathy for somebody that has to
download all 900+ patches from the beginning?


A little if it's the first time they've ever built vim on FreeBSD,
and they have have genuine good reason for not being able to wait an
extra minute.


900 patches /4 patches/min = 225 minutes = 3.75 hours
hardly an "extra minute"



The "slow" complaint is not trivial, it's very, very real.   Saying
you haven't seen it doesn't make it less real, you probably just
didn't sit there and watch it from patch#1.


No, it's because I've been using FreeBSD since before August 2010
when that patch was created.


I've been using FreeBSD since version 4.10, but that doesn't imply that 
I've every downloaded vim patches before.



I just tried deleting all the patches and refetching and it took 74
seconds, it's scarcely a major problem.


Great.  With the previous mirror I had it would have taken well over an 
hour back when the patch count was 700.   That is a major problem for 
others, despite the fact that it's not a problem for you.


It's obviously true since multiple users are seeing it.  (the whole 1080 
movie analogy, remember?)


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"

Re: The vim port needs a refresh

[RW]

On Mon, 27 May 2013 17:19:40 +0200
John Marino wrote:

> On 5/27/2013 16:34, RW wrote:
> >
> > It would hurt people with a slow connections who would end-up
> > having to download most of the patches twice. I've a lot more
> > sympathy with people in that situation than with someone who
> > doesn't cache and then complains it's slow.
> 
> Trust me.
> If you get the wrong mirror, ...


I'm not sure what you mean by that. Unless something has changed
everyone tries the mirrors list in the same order. Have you set
something in make.conf to alter that? In particular
RANDOMIZE_MASTER_SITES is well known for poor speeds.

> Like 4 patches 
> per minute slow.  You have no sympathy for somebody that has to
> download all 900+ patches from the beginning?

A little if it's the first time they've ever built vim on FreeBSD,
and they have have genuine good reason for not being able to wait an
extra minute.

> The "trick", of course, is to override MASTER_SITES in the
> environment, e.g. "make MASTER_SITES= fetch" and then force fetching
> from FreeBSD. Then it gets all the patches pretty quickly.

It looks to me like you've just proposed a more sensible solution:
change PATCH_SITES or MASTER_SITE_VIM to exclude slow servers and/or
bring the fast ones to the front of the list.


> The "slow" complaint is not trivial, it's very, very real.   Saying
> you haven't seen it doesn't make it less real, you probably just
> didn't sit there and watch it from patch#1.

No, it's because I've been using FreeBSD since before August 2010
when that patch was created.

I just tried deleting all the patches and refetching and it took 74
seconds, it's scarcely a major problem.
___
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: Proper way to access executable's "environment"?

[Stefan Ehmann]

On 05/27/2013 15:32, David Wolfskill wrote:

On Mon, May 27, 2013 at 05:43:13AM +0700, Erich Dollansky wrote:

...

piewm's twm.c declares main as:

int
main(int argc, char **argv, char **environ)
{


I use this concept since decades but with different names. Could it be
a problem of overlapping names?
...


It was pointed out to me that -- other than assigning "Environ =
environ" -- the code in piewm's twm.c didn't actually use the values of
environ or Environ.  [Thanks, Stefan!]

Elsewhere, there is a putenv() implementation for environments that
lack it, and the code uses getenv(), as well.

Doing a few more comparisons with twm.c from tvtwm and from twm itself;
I have a few more observations:

* tvtwm's twm.c is more recent than that of piewm:
   - * $XConsortium: twm.c,v 1.124 91/05/08 11:01:54 dave Exp $
   + * $XConsortium: twm.c,v 1.111 90/03/23 13:23:34 jim Exp $

* twm's twm.c has a copyright block dated 2005 from Hitachi, Ltd.

* Merely inserting the "#include " in piewm's twm.c appears
   to be a minimal effective change: Once that's done, the SIGSEGV goes
   away.

* Neither tvtwm's nor twm's twm.c has the "#include " (and
   neither gets a SIGSEGV).

* As Stefan pointed out, I was able to completely remove the references
   to both "environ" and "Environ" from piewm's twm.c; the result builds
   and runs without problem.

* tvtwm's twm.c has these environ and Environ variables (and, as above,
   lacks the "#include " and doesn't get the SIGSEGV).

* twm's twm.c lacks the environ and Environ variables (and main() is
   defined as a function that takes but 2 arguments).

I suspect that I'm failing to understand at least part of what's causing
the actual problem in piewm.


The environ variable had nothing to do with the segfault.
The third argument to main() is supported historically, but it's not 
standardized. Using the extern declaration is more portable. But 
apparently the main argument just works fine in FreeBSD.


Thomas explained why getenv() causes a segfault when  is not 
included. This is the actual problem that needs to be fixed.


twm.c indirectly includes  via twm.h. So that's why tvtwm and 
twm work fine.


IOW, just including  should be the right fix.

Hope all mysteries are solved now :)

--
Stefan
___
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: Is latest portsnap snapshot corrupted?

[HU Dong]

I met with the same problem, too.


On Mon, May 27, 2013 at 10:30 PM, Jakub Lach  wrote:

> Looks so:
>
> Fetching public key from portsnap1.FreeBSD.org... done.
> Fetching snapshot tag from portsnap1.FreeBSD.org... done.
> Fetching snapshot metadata... done.
> Fetching snapshot generated at Mon May 27 02:02:39 CEST 2013:
> ecc705a413e04a7c6eafdc110161ed9e1d6efd52224e7a100% of 8007 kB  702 kBps
> 00m00s
> Extracting snapshot...
> snap/8afe7697a48de0f3f78e4ca10ea11f519a2d215f22d0e9f294de70abcaeb42f7.gz:
> (Empty error message)
> tar: Error exit delayed from previous errors.
>
> Fetching public key from portsnap3.FreeBSD.org... done.
> Fetching snapshot tag from portsnap3.FreeBSD.org... done.
> Fetching snapshot metadata... done.
> Fetching snapshot generated at Mon May 27 02:02:39 CEST 2013:
> ecc705a413e04a7c6eafdc110161ed9e1d6efd52224e7a100% of 8007 kB  703 kBps
> 00m00s
> Extracting snapshot...
> snap/8afe7697a48de0f3f78e4ca10ea11f519a2d215f22d0e9f294de70abcaeb42f7.gz:
> (Empty error message)
> tar: Error exit delayed from previous errors.
>
>
>
>
> --
> View this message in context:
> http://freebsd.1045724.n5.nabble.com/Is-latest-portsnap-snapshot-corrupted-tp5815448.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"
>



-- 
B.R.
HU Dong
___
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: The vim port needs a refresh

[John Marino]

On 5/27/2013 16:34, RW wrote:


It would hurt people with a slow connections who would end-up having to
download most of the patches twice. I've a lot more sympathy with people
in that situation than with someone who doesn't cache and then
complains it's slow.


Trust me.
If you get the wrong mirror, it is horrifically slow.  Like 4 patches 
per minute slow.  You have no sympathy for somebody that has to download 
all 900+ patches from the beginning?


The "trick", of course, is to override MASTER_SITES in the environment, 
e.g. "make MASTER_SITES= fetch" and then force fetching from FreeBSD. 
Then it gets all the patches pretty quickly.  But most users wouldn't 
figure that out (and I'm sure you don't want it broadcast either).


The "slow" complaint is not trivial, it's very, very real.   Saying you 
haven't seen it doesn't make it less real, you probably just didn't sit 
there and watch it from patch#1.


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"

Maintainer update for mail/roundcube-userprefs (was ports/179007: )

[Stefan Bethke]

Hey,

sorry I screwed up the synopsis line; maybe somebody can correct that?


Thanks,
Stefan

Am 27.05.2013 um 10:50 schrieb freebsd-gnats-sub...@freebsd.org:

> Thank you very much for your problem report.
> It has the internal identification `ports/179007'.
> The individual assigned to look at your
> report is: freebsd-ports-bugs. 
> 
> You can access the state of your problem report at any time
> via this link:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=179007
> 
>> Category:   ports
>> Responsible:freebsd-ports-bugs
>> Synopsis:   
>> Arrival-Date:   Mon May 27 14:50:00 UTC 2013

-- 
Stefan BethkeFon +49 151 14070811

___
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: The vim port needs a refresh

[RW]

On Mon, 27 May 2013 09:36:20 -0400
Lowell Gilbert wrote:

> RW  writes:


> > I prefer it the way it is; those patch files are cached in the
> > distfiles directory, so only new patches need be downloaded. I can't
> > say I've ever noticed it being slow. If you roll them up into one
> > file the whole thing needs to be download every time a patch is
> > added. If you combine a tarball with individual newer patch, it's
> > no better than the current situation with caching.
> 
> There's plenty of middle ground. Re-rolling the tarball every time a
> new patch is added would definitely be worse than the current
> situation, but rolling lots of long-standing patches into a
> much-smaller number of collective downloads would be an improvement
> for some people without hurting anyone else.

It would hurt people with a slow connections who would end-up having to
download most of the patches twice. I've a lot more sympathy with people
in that situation than with someone who doesn't cache and then
complains it's slow.

It wouldn't matter if this were KDE4, but VIM is the kind of port
that's likely to be present on a minimalist install.
___
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"

Is latest portsnap snapshot corrupted?

[Jakub Lach]

Looks so:

Fetching public key from portsnap1.FreeBSD.org... done.
Fetching snapshot tag from portsnap1.FreeBSD.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Mon May 27 02:02:39 CEST 2013:
ecc705a413e04a7c6eafdc110161ed9e1d6efd52224e7a100% of 8007 kB  702 kBps
00m00s
Extracting snapshot...
snap/8afe7697a48de0f3f78e4ca10ea11f519a2d215f22d0e9f294de70abcaeb42f7.gz:
(Empty error message)
tar: Error exit delayed from previous errors.

Fetching public key from portsnap3.FreeBSD.org... done.
Fetching snapshot tag from portsnap3.FreeBSD.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Mon May 27 02:02:39 CEST 2013:
ecc705a413e04a7c6eafdc110161ed9e1d6efd52224e7a100% of 8007 kB  703 kBps
00m00s
Extracting snapshot...
snap/8afe7697a48de0f3f78e4ca10ea11f519a2d215f22d0e9f294de70abcaeb42f7.gz:
(Empty error message)
tar: Error exit delayed from previous errors.




--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Is-latest-portsnap-snapshot-corrupted-tp5815448.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: Proper way to access executable's "environment"?

[Thomas Mueller]

On Sun, 26 May 2013 11:06:29 -0700, David Wolfskill wrote:
> On Sun, May 26, 2013 at 07:55:03PM +0200, Stefan Ehmann wrote:
> > ...
> > > So I have a couple of questions related to the above:
> > > * Is the patch correct?...
> > 
> > Should be fine. See environ(7) or
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/environ.html:
> > 
> > "In addition, the following variable, which must be declared by the user 
> > if it is to be used directly: extern char **environ; "
> 
> Cool; thanks.
> 
> (Aside: I'd be happy to hear of plausible reasons the earlier approach
> does not appear to fail in i386.  I'm suspecting some sort of
> compatibilty shim -- which was jettisoned for amd64, probably quite
> intentionally.)

On AMD64 sizeof(void *)!=sizeof(int), thus warnings such as
   twm.c:250: warning: assignment makes pointer from integer without a cast
should trigger alarms.

 === GDB session
 Program received signal SIGSEGV, Segmentation fault.
 0x000801b60697 in strlen () from /lib/libc.so.7
 (gdb) bt
 #0  0x000801b60697 in strlen () from /lib/libc.so.7
 #1  0x0040b397 in main (argc=, argv=, environ=)
 at twm.c:254
 (gdb) frame 1
 #1  0x0040b397 in main (argc=, argv=, environ=)
 at twm.c:254
 254 HomeLen = strlen(Home);
 (gdb) l
 249 
 250 Home = getenv("HOME");
 251 if (Home == NULL)
 252 Home = "./";
 253 
 254 HomeLen = strlen(Home);
 (gdb) p Home
 $1 = 0xdf3a 
 =

Similarly,
   twm.c:306: warning: incompatible implicit declaration of built-in function 
'calloc'
including  provides a proper declaration for calloc().

-- 
Thomas Mueller
___
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: The vim port needs a refresh

[Lowell Gilbert]

RW  writes:

> On Fri, 24 May 2013 17:23:18 -0400
> Kenta Suzumoto wrote:
>
>
>> - It fetches almost 700 patches from what seems like a dial-up
>> connection in AUSTRALIA.
>> 
>> You might as well be downloading a 1080p movie from a rock in the
>> north pole, because that's about how fast it is. This can be very
>> easily avoided by putting all the patches into a single tarball and
>> hosting it anywhere decent. I've seen someone in ##freebsd on
>> freenode handing out a tarball with all the patches many times, and
>> everyone asks "why isn't this the default? why is some random guy
>> giving me distfiles?" etc. Seems like a no-brainer.
>
> I prefer it the way it is; those patch files are cached in the
> distfiles directory, so only new patches need be downloaded. I can't
> say I've ever noticed it being slow. If you roll them up into one file
> the whole thing needs to be download every time a patch is added. If you
> combine a tarball with individual newer patch, it's no better than the
> current situation with caching.

There's plenty of middle ground. Re-rolling the tarball every time a new
patch is added would definitely be worse than the current situation, but
rolling lots of long-standing patches into a much-smaller number of
collective downloads would be an improvement for some people without
hurting anyone else.

-- 
Rick Astley was not harmed in the making of this communication.
___
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: Proper way to access executable's "environment"?

[David Wolfskill]

On Mon, May 27, 2013 at 05:43:13AM +0700, Erich Dollansky wrote:
> ...
> > piewm's twm.c declares main as:
> > 
> > int
> > main(int argc, char **argv, char **environ)
> > {
> 
> I use this concept since decades but with different names. Could it be
> a problem of overlapping names?
> ...

It was pointed out to me that -- other than assigning "Environ =
environ" -- the code in piewm's twm.c didn't actually use the values of
environ or Environ.  [Thanks, Stefan!]

Elsewhere, there is a putenv() implementation for environments that
lack it, and the code uses getenv(), as well.

Doing a few more comparisons with twm.c from tvtwm and from twm itself;
I have a few more observations:

* tvtwm's twm.c is more recent than that of piewm:
  - * $XConsortium: twm.c,v 1.124 91/05/08 11:01:54 dave Exp $
  + * $XConsortium: twm.c,v 1.111 90/03/23 13:23:34 jim Exp $

* twm's twm.c has a copyright block dated 2005 from Hitachi, Ltd.

* Merely inserting the "#include " in piewm's twm.c appears
  to be a minimal effective change: Once that's done, the SIGSEGV goes
  away.

* Neither tvtwm's nor twm's twm.c has the "#include " (and
  neither gets a SIGSEGV).

* As Stefan pointed out, I was able to completely remove the references
  to both "environ" and "Environ" from piewm's twm.c; the result builds
  and runs without problem.

* tvtwm's twm.c has these environ and Environ variables (and, as above,
  lacks the "#include " and doesn't get the SIGSEGV).

* twm's twm.c lacks the environ and Environ variables (and main() is
  defined as a function that takes but 2 arguments).

I suspect that I'm failing to understand at least part of what's causing
the actual problem in piewm.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpL72zaFfMln.pgp
Description: PGP signature

[HEADSUP] default version of Ruby switched to 1.9

[Steve Wills]

Hi All,

Just a heads up, I've finally switched the default version of Ruby to 1.9.
There is a note in UPDATING that should help. Let us know if you have any
trouble.

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: The vim port needs a refresh

[RW]

On Fri, 24 May 2013 17:23:18 -0400
Kenta Suzumoto wrote:


> - It fetches almost 700 patches from what seems like a dial-up
> connection in AUSTRALIA.
> 
> You might as well be downloading a 1080p movie from a rock in the
> north pole, because that's about how fast it is. This can be very
> easily avoided by putting all the patches into a single tarball and
> hosting it anywhere decent. I've seen someone in ##freebsd on
> freenode handing out a tarball with all the patches many times, and
> everyone asks "why isn't this the default? why is some random guy
> giving me distfiles?" etc. Seems like a no-brainer.

I prefer it the way it is; those patch files are cached in the
distfiles directory, so only new patches need be downloaded. I can't
say I've ever noticed it being slow. If you roll them up into one file
the whole thing needs to be download every time a patch is added. If you
combine a tarball with individual newer patch, it's no better than the
current situation with caching.

___
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: [HEADS UP] xorg mega-update committed!

[Andrea Venturoli]

On 05/26/13 02:58, Niclas Zeising wrote:


With the new xserver (1.12) it is not possible currently, it seems.  I
haven't tested the old server.


Thanks for the work.
It's probably me, missing the original message or some old discussion, 
but I think many of us would welcome some more details; the UPDATING 
entry doesn't tell either...


Being a Radeon user, who currently runs 9.1 with "WITH_NEW_XORG=yes" in 
/etc/make.conf, how should I deal with this? I'd like to avoid an 
upgrade which makes me lose functionalities, so I think I should stay 
with the XServer/MESA version I currently have. Is it right?


So I should:
_ just freeze everything (possibly by HOLD_PKGS)?
_ remove WITH_NEW_XORG and go ahead with the rest?
_ ...?

 bye & Thanks
av.
___
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"

Speciale COSTA CROCIERE da 340 euro

[Eurotour Viaggi]

VIAGGI & TURISMO

Via Genova 20 - PESCARA

TEL.085-4224040 - cell. 328-7287173

www.eurotour.it 
- i...@eurotour.it 

 **Newsletter di offerte**

 Giovedí, 23 Maggio 2013
 *9* offerte totali

 Speciale COSTA CROCIERE da 340 euro

 Tipo Viaggio Crociere
 9 novitá

 Grecia Croazia e Montenegro da euro 340


 formula roulette parti subito da Copenhagen da euro 699


 formula rouette parti subito da Copenhagen da euro 599


 Mediterraneo giugno luglio agosto da euro 490


 Ref.
 Titolo
 Prima P.
 Ultima P.

 61279
 parti in crociera prenota adesso Nord Europa Fiordi norvegesi
partenza da Amsterdam volo da Milano


 26-06-2013
 25-07-2013

 61278
 formula roulette parti subito Crociera Grecia Croazia Montenegro da
Ancona


 02-06-2013
 30-06-2013

 61048
 formula roulette Crociere Nord Europa parti subito da Amsterdam Kiel
volo da Roma


 23-05-2013
 17-06-2013

 61047
 formula roulette Crociera Fiordi Norvegesiparti subito da Copenaghen
volo incluso


 25-05-2013
 01-06-2013

 60808
 Spagna Marocco e Portogallo da euro 490


 15-05-2013
 31-07-2013

 EUROTOUR VIAGGI PESCARA · VIA GENOVA 20 - cell.328 7287173 · 65122
· 

 tel. 0854224040 · fax. 0854224092 · email. felici...@eurotour.it

 ·

RICHIEDI INFORMAZIONI 
 oppure

PRENOTA ONLINE

VIAGGI & TURISMO

Via Genova 20 - PESCARA

TEL.085-4224040 - cell. 328-7287173

www.eurotour.it 
- i...@eurotour.it 



--
Per cancellarsi, cliccare qui >
http://www.eurotour.it/lists/?p=unsubscribe&uid=9342a8b4ee480b6c3cbf72194e2a2fba

Per aggiornare i propri dati o le preferenze, cliccare qui >
http://www.eurotour.it/lists/?p=preferences&uid=9342a8b4ee480b6c3cbf72194e2a2fba



--
Powered by PHPlist, www.phplist.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"

Current unassigned ports problem reports

[FreeBSD bugmaster]

(Note: an HTML version of this report is available at
http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .)

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

o ports/179001Opera flash plugin crashes
o ports/178998New port: devel/sfml2: a multimedia library
o ports/178992[patch] Mk/bsd.tex.mk - get rid of SITE_PERL
f ports/178987[patch] fix printing failure in print/cups-client
o ports/178982devel/opencl: Update and patch Makefile
o ports/178981[PATCH] www/node: update to 0.10.8
f ports/178979[patch] Clean up dns/inadyn
o ports/178946New port: net/owncloud-csync, a library for mirall, an
o ports/178945[NEW PORT] devel/commit-patch: Commit patches or parti
f ports/178942[patch] www/awstats
f ports/178924[patch] security/ftimes
o ports/178861[NEW PORT] dns/opendnssec14: Tool suite for maintainin
o ports/178860[MAINTAINER] dns/opendnssec: update to 1.3.14
f ports/178826Upgrade net/rabbitmq to 3.1.1
o ports/178808devel/wxGlade raises exception when generating XRC cod
f ports/178785mail/dracmail: adoption of optionsNG, and standardize 
o ports/178784[patch] enable PowerPC support in devel/gdb
o ports/178783[NEW PORT] misc/auto-multiple-choice: Multiple Choice 
f ports/178781[PATCH] net-mgmt/nfsen: Fix RUN_REPENDS syntax
f ports/178777[patch] Fix pkg-plist for games/boswars
o ports/178772Port update: net-mgmt/snmptt
f ports/178766science/hdf5: crt1.c:(.text+0x8a): undefined reference
o ports/178757devel/freeocl: Update
o ports/178726[PATCH] databases/mariadb55-server: multi-instances st
f ports/178717[update]: textproc/ctpp2 up to 2.8.3
o ports/178709[new port]: databases/hyperdex Searchable distributed 
o ports/178695[new port] www/eaccelerator-devel Development version 
f ports/178687audio/clementine-player fails to build
f ports/178652devel/m17n-lib: SHA256 Checksum mismatch for m17n-lib-
o ports/178617[new port]: databases/p5-MR-Tarantool Driver for an ef
f ports/178616ports-mgmt/porttools: port test does not handle pkgNG
o ports/178614[new port]: databases/php5-tarantool PECL PHP driver f
o ports/178557Ports with USE_GCC=any don't respect local CC and CXX 
f ports/178555[patch] Update cad/ngspice_rework to version 25
f ports/178539[PATCH] ports-mgmt/porttools: Improve commit sub-comma
f ports/178534sysutils/gkrelltop: master_site disappeared (universit
f ports/178529net/hornetq: uses home directory during build, not all
f ports/178525sysutils/less: correct the build option
f ports/178476dns/knot: Fix rc script for 1.2.0
f ports/178475[UPDATE] graphics/gmt: New version 4.5.9 available
o ports/178474[NEW PORT] games/linux-dwarf-fortress: Dwarf Fortress 
o ports/178464[NEW PORT] www/redaxo: The REDAXO content management s
o ports/178457[New port]audio/hydrogen-devel
o ports/178441[NEW PORT] databases/memkeys: A tool to show memcache 
f ports/178431graphics/geos hardcodes PHP 5.4 version
f ports/178386emulators/hercules version is more than 2 years old wh
o ports/178350net/pchar: Fix compile error by avoid sizeof(bool) tes
o ports/178333[new port] net/libnss-pgsql: allow user accounts to be
s ports/178281[new port] www/torbrowser: Request for a Native Torbro
f ports/178275build failed: net/rabbitmq: validity error : Could not
o ports/178269[PATCH] Remove checks for get_pidfile_from_conf functi
f ports/178251[patch] converters/unix2dos implicit declaration of fu
f ports/178246mail/fetchyahoo: is BROKEN
f ports/178245[patch] mail/getlive: 3.0 has been released
o ports/178240Update port science/meep to 1.2
f ports/178239Update port science/libctl to 3.2.1
f ports/178229devel/gnustep failed install - no objective c compiler
o ports/178206[updated port] graphics/rawtherapee to 4.0.10
o ports/178196/usr/ports/www/trac-mercurial broken
f ports/178187[PATCH] games/freedink-dfarc: Fix build and plist
o ports/178160emulators/sness9express: Fix build
o ports/178126[NEW PORT] databases/mysql56-server-cluster: MySQL Clu
o ports/178125[NEW PORT] databases/mysql56-client-cluster: Multithre
o ports/178078   

[QAT] r319190: 4x leftovers

[Ports-QAT]

Fix plist
-

  Build ID:  20130527093001-21085
  Job owner: b...@freebsd.org
  Buildtime: 33 minutes
  Enddate:   Mon, 27 May 2013 10:02:39 GMT

  Revision:  r319190
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=319190

-

Port:security/p5-Crypt-IDEA 1.08_2

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20130527093001-21085-143672/p5-Crypt-IDEA-1.08_2.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20130527093001-21085-143673/p5-Crypt-IDEA-1.08_2.log

  Buildgroup: 8.3-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20130527093001-21085-143674/p5-Crypt-IDEA-1.08_2.log

  Buildgroup: 8.3-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20130527093001-21085-143675/p5-Crypt-IDEA-1.08_2.log


--
Buildarchive URL: 
redports 
___
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/17892: commit references a PR

[dfilter service]

The following reply was made to PR ports/17892; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: ports/17892: commit references a PR
Date: Mon, 27 May 2013 08:59:26 + (UTC)

 Author: jadawin
 Date: Mon May 27 08:57:05 2013
 New Revision: 319179
 URL: http://svnweb.freebsd.org/changeset/ports/319179
 
 Log:
   - Remove useless depend on PERL_LEVEL < 5.12
   
   PR:  ports/17892
   Submitted by:az@
 
 Modified:
   head/audio/gnump3d/Makefile   (contents, props changed)
 
 Modified: head/audio/gnump3d/Makefile
 ==
 --- head/audio/gnump3d/MakefileMon May 27 08:51:52 2013
(r319178)
 +++ head/audio/gnump3d/MakefileMon May 27 08:57:05 2013
(r319179)
 @@ -1,9 +1,5 @@
 -# Ports collection makefile for:  gnump3d
 -# Date created:   May 27, 2002
 -# Whom:   ijliao
 -#
 +# Created by: ijliao
  # $FreeBSD$
 -#
  
  PORTNAME= gnump3d
  PORTVERSION=  3.0
 @@ -31,10 +27,6 @@ CONFDIR=${PREFIX}/etc/${PORTNAME}
  
  .include 
  
 -.if ${PERL_LEVEL} < 500806
 -RUN_DEPENDS+= p5-Encode>=0:${PORTSDIR}/converters/p5-Encode
 -.endif
 -
  post-patch:
  .for f in bin/gnump3d-index bin/gnump3d-top bin/gnump3d2 etc/gnump3d.conf \
man/gnump3d.conf.1
 ___
 svn-ports-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-ports-all
 To unsubscribe, send any mail to "svn-ports-all-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: x11-toolkits/mx build fail

[Florent Peterschmitt]

Le 26/05/2013 21:54, Lowell Gilbert a écrit :
> Beeblebrox  writes:
> 
>> Sorry, my bad - port is part of marcuscom-gnome3 apparently. I have had so
>> many port-build fails (consistently over a long period) that a neglected to
>> check the port origin.
>> Will report issue to marcuscom-gnome3
> 
> You have been issuing a *lot* of e-mails to the ports lists about
> failure that do not occur in any other environment than yours.
> 
> *Please* stop sending out such messages until you have fixed your own
> environment.

Just to support your comment.

Beeblebrox: you're reporting many bugs without trying any fix by
yourself, you don't care of others requests to start from a clean (from
zero) environment.

And over all, working on -CURRENT brings his lot of (possible) issues.
You shouldn't use -CURRENT if you're not able by yourself to fix
problems, at least trying to do something and stop losing your time and
time of others reading error messages that doesn't makes sens.

Again, it is *not* useful/usable to send error logs at every fail.

-- 
Florent Peterschmitt   |  /"\ ASCII Ribbon Campaign
flor...@peterschmitt.fr|  \ / - No HTML/RTF in E-mail
+33 (0)6 64 33 97 92   |   X  - No proprietary attachments
http://florent.peterschmitt.fr |  / \ - Respect for open standards



signature.asc
Description: OpenPGP digital signature