Easter Operating Hours

[Aurora Global Logistics]

*** IMPORTANT NOTE *** 
If you can see this text, you are not using HTML enabled email software. 


You can view this e-mail online at 
http://mailbank.com.au/Online/?B=108264&BK=8F336E76EE254

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

Fwd: ja-skk-tools-1.3.2,1 failed on i386 8

[Martin Wilke]

anyone :)?

Begin forwarded message:

> From: Portbuild user 
> Subject: ja-skk-tools-1.3.2,1 failed on i386 8
> Date: March 27, 2013 9:18:05 AM GMT+08:00
> To: m...@freebsd.org
> 
> You can also find this build log at
> 
>  
> http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20130327001001.pointyhat/ja-skk-tools-1.3.2,1.log
> 
> building ja-skk-tools-1.3.2,1 on gohan12.freebsd.org
> in directory /a/pkgbuild/8/20130327001001.pointyhat/chroot/66641
> building for: 8.3-RELEASE-p6 i386
> maintained by: po...@freebsd.org
> port directory: /usr/ports/japanese/skk-tools
> Makefile ident: $FreeBSD: head/japanese/skk-tools/Makefile 305610 2012-10-09 
> 22:12:13Z linimon $
> build started at Wed Mar 27 01:15:47 UTC 2013
> FETCH_DEPENDS=
> PATCH_DEPENDS=
> EXTRACT_DEPENDS=
> BUILD_DEPENDS=gettext-0.18.1.1_1.tbz glib-2.34.3.tbz libffi-3.0.13.tbz 
> libiconv-1.14_1.tbz pcre-8.32.tbz perl-5.14.2_3.tbz python27-2.7.3_6.tbz
> RUN_DEPENDS=gamin-0.1.10_5.tbz gettext-0.18.1.1_1.tbz 
> gio-fam-backend-2.34.3.tbz glib-2.34.3.tbz libffi-3.0.13.tbz 
> libiconv-1.14_1.tbz pcre-8.32.tbz perl-5.14.2_3.tbz python27-2.7.3_6.tbz
> PKG_DEPENDS=
> prefixes: LOCALBASE=usr/local
> add_pkg
> add_pkg
> 
> 
> ===>  License GPLv2 accepted by the user
> => skktools-1.3.2.tar.gz doesn't seem to exist in /tmp/distfiles/.
> => Attempting to fetch 
> ftp://ftp-master.freebsd.org/pub/FreeBSD/ports/distfiles//skktools-1.3.2.tar.gz
> skktools-1.3.2.tar.gz  267 kB   55 MBps
> ===> Fetching all distfiles required by ja-skk-tools-1.3.2,1 for building
> => SHA256 Checksum OK for skktools-1.3.2.tar.gz.
> 
> 
> add_pkg
> ===>  License GPLv2 accepted by the user
> ===> Fetching all distfiles required by ja-skk-tools-1.3.2,1 for building
> ===>  Extracting for ja-skk-tools-1.3.2,1
> ===>  License GPLv2 accepted by the user
> ===> Fetching all distfiles required by ja-skk-tools-1.3.2,1 for building
> => SHA256 Checksum OK for skktools-1.3.2.tar.gz.
> 
> 
> add_pkg
> ===>  Patching for ja-skk-tools-1.3.2,1
> 
> 
> add_pkg gettext-0.18.1.1_1.tbz glib-2.34.3.tbz libffi-3.0.13.tbz 
> libiconv-1.14_1.tbz pcre-8.32.tbz perl-5.14.2_3.tbz python27-2.7.3_6.tbz
> adding dependencies
> adding package gettext-0.18.1.1_1.tbz
> adding package glib-2.34.3.tbz
> Removing stale symlinks from /usr/bin...
>Skipping /usr/bin/perl
>Skipping /usr/bin/perl5
> Done.
> Creating various symlinks in /usr/bin...
>Symlinking /usr/local/bin/perl5.14.2 to /usr/bin/perl
>Symlinking /usr/local/bin/perl5.14.2 to /usr/bin/perl5
> Done.
> Cleaning up /etc/make.conf... Done.
> Spamming /etc/make.conf... Done.
> Cleaning up /etc/manpath.config... Done.
> Spamming /etc/manpath.config... Done.
> 
> 
> Note that some of the standard modules are provided as separate
> ports since they require extra dependencies:
> 
> bsddb   databases/py-bsddb
> gdbmdatabases/py-gdbm
> sqlite3   databases/py-sqlite3
> tkinter x11-toolkits/py-tkinter
> 
> Install them as needed.
> 
> 
> No schema files found: doing nothing.
> adding package libffi-3.0.13.tbz
> skipping libffi-3.0.13, already added
> adding package libiconv-1.14_1.tbz
> skipping libiconv-1.14_1, already added
> adding package pcre-8.32.tbz
> skipping pcre-8.32, already added
> adding package perl-5.14.2_3.tbz
> skipping perl-5.14.2_3, already added
> adding package python27-2.7.3_6.tbz
> skipping python27-2.7.3_6, already added
> ===>   ja-skk-tools-1.3.2,1 depends on shared library: glib-2.0 - found
> ===>   ja-skk-tools-1.3.2,1 depends on shared library: pcre - found
> ===>  Configuring for ja-skk-tools-1.3.2,1
> checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... ./install-sh -c -d
> checking for gawk... no
> checking for mawk... no
> checking for nawk... nawk
> checking whether make sets $(MAKE)... yes
> checking for style of include used by make... GNU
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... cpp
> checking for grep that handles long lines and -e... /usr/bin/

Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

[Jeremy Messenger]

On Tue, Mar 26, 2013 at 11:52 AM, Andrew W. Nosenko
 wrote:
> On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger
>  wrote:
>> On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko
>>  wrote:
>>> On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger
>>>  wrote:
 On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
  wrote:
> On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
>  wrote:
>> From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013
>>
>> On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer 
>>  wrote:
>> > On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
>> >> I've now run ia64 with the above change for over 2 weeks,
>> >> mostly rebuilding ports, etc.
>> >> I didn't see any issues with gcc47.
>> >> So, from my very limited testing,
>> >> gcc47 can be made default.
>> >
>> > Thanks for the feedback, Anton!  To really make that switch
>> > globally, we'll need more extensive testing, a full ports 
>> builds
>> > run, since there is a chance that some port you are not using 
>> may
>> > be broken, and I hope to get this done in the coming weeks.
>>
>> >From my expiriense, devel/glib20 cannot be compiled with gcc47.
>>
>> Isn't it built with the system default compiler:
>>
>> configure:3954: checking for C compiler version
>> configure:3963: cc --version >&5
>> cc (GCC) 4.2.1 20070831 patched [FreeBSD]
>>
>> I think we are only talking about updating lang/gcc to 4.7.
>
> By default -- yes, it is going to build with base gcc.  But topic and,
> therefore, my reaction was about overriding compiler to be lang/gcc*
> from ports and whether there are ports, which fail in that case.  At
> least, as I understand it.
>
> Now, why overriding the compiler for Glib seems important to me and
> why I tried to do that:
>
> Since
> commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58
> Author: Ryan Lortie 
> Date:   Tue Oct 18 16:21:50 2011 -0400
>
> gatomic: introduce G_ATOMIC_LOCK_FREE
>
> glib atomics implementation depends on gcc predefined macro
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base
> gcc-4.2 and on Clang (all version, at least at that time).
>
> As consequence, we have a mutex-based implementation of atomics.
> Building Glib using more modern GCC (e.g. gcc-4.7) would help, but
> gnome-libtool hack prevents us from that.

 Did you install all ports with GCC 4.7? If you install libtool with
 foo compiler then install other ports with bar compiler will be
 broken. You have to reinstall libtool with the bar compiler to make
 other ports with bar compiler works.
>>>
>>> No, I should not do that (of course if assume that port machinery
>>> doesn't interfere with configure results by discarding part of them).
>>
>> You need to try it. You can't assume anything.
>
> I don't assume.  I just know it.  Know from everyday usage.

# pkg_info -IX libtool
libtool-2.4.2   Generic shared library support script
# libtool --config | grep CC=
LTCC="cc"
CC="cc"

MIght be has to do with
http://svnweb.freebsd.org/ports/head/devel/libtool/files/patch-libltdl_config_ltmain.sh
?

>> It's well known that if
>> you change the CC/CXX then you have to reinstall libtool. Although, I
>> don't know if it's still true for present libtool, but it was problem
>> with libtool15 at last time when I checked. The libtool15 will storage
>> the CC, CXX and other stuff as default of what you used it on
>> libtool15. (ie: Run 'libtool --config')
>
> My knowledge based on 2.x series.  At the times of 1.x, the "base"
> compiler was modern enough for mitigate the need to redefine
> compilers.
>
>>
>> The gnome-libtool was copied from ${LOCALBASE}/bin/libtool (libtool
>> port) then patch the bug of shared library version in gnome-libtool.
>> It also changed the configure to look at gnome-libtool. Nothing more
>> and nothing less. You can look at Mk/bsd.gnome.mk by search for
>> ltverhack.
>
> I know it and knew at the time of writting.
>
> I don't know or don't understand why these "hacks" are needed, and, if
> they are really needed, then why they maintained separatelly instead
> of be pushed to the upstream and become part of libtool
> out-of-the-box.

The fix is really need. It is a bug in libtool that give wrong shared
library version that will get bump at the every API change. See here:
http://people.freebsd.org/~mezz/libtool.txt

> If, for some reason, libtool upstream cannot be conviced, or just at
> the transition stage, why patch the ${LOCALBASE}/bin/libtool?  Why
> don't patch the "local" libtool generated by package's configure and
> which contains all configure-gatchered variables properly filled (at
> least for those packages, which use fresh enough libtool version)?  

Re: Status of packages

[Bernhard Fröhlich]

Am 26.03.2013 19:20 schrieb "grarpamp" :
>
> > This may not have made it out in this list, the latest announcement is
> > here http://www.freebsd.org/news/2012-compromise.html#update20130323
>
> It's nice to see something like redports. It can be helpful to those using
> ports to diagnose their local builds against the output of a formal
sandbox
> service for the project. It would be cool if the logs, build hiers and
packages
> from such a buildbot were accessible. They'd obviously always be in flux
but
> still useful to see.

Redports is very bad for providing packages because of all the frequent
changes and the "chaotic nature" of such a system. Additionally the
security considerations made clear that redports should never provide any
binary data to users to minimize risk in case of a potential security
incident.
___
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: Could you remove the *-rtems-* ports?

[Joel]

On 3/26/2013 1:16 PM, Wojciech Puchar wrote:

actually i used mips-rtems ports to just compile gcc mips cross compiler
and with ease - to use it without any standard libs to write software for
microchip PIC32 microcontroller.

What version of RTEMS?

You are lucky because the MIPS architecture is very stable. The tool 
versions listed

that do not match any set of patches/versions from the RTEMS Project.

Plus they do not follow the proper naming for any RTEMS version in this
century.

What can we do to help either make these ports correct per RTEMS or
help any users transition to rtems-source-builder?

I don't want to leave anyone in a pinch. That is NOT the RTEMS way. :)

cc'ing Chris Johns who is the rtems-source-builder person.

--joel
RTEMS

On Sun, 24 Mar 2013, Rempel, Cynthia wrote:


Hi FreeBSD Ports Maintainer,

Could you remove the *-rtems-* ports? They fail to build (the user has to 
change to bash to build them), and once built they don't build RTEMS. There are 
additional issues stated below.

Thanks!
Cynthia Rempel

From: bugzilla-dae...@rtems.org [bugzilla-dae...@rtems.org]
Sent: Sunday, March 24, 2013 7:40 AM
To: cynt6...@vandals.uidaho.edu
Subject: [Bug 2099] sparc-gcc: error: cannot compute suffix of object files

https://www.rtems.org/bugzilla/show_bug.cgi?id=2099

--- Comment #3 from Joel Sherrill  2013-03-24 
09:40:35 CDT ---
We really want the RTEMS Ports collections deleted. They do not include the
RTEMS version in the target name and do not include recent patches. They were
not submitted by the project and have no maintainer.

You just tripped into a pit we wanted to fill with dirt. :)

--
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.


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





--
Joel Sherrill, Ph.D.  Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS   Huntsville AL 35805
Support Available (256) 722-9985

___
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 should provide knobs disabling unwanted network services

[Baptiste Daroussin]

On Tue, Mar 26, 2013 at 07:15:24PM +0100, Wojciech Puchar wrote:
> On Sun, 24 Mar 2013, Beeblebrox wrote:
> 
> > Many ports, (specially the KDE-related ones) provide no option to disable
> > network-related options. Usually these are things like samba-client,
> > Avahi-mDNS* (with variants), and the like. Gnome usually provides a choice
> > to disable gnome-vfs.
> >
> > I really don't understand why such ports enable those services by default,
> me too. I don't think KDE is for anything serious but still it should just 
> be disabled by default and enabled at user choice.
> 
> No special knobs for disabling should exist, but for enabling.

It is not because a program is linked against a library that it uses it for
real. I don't know much kde, but I'm pretty sure I have a checkbox somewhere
saying "activate mdns" or "deactivate mdns" you can have it installed on your
system but not actually starting it.

I general I do think ports/packages should offer as default what may fits the
general needs easily. in this case if you are free to use/not use it via a
checkbox, then the default right now is sane because another user with different
needs will just have to click to activate it without having to build his own
packages.

regards,
Bapt


pgpB5y0UUnFLk.pgp
Description: PGP signature

Re: Ports should provide knobs disabling unwanted network services

[Wojciech Puchar]

On Sun, 24 Mar 2013, Beeblebrox wrote:


Many ports, (specially the KDE-related ones) provide no option to disable
network-related options. Usually these are things like samba-client,
Avahi-mDNS* (with variants), and the like. Gnome usually provides a choice
to disable gnome-vfs.

I really don't understand why such ports enable those services by default,
me too. I don't think KDE is for anything serious but still it should just 
be disabled by default and enabled at user choice.


No special knobs for disabling should exist, but for enabling.
___
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: Status of packages

[grarpamp]

> This may not have made it out in this list, the latest announcement is
> here http://www.freebsd.org/news/2012-compromise.html#update20130323

It's nice to see something like redports. It can be helpful to those using
ports to diagnose their local builds against the output of a formal sandbox
service for the project. It would be cool if the logs, build hiers and packages
from such a buildbot were accessible. They'd obviously always be in flux but
still useful to see.
___
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: Could you remove the *-rtems-* ports?

[Wojciech Puchar]

actually i used mips-rtems ports to just compile gcc mips cross compiler 
and with ease - to use it without any standard libs to write software for 
microchip PIC32 microcontroller.


On Sun, 24 Mar 2013, Rempel, Cynthia wrote:


Hi FreeBSD Ports Maintainer,

Could you remove the *-rtems-* ports? They fail to build (the user has to 
change to bash to build them), and once built they don't build RTEMS. There are 
additional issues stated below.

Thanks!
Cynthia Rempel

From: bugzilla-dae...@rtems.org [bugzilla-dae...@rtems.org]
Sent: Sunday, March 24, 2013 7:40 AM
To: cynt6...@vandals.uidaho.edu
Subject: [Bug 2099] sparc-gcc: error: cannot compute suffix of object files

https://www.rtems.org/bugzilla/show_bug.cgi?id=2099

--- Comment #3 from Joel Sherrill  2013-03-24 
09:40:35 CDT ---
We really want the RTEMS Ports collections deleted. They do not include the
RTEMS version in the target name and do not include recent patches. They were
not submitted by the project and have no maintainer.

You just tripped into a pit we wanted to fill with dirt. :)

--
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.


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



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

[QAT] r314233: 4x leftovers

[Ports-QAT]

- Convert to PEAR_AUTOINSTALL
-

  Build ID:  20130315023600-62743
  Job owner: m...@freebsd.org
  Buildtime: 12 days
  Enddate:   Tue, 26 Mar 2013 17:26:32 GMT

  Revision:  r314233
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=314233

-

Port:databases/pear-DB_Table 1.5.6,1

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20130315023600-62743-119052/pear-DB_Table-1.5.6,1.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20130315023600-62743-119053/pear-DB_Table-1.5.6,1.log

  Buildgroup: 8.3-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20130315023600-62743-119054/pear-DB_Table-1.5.6,1.log

  Buildgroup: 8.3-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20130315023600-62743-119055/pear-DB_Table-1.5.6,1.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: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

[Andrew W. Nosenko]

On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger
 wrote:
> On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko
>  wrote:
>> On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger
>>  wrote:
>>> On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
>>>  wrote:
 On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
  wrote:
> From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013
>
> On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer 
>  wrote:
> > On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
> >> I've now run ia64 with the above change for over 2 weeks,
> >> mostly rebuilding ports, etc.
> >> I didn't see any issues with gcc47.
> >> So, from my very limited testing,
> >> gcc47 can be made default.
> >
> > Thanks for the feedback, Anton!  To really make that switch
> > globally, we'll need more extensive testing, a full ports builds
> > run, since there is a chance that some port you are not using 
> may
> > be broken, and I hope to get this done in the coming weeks.
>
> >From my expiriense, devel/glib20 cannot be compiled with gcc47.
>
> Isn't it built with the system default compiler:
>
> configure:3954: checking for C compiler version
> configure:3963: cc --version >&5
> cc (GCC) 4.2.1 20070831 patched [FreeBSD]
>
> I think we are only talking about updating lang/gcc to 4.7.

 By default -- yes, it is going to build with base gcc.  But topic and,
 therefore, my reaction was about overriding compiler to be lang/gcc*
 from ports and whether there are ports, which fail in that case.  At
 least, as I understand it.

 Now, why overriding the compiler for Glib seems important to me and
 why I tried to do that:

 Since
 commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58
 Author: Ryan Lortie 
 Date:   Tue Oct 18 16:21:50 2011 -0400

 gatomic: introduce G_ATOMIC_LOCK_FREE

 glib atomics implementation depends on gcc predefined macro
 __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base
 gcc-4.2 and on Clang (all version, at least at that time).

 As consequence, we have a mutex-based implementation of atomics.
 Building Glib using more modern GCC (e.g. gcc-4.7) would help, but
 gnome-libtool hack prevents us from that.
>>>
>>> Did you install all ports with GCC 4.7? If you install libtool with
>>> foo compiler then install other ports with bar compiler will be
>>> broken. You have to reinstall libtool with the bar compiler to make
>>> other ports with bar compiler works.
>>
>> No, I should not do that (of course if assume that port machinery
>> doesn't interfere with configure results by discarding part of them).
>
> You need to try it. You can't assume anything.

I don't assume.  I just know it.  Know from everyday usage.

> It's well known that if
> you change the CC/CXX then you have to reinstall libtool. Although, I
> don't know if it's still true for present libtool, but it was problem
> with libtool15 at last time when I checked. The libtool15 will storage
> the CC, CXX and other stuff as default of what you used it on
> libtool15. (ie: Run 'libtool --config')

My knowledge based on 2.x series.  At the times of 1.x, the "base"
compiler was modern enough for mitigate the need to redefine
compilers.

>
> The gnome-libtool was copied from ${LOCALBASE}/bin/libtool (libtool
> port) then patch the bug of shared library version in gnome-libtool.
> It also changed the configure to look at gnome-libtool. Nothing more
> and nothing less. You can look at Mk/bsd.gnome.mk by search for
> ltverhack.

I know it and knew at the time of writting.

I don't know or don't understand why these "hacks" are needed, and, if
they are really needed, then why they maintained separatelly instead
of be pushed to the upstream and become part of libtool
out-of-the-box.

If, for some reason, libtool upstream cannot be conviced, or just at
the transition stage, why patch the ${LOCALBASE}/bin/libtool?  Why
don't patch the "local" libtool generated by package's configure and
which contains all configure-gatchered variables properly filled (at
least for those packages, which use fresh enough libtool version)?  Or
why don't patch the devel/libtool (if need) for install the patched
ltmain.sh (if need) and then force package to re-grab
autotools/libtool related things and regenerate the configure script?

>
>> libtool script is a _generated_ thing when used with autoconf.
>> 'configure' does some checks (including how to execute linker
>> depending on used languages) and generates the "current" libtool sript
>> using these results.  This generated script has nothing with
>> /usr/local/bin/libtool.  Moreover, the system-wide libtool has no
>> business there, not used and may be completely absent until you want
>> reg

Re:qjail fork attribution was Handbook Jail Chapter rewrite available for critique

[Fbsd8]

Dirk Engling wrote:

Dear JoeB,

since you just threatened me via private email to expose my evil plans
of preventing your ubercool project from taking FreeBSD by storm, I
would like to comment on your views and your project publicly

On 22.03.13 23:12, Fbsd8 wrote:


On the subject of qjail being a fork of ezjail, of course it is.


So, you've decided to run along with an existing code base to fork a
project. Congratulations.

You surely must have had reasons, like including features that the
original author told you never to implement. Like you found the project
abandoned and no one replied to your requests.

Well, except you did not. I found out about your fork by chance, after
someone directed my attention to your constant bragging and nagging.
Why, after all, would you ever feel the need to talk to me directly
about the fork? After all, what common interests might we possibly share?

So I think the only reason to rip off ezjails code was to boost your ego
with some impressive looking column of shell script you obviously had
trouble understanding, which comes as no surprise as you _still_ seem to
have trouble grasping even the basic concepts of shell scripting:

http://lists.freebsd.org/pipermail/freebsd-questions/2013-January/248558.html

http://lists.freebsd.org/pipermail/freebsd-questions/2013-January/247723.html

Reading this I find it very disturbing that you try to lure users into
using your bumbling hack that pokes in one of the core security features
of FreeBSD. To put it more plainly: What you do is dangerous. Stop doing
it. You're putting your users at risk.


British member concluded that the author of ezjail must be British based
solely on the spelling of the flavour directory. He also convinced us
that his Beerware license was British humor, a joke, and should not be
taken serous. In our review of other jail ports we did not see this


Then tell your "British member" to read up on some contemporary
literature, maybe Wikipedia

  http://en.wikipedia.org/wiki/Beerware

so he has a chance to understand what connects Beerware and FreeBSD. Do
not use your confused team member as pretext to violate the terms of
license you obviously found by yourself and chose to ignore.


file. It was inserted in the front like they have. We though that was
how you make software opensource which was the intention. There are no
formal copyright documents; it's just a extrapolation from the FreeBSD
comments.


Besides completely failing to see the point what the difference between
open source and public domain is, you do not have the slightest idea,
what a community of people sharing their code as open source is about.

The simple fact that you resort to Windows and IIS to serve your web
site should have warned me, that you do not actually have any connection
to the scene besides your gimme-gimme-gimme attitude.

To make my point clear: Open source software is about attribution. For
multiple reasons, most important to me: getting to socialize. Beerware
is not so much about getting the actual beer, but to have a chance to
sit together and talk with people sharing common interests. Now you rob
me of the chance to ever hear from people using my code disguised as yours.

Another reason, of course, is the pride we take in spending nearly ten
years on ezjail and we definitely do not like some script kiddie running
around adorn himself with plumes plucked from our asses.


section is not appropriate to include qjail under Freebsd opensource
type of license, then we can change the comments to say "totally free to
do as you wish as opensource" and leave it at that. If something else is
needed, please inform what that is by private email. To continue this
this subject in public is not appropriate. Please respect our wish in
this matter.


No, I will not respect your wishes, as you chose to ignore mine. You are
not totally free to do as you wish with the ezjail authors' code and you
can not grant that rights to someone else.

Regarding your fork: I can not and I will not prevent forks from
happening. So I wish you good luck with it. Maybe you learn some shell
on the way.

The qjail port has been marked RESTRICTED by the ports managers and I
will withdraw my concerns once you find a proper way to indicate
original authorship in a humble way.

Regards,

   erdgeist




Dear Dirk Engling

I feel sorry for you. I man with such talent and respect has fallen to 
such a level of self induced public humiliation. This outburst only 
confirms my suspicion that your suffering from dementia caused by 
advancing age. I tried to give you a way to save face as I purposed in 
my private email to you. But now that you have moved things into the 
public light you force me to publicly point out just how confused your 
thinking is.


The FACT is the ezjail-3.2.3 port currently in the port system contains 
NO verbiage concerning any type of license. Even the ezjail Makefile 
doesn't invoke the BSD license.


Even after I informed you of this f

Re: pam_ssh_agent_auth: ENOENT

[Martin Wilke]

Hey

Please test the new patch. @ Stefan thx for the PR.

http://people.freebsd.org/~miwi/psaa.diff

- Martin

On Feb 27, 2013, at 4:04 PM, Stefan Bethke  wrote:

> 
> Am 27.02.2013 um 09:01 schrieb Dimitry Andric :
> 
>> On 2013-02-27 00:39, Stefan Bethke wrote:
>> ...
>>> openbsd-compat/vis.h is #ifdef'd HAVE_STRNVIS, so we check configure.  
>>> configure.log thinks we have a suitable strnvis:
>>> 
>>> configure:16566: checking for strnvis
>>> configure:16622: cc -o conftest -O2 -pipe -fno-strict-aliasing -fPIC -Wall 
>>> -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign 
>>> -fstack-protector-all   -fstack-protector-all conftest.c  -lutil -lpam >&5
>>> configure:16629: $? = 0
>>> configure:16651: result: yes
>>> 
>>> 
>>> Do we?
>> 
>> We have strnvis(), but it is not suitable.  We got strnvis() from
>> NetBSD, and its arguments are in a different order from OpenBSD's
>> version.  See the archive for earlier discussions (and crash reports :)
>> about this.
>> 
>> I recommend adding the line:
>> 
>> CONFIGURE_ENV=   ac_cv_func_strnvis=no
>> 
>> to the port Makefile, just as with security/openssh-portable.
> 
> Ah, neat, I didn't know you could do that in a Makefile.  I've just submitted 
> ports/176469 with a patch to configure, but this much nicer.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=176469
> 
> 
> Stefan
> 
> -- 
> 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"
> 

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

FreeBSD Port: ap22-mod_security-2.6.6

[Manfred Wischin]

Hi Marcelo Araujo,

is there any chance to get a current modsecurity 2.7 version into the FreeBSD 
ports?

Thank you for your time and effort.

Dear
Manfred Wischin

--
Mag. Manfred Wischin
AGENTUR ZEITPUNKT Mediendesign & -produktion Gmbh
Sustainable Online Solutions

1070 Wien, Neubaugasse 57/3/22
T: +43.1.8908660-11
F: +43.1.8908660-15
M: +43.699.16688661
E: manfred.wisc...@zeitpunkt.com
I: www.zeitpunkt.com

consulting | design | development | services

___
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 it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

[Jeremy Messenger]

On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko
 wrote:
> On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger
>  wrote:
>> On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
>>  wrote:
>>> On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
>>>  wrote:
 From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013

 On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer 
  wrote:
 > On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
 >> I've now run ia64 with the above change for over 2 weeks,
 >> mostly rebuilding ports, etc.
 >> I didn't see any issues with gcc47.
 >> So, from my very limited testing,
 >> gcc47 can be made default.
 >
 > Thanks for the feedback, Anton!  To really make that switch
 > globally, we'll need more extensive testing, a full ports builds
 > run, since there is a chance that some port you are not using may
 > be broken, and I hope to get this done in the coming weeks.

 >From my expiriense, devel/glib20 cannot be compiled with gcc47.

 Isn't it built with the system default compiler:

 configure:3954: checking for C compiler version
 configure:3963: cc --version >&5
 cc (GCC) 4.2.1 20070831 patched [FreeBSD]

 I think we are only talking about updating lang/gcc to 4.7.
>>>
>>> By default -- yes, it is going to build with base gcc.  But topic and,
>>> therefore, my reaction was about overriding compiler to be lang/gcc*
>>> from ports and whether there are ports, which fail in that case.  At
>>> least, as I understand it.
>>>
>>> Now, why overriding the compiler for Glib seems important to me and
>>> why I tried to do that:
>>>
>>> Since
>>> commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58
>>> Author: Ryan Lortie 
>>> Date:   Tue Oct 18 16:21:50 2011 -0400
>>>
>>> gatomic: introduce G_ATOMIC_LOCK_FREE
>>>
>>> glib atomics implementation depends on gcc predefined macro
>>> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base
>>> gcc-4.2 and on Clang (all version, at least at that time).
>>>
>>> As consequence, we have a mutex-based implementation of atomics.
>>> Building Glib using more modern GCC (e.g. gcc-4.7) would help, but
>>> gnome-libtool hack prevents us from that.
>>
>> Did you install all ports with GCC 4.7? If you install libtool with
>> foo compiler then install other ports with bar compiler will be
>> broken. You have to reinstall libtool with the bar compiler to make
>> other ports with bar compiler works.
>
> No, I should not do that (of course if assume that port machinery
> doesn't interfere with configure results by discarding part of them).

You need to try it. You can't assume anything. It's well known that if
you change the CC/CXX then you have to reinstall libtool. Although, I
don't know if it's still true for present libtool, but it was problem
with libtool15 at last time when I checked. The libtool15 will storage
the CC, CXX and other stuff as default of what you used it on
libtool15. (ie: Run 'libtool --config')

The gnome-libtool was copied from ${LOCALBASE}/bin/libtool (libtool
port) then patch the bug of shared library version in gnome-libtool.
It also changed the configure to look at gnome-libtool. Nothing more
and nothing less. You can look at Mk/bsd.gnome.mk by search for
ltverhack.

> libtool script is a _generated_ thing when used with autoconf.
> 'configure' does some checks (including how to execute linker
> depending on used languages) and generates the "current" libtool sript
> using these results.  This generated script has nothing with
> /usr/local/bin/libtool.  Moreover, the system-wide libtool has no
> business there, not used and may be completely absent until you want
> regenerate and replace all package-supplied tools by your copy by
> something like 'autoreconf -f'.
>
> As you can see, under proper workflow, there no dependency, which
> version of compiler was installed or used on the time of
> /usr/local/bin/libtool generation.  All knowledge about currently used
> language, compiler, linker abelities and so on are gatchered by
> configure and written into "local" package-specific libtool script (in
> contrast to the "global" /usr/local/bin/libtool).
>
> The only one problem that ports machinery decides to trow out these
> results and use own copy, which know nothing about actual package
> preferences, needs, nor used language.
>
>>
>>> See also:
>>> Thread "atomic ops broken on mac/xcode"
>>> https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00089.html
>>>
>>> Gnome bugzilla #682818: atomic ops broken on mac/xcode
>>> https://bugzilla.gnome.org/show_bug.cgi?id=682818
>>>
>>> LLVM/Clang bugzilla #11174: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_
>>> http://llvm.org/bugs/show_bug.cgi?id=11174
>>>
>
>
> --
> Andrew W. Nosenko 



-- 
mezz.free...@gmail.com - m...@freebsd.org
FreeB

Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

[Andrew W. Nosenko]

On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger
 wrote:
> On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
>  wrote:
>> On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
>>  wrote:
>>> From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013
>>>
>>> On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer 
>>>  wrote:
>>> > On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
>>> >> I've now run ia64 with the above change for over 2 weeks,
>>> >> mostly rebuilding ports, etc.
>>> >> I didn't see any issues with gcc47.
>>> >> So, from my very limited testing,
>>> >> gcc47 can be made default.
>>> >
>>> > Thanks for the feedback, Anton!  To really make that switch
>>> > globally, we'll need more extensive testing, a full ports builds
>>> > run, since there is a chance that some port you are not using may
>>> > be broken, and I hope to get this done in the coming weeks.
>>>
>>> >From my expiriense, devel/glib20 cannot be compiled with gcc47.
>>>
>>> Isn't it built with the system default compiler:
>>>
>>> configure:3954: checking for C compiler version
>>> configure:3963: cc --version >&5
>>> cc (GCC) 4.2.1 20070831 patched [FreeBSD]
>>>
>>> I think we are only talking about updating lang/gcc to 4.7.
>>
>> By default -- yes, it is going to build with base gcc.  But topic and,
>> therefore, my reaction was about overriding compiler to be lang/gcc*
>> from ports and whether there are ports, which fail in that case.  At
>> least, as I understand it.
>>
>> Now, why overriding the compiler for Glib seems important to me and
>> why I tried to do that:
>>
>> Since
>> commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58
>> Author: Ryan Lortie 
>> Date:   Tue Oct 18 16:21:50 2011 -0400
>>
>> gatomic: introduce G_ATOMIC_LOCK_FREE
>>
>> glib atomics implementation depends on gcc predefined macro
>> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base
>> gcc-4.2 and on Clang (all version, at least at that time).
>>
>> As consequence, we have a mutex-based implementation of atomics.
>> Building Glib using more modern GCC (e.g. gcc-4.7) would help, but
>> gnome-libtool hack prevents us from that.
>
> Did you install all ports with GCC 4.7? If you install libtool with
> foo compiler then install other ports with bar compiler will be
> broken. You have to reinstall libtool with the bar compiler to make
> other ports with bar compiler works.

No, I should not do that (of course if assume that port machinery
doesn't interfere with configure results by discarding part of them).

libtool script is a _generated_ thing when used with autoconf.
'configure' does some checks (including how to execute linker
depending on used languages) and generates the "current" libtool sript
using these results.  This generated script has nothing with
/usr/local/bin/libtool.  Moreover, the system-wide libtool has no
business there, not used and may be completely absent until you want
regenerate and replace all package-supplied tools by your copy by
something like 'autoreconf -f'.

As you can see, under proper workflow, there no dependency, which
version of compiler was installed or used on the time of
/usr/local/bin/libtool generation.  All knowledge about currently used
language, compiler, linker abelities and so on are gatchered by
configure and written into "local" package-specific libtool script (in
contrast to the "global" /usr/local/bin/libtool).

The only one problem that ports machinery decides to trow out these
results and use own copy, which know nothing about actual package
preferences, needs, nor used language.

>
>> See also:
>> Thread "atomic ops broken on mac/xcode"
>> https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00089.html
>>
>> Gnome bugzilla #682818: atomic ops broken on mac/xcode
>> https://bugzilla.gnome.org/show_bug.cgi?id=682818
>>
>> LLVM/Clang bugzilla #11174: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_
>> http://llvm.org/bugs/show_bug.cgi?id=11174
>>


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

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

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

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

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


Port| Current version | New version
+-+
devel/arm-rtems-binutils| 2.21| 2.23.2
+-+
devel/cross-binutils| 2.21| 2.23.2
+-+
devel/i386-rtems-binutils   | 2.21| 2.23.2
+-+
devel/m68k-rtems-binutils   | 2.21| 2.23.2
+-+
devel/mingw64-binutils  | 2.21| 2.23.2
+-+
devel/mips-rtems-binutils   | 2.21| 2.23.2
+-+
devel/powerpc-rtems-binutils| 2.21| 2.23.2
+-+
devel/sh-rtems-binutils | 2.21| 2.23.2
+-+
devel/sparc-rtems-binutils  | 2.21| 2.23.2
+-+


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

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

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

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

Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

[Jeremy Messenger]

On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
 wrote:
> On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
>  wrote:
>> From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013
>>
>> On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer  
>> wrote:
>> > On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
>> >> I've now run ia64 with the above change for over 2 weeks,
>> >> mostly rebuilding ports, etc.
>> >> I didn't see any issues with gcc47.
>> >> So, from my very limited testing,
>> >> gcc47 can be made default.
>> >
>> > Thanks for the feedback, Anton!  To really make that switch
>> > globally, we'll need more extensive testing, a full ports builds
>> > run, since there is a chance that some port you are not using may
>> > be broken, and I hope to get this done in the coming weeks.
>>
>> >From my expiriense, devel/glib20 cannot be compiled with gcc47.
>>
>> Isn't it built with the system default compiler:
>>
>> configure:3954: checking for C compiler version
>> configure:3963: cc --version >&5
>> cc (GCC) 4.2.1 20070831 patched [FreeBSD]
>>
>> I think we are only talking about updating lang/gcc to 4.7.
>
> By default -- yes, it is going to build with base gcc.  But topic and,
> therefore, my reaction was about overriding compiler to be lang/gcc*
> from ports and whether there are ports, which fail in that case.  At
> least, as I understand it.
>
> Now, why overriding the compiler for Glib seems important to me and
> why I tried to do that:
>
> Since
> commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58
> Author: Ryan Lortie 
> Date:   Tue Oct 18 16:21:50 2011 -0400
>
> gatomic: introduce G_ATOMIC_LOCK_FREE
>
> glib atomics implementation depends on gcc predefined macro
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base
> gcc-4.2 and on Clang (all version, at least at that time).
>
> As consequence, we have a mutex-based implementation of atomics.
> Building Glib using more modern GCC (e.g. gcc-4.7) would help, but
> gnome-libtool hack prevents us from that.

Did you install all ports with GCC 4.7? If you install libtool with
foo compiler then install other ports with bar compiler will be
broken. You have to reinstall libtool with the bar compiler to make
other ports with bar compiler works.

> See also:
> Thread "atomic ops broken on mac/xcode"
> https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00089.html
>
> Gnome bugzilla #682818: atomic ops broken on mac/xcode
> https://bugzilla.gnome.org/show_bug.cgi?id=682818
>
> LLVM/Clang bugzilla #11174: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_
> http://llvm.org/bugs/show_bug.cgi?id=11174
>
> --
> Andrew W. Nosenko 
> ___
> 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"



-- 
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: Ports should provide knobs disabling unwanted network services

[Florent Peterschmitt]

Le 26/03/2013 10:00, Peter Pentchev a écrit :
> On Tue, Mar 26, 2013 at 09:13:38AM +0100, Florent Peterschmitt wrote:
>> Le 25/03/2013 04:40, Scot Hetzel a écrit :
>>> On Sun, Mar 24, 2013 at 10:33 PM, Florent Peterschmitt
>>>  wrote:
 Le 24/03/2013 17:34, Scot Hetzel a écrit :
> On Sun, Mar 24, 2013 at 7:00 AM, Beeblebrox  wrote:
>> I would be very happy to submit a patch, if I actually knew how to write
>> one...
>>
>
> It is quite simple to create the patch.
>
> If you have a working copy checked out with svn, then it would be:
>
> cd /usr/ports/[category]/[port]
> - Make the necessary changes to the port
> - After testing the port make sure to do a 'make clean'
> svn diff > port.diff
>
> Otherwise make a copy of the port:
>
> cd /usr/ports/[catagory]
> cp port port-orig
> cd port
> - Make the necessary changes to port
> - After testing port make sure to do a 'make clean'
> cd ..
> diff -ruN port-orig port > port.diff
>
> Then just submit the port.diff in a PR using either send-pr or
> http://www.freebsd.org/send-pr.html.
>

 Is there a way to manually make a patch that will say :

 --- MyFile
 +++ MyFile

 Even if these files are in two distinct trees ?

>>> There is always a way to do that:
>>>
>>> diff -u /path/to/original/port/MyFile /path/to/modified/port/MyFile >
>>> /place/to/save/patch/port.diff
>>>
>>> or if you modifed several files:
>>>
>>> diff -ruN /path/to/original/port /path/to/modified/port >
>>> /place/to/save/patch/port.diff
>>>
>> Hum yes but what I mean is that we'll have, for example:
>>
>> --- /home/florent-gentoo/patch/old/one   2013-03-24 14:04:20.757200724 
>> +0100
>> +++ /home/florent-gentoo/patch/new/one   2013-03-24 14:04:08.541201548 
>> +0100
>> […]
>>
>> And what I want is:
>>
>> --- /home/florent-gentoo/patch/old/one   2013-03-24 14:04:20.757200724 
>> +0100
>> +++ /home/florent-gentoo/patch/old/one   2013-03-24 14:04:08.541201548 
>> +0100
>> […]
>>
>> SCM make patches like the second one and I'm no sure it is possible to
>> do without modifying by hand the patch generated.
> 
> Well, one way to do it would be to actually *use* an SCM :)  My
> preferred way would be a Git copy of the Subversion repository - then
> you do your changes in your local Git tree and periodically pull down
> the changes from the FreeBSD Subversion repo and merge them into yours.
> 
> But really, is there actually a reason why you don't want two separate
> directories?  To be honest, before the advent of Subversion and Git
> everyone did their patches that way (well, there *were* local CVS
> repositories and checkouts from there, but most of the patches were
> diffs between two side-by-side directories) - and I don't think anyone
> ever complained.  Are there any problems you are seeing with two paths
> in the diff headers, or is it just aesthetic?
> 
> G'luck,
> Peter
> 

Hum. I'm definitively misunderstanding patching process and I just
discovered that even if the header is not with the two same subdirs, it
works anyway.

For the moment I've no time for porting but I'll study it as soon as
possible :)

Thanks ;)

-- 
Florent Peterschmitt
+33 (0)6 64 33 97 92
flor...@peterschmitt.fr



signature.asc
Description: OpenPGP digital signature

Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

[Andrew W. Nosenko]

On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
 wrote:
> From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013
>
> On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer  
> wrote:
> > On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
> >> I've now run ia64 with the above change for over 2 weeks,
> >> mostly rebuilding ports, etc.
> >> I didn't see any issues with gcc47.
> >> So, from my very limited testing,
> >> gcc47 can be made default.
> >
> > Thanks for the feedback, Anton!  To really make that switch
> > globally, we'll need more extensive testing, a full ports builds
> > run, since there is a chance that some port you are not using may
> > be broken, and I hope to get this done in the coming weeks.
>
> >From my expiriense, devel/glib20 cannot be compiled with gcc47.
>
> Isn't it built with the system default compiler:
>
> configure:3954: checking for C compiler version
> configure:3963: cc --version >&5
> cc (GCC) 4.2.1 20070831 patched [FreeBSD]
>
> I think we are only talking about updating lang/gcc to 4.7.

By default -- yes, it is going to build with base gcc.  But topic and,
therefore, my reaction was about overriding compiler to be lang/gcc*
from ports and whether there are ports, which fail in that case.  At
least, as I understand it.

Now, why overriding the compiler for Glib seems important to me and
why I tried to do that:

Since
commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58
Author: Ryan Lortie 
Date:   Tue Oct 18 16:21:50 2011 -0400

gatomic: introduce G_ATOMIC_LOCK_FREE

glib atomics implementation depends on gcc predefined macro
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base
gcc-4.2 and on Clang (all version, at least at that time).

As consequence, we have a mutex-based implementation of atomics.
Building Glib using more modern GCC (e.g. gcc-4.7) would help, but
gnome-libtool hack prevents us from that.

See also:
Thread "atomic ops broken on mac/xcode"
https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00089.html

Gnome bugzilla #682818: atomic ops broken on mac/xcode
https://bugzilla.gnome.org/show_bug.cgi?id=682818

LLVM/Clang bugzilla #11174: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_
http://llvm.org/bugs/show_bug.cgi?id=11174

-- 
Andrew W. Nosenko 
___
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 it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

[Anton Shterenlikht]

From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013

On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer  
wrote:
> On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
>> I've now run ia64 with the above change for over 2 weeks,
>> mostly rebuilding ports, etc.
>> I didn't see any issues with gcc47.
>> So, from my very limited testing,
>> gcc47 can be made default.
>
> Thanks for the feedback, Anton!  To really make that switch
> globally, we'll need more extensive testing, a full ports builds
> run, since there is a chance that some port you are not using may
> be broken, and I hope to get this done in the coming weeks.

>From my expiriense, devel/glib20 cannot be compiled with gcc47.

Isn't it built with the system default compiler:

configure:3954: checking for C compiler version
configure:3963: cc --version >&5
cc (GCC) 4.2.1 20070831 patched [FreeBSD]

I think we are only talking about updating lang/gcc to 4.7.

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

Re: Ports should provide knobs disabling unwanted network services

[Peter Pentchev]

On Tue, Mar 26, 2013 at 09:13:38AM +0100, Florent Peterschmitt wrote:
> Le 25/03/2013 04:40, Scot Hetzel a écrit :
> > On Sun, Mar 24, 2013 at 10:33 PM, Florent Peterschmitt
> >  wrote:
> >> Le 24/03/2013 17:34, Scot Hetzel a écrit :
> >>> On Sun, Mar 24, 2013 at 7:00 AM, Beeblebrox  wrote:
>  I would be very happy to submit a patch, if I actually knew how to write
>  one...
> 
> >>>
> >>> It is quite simple to create the patch.
> >>>
> >>> If you have a working copy checked out with svn, then it would be:
> >>>
> >>> cd /usr/ports/[category]/[port]
> >>> - Make the necessary changes to the port
> >>> - After testing the port make sure to do a 'make clean'
> >>> svn diff > port.diff
> >>>
> >>> Otherwise make a copy of the port:
> >>>
> >>> cd /usr/ports/[catagory]
> >>> cp port port-orig
> >>> cd port
> >>> - Make the necessary changes to port
> >>> - After testing port make sure to do a 'make clean'
> >>> cd ..
> >>> diff -ruN port-orig port > port.diff
> >>>
> >>> Then just submit the port.diff in a PR using either send-pr or
> >>> http://www.freebsd.org/send-pr.html.
> >>>
> >>
> >> Is there a way to manually make a patch that will say :
> >>
> >> --- MyFile
> >> +++ MyFile
> >>
> >> Even if these files are in two distinct trees ?
> >>
> > There is always a way to do that:
> > 
> > diff -u /path/to/original/port/MyFile /path/to/modified/port/MyFile >
> > /place/to/save/patch/port.diff
> > 
> > or if you modifed several files:
> > 
> > diff -ruN /path/to/original/port /path/to/modified/port >
> > /place/to/save/patch/port.diff
> > 
> Hum yes but what I mean is that we'll have, for example:
> 
> --- /home/florent-gentoo/patch/old/one2013-03-24 14:04:20.757200724 
> +0100
> +++ /home/florent-gentoo/patch/new/one2013-03-24 14:04:08.541201548 
> +0100
> […]
> 
> And what I want is:
> 
> --- /home/florent-gentoo/patch/old/one2013-03-24 14:04:20.757200724 
> +0100
> +++ /home/florent-gentoo/patch/old/one2013-03-24 14:04:08.541201548 
> +0100
> […]
> 
> SCM make patches like the second one and I'm no sure it is possible to
> do without modifying by hand the patch generated.

Well, one way to do it would be to actually *use* an SCM :)  My
preferred way would be a Git copy of the Subversion repository - then
you do your changes in your local Git tree and periodically pull down
the changes from the FreeBSD Subversion repo and merge them into yours.

But really, is there actually a reason why you don't want two separate
directories?  To be honest, before the advent of Subversion and Git
everyone did their patches that way (well, there *were* local CVS
repositories and checkouts from there, but most of the patches were
diffs between two side-by-side directories) - and I don't think anyone
ever complained.  Are there any problems you are seeing with two paths
in the diff headers, or is it just aesthetic?

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
I am jealous of the first word in this sentence.


signature.asc
Description: Digital signature

Re: Status of packages

[Erwin Lansing]

On Mon, Mar 25, 2013 at 06:33:35PM -0400, grarpamp wrote:
> There haven't been any package updates since last October, even
> September in the soon to be legacy case of RELENG_8 i386. So lets
> say six months.
> 
> Last status I noticed was in January pending 'security review of
> build farm code'.
> 
> Nearly two months later this would seem to be an unusual amount of
> time to leave those users who use only packages (not ports) hanging.
> 
> What needs done to get this rolling and out to the users again?
> 
This may not have made it out in this list, the latest announcement is
here http://www.freebsd.org/news/2012-compromise.html#update20130323

In short, we're working hard on getting everything back online and have
made some very good progress the last few weeks and days, and hope to
have packages available again shortly.

Best,
Erwin

-- 
Erwin Lansinghttp://droso.dk
er...@freebsd.orghttp:// 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: Ports should provide knobs disabling unwanted network services

[Florent Peterschmitt]

Le 25/03/2013 04:40, Scot Hetzel a écrit :
> On Sun, Mar 24, 2013 at 10:33 PM, Florent Peterschmitt
>  wrote:
>> Le 24/03/2013 17:34, Scot Hetzel a écrit :
>>> On Sun, Mar 24, 2013 at 7:00 AM, Beeblebrox  wrote:
 I would be very happy to submit a patch, if I actually knew how to write
 one...

>>>
>>> It is quite simple to create the patch.
>>>
>>> If you have a working copy checked out with svn, then it would be:
>>>
>>> cd /usr/ports/[category]/[port]
>>> - Make the necessary changes to the port
>>> - After testing the port make sure to do a 'make clean'
>>> svn diff > port.diff
>>>
>>> Otherwise make a copy of the port:
>>>
>>> cd /usr/ports/[catagory]
>>> cp port port-orig
>>> cd port
>>> - Make the necessary changes to port
>>> - After testing port make sure to do a 'make clean'
>>> cd ..
>>> diff -ruN port-orig port > port.diff
>>>
>>> Then just submit the port.diff in a PR using either send-pr or
>>> http://www.freebsd.org/send-pr.html.
>>>
>>
>> Is there a way to manually make a patch that will say :
>>
>> --- MyFile
>> +++ MyFile
>>
>> Even if these files are in two distinct trees ?
>>
> There is always a way to do that:
> 
> diff -u /path/to/original/port/MyFile /path/to/modified/port/MyFile >
> /place/to/save/patch/port.diff
> 
> or if you modifed several files:
> 
> diff -ruN /path/to/original/port /path/to/modified/port >
> /place/to/save/patch/port.diff
> 
Hum yes but what I mean is that we'll have, for example:

--- /home/florent-gentoo/patch/old/one  2013-03-24 14:04:20.757200724 +0100
+++ /home/florent-gentoo/patch/new/one  2013-03-24 14:04:08.541201548 +0100
[…]

And what I want is:

--- /home/florent-gentoo/patch/old/one  2013-03-24 14:04:20.757200724 +0100
+++ /home/florent-gentoo/patch/old/one  2013-03-24 14:04:08.541201548 +0100
[…]

SCM make patches like the second one and I'm no sure it is possible to
do without modifying by hand the patch generated.
-- 
Florent Peterschmitt
+33 (0)6 64 33 97 92
flor...@peterschmitt.fr



signature.asc
Description: OpenPGP digital signature