Re: Bug in r361898 (was Re: poudriere: services_mkdb recompile with larger PROTOMAX)

[Pedro Giffuni]

On 12/31/20 5:47 PM, Daniel Eischen wrote:

On Thu, 31 Dec 2020, Daniel Eischen wrote:


I see this message in src/UPDATING:

20201216:
 The services database has been updated to cover more of the basic
 services expected in a modern system. The database is big enough
 that it will cause issues in mergemaster in Releases previous to
 12.2 and 11.3, or in very old current systems from before r358154.

I'm trying to update a poudriere jail from a freshly built -current
system (r368820):

  FreeBSD vega.my.domain 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368820
  Wed Dec 30 15:55:06 EST 2020

I've tried running this command twice:

  export MAKEOBJDIRPREFIX=/opt/FreeBSD/obj/head.obj
  poudriere jail -u -j 13amd64

[ /opt/FreeBSD/obj/head.obj is my freshly built (r368820) obj tree is ]

services_mkdb was updated in the jail on the first pass:

  # ls -l /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb
  -r-xr-xr-x  1 root  wheel  15288 Dec 31 13:02 
/usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb


But as on the first pass of 'poudriere jail -u -j 13amd64`, I still get
the following error:

...

--- _CONFSINS_services ---
install -N /opt/FreeBSD/svn/head/etc  -C -o root  -g wheel -m 644 
/opt/FreeBSD/svn/head/usr.sbin/services_mkdb/services 
/usr/local/poudriere/jails/13amd64/etc/services

--- installconfig_subdir_usr.bin ---
--- installconfig_subdir_usr.bin/nice ---
===> usr.bin/nice (installconfig)
--- installconfig_subdir_usr.sbin ---
--- afterinstallconfig ---
--- installconfig_subdir_lib ---
--- installconfig_subdir_lib/ncurses ---
--- installconfig_subdir_lib/ncurses/ncurses ---
===> lib/ncurses/ncurses (installconfig)
--- installconfig_subdir_usr.sbin ---
services_mkdb -l -q -o 
/usr/local/poudriere/jails/13amd64/var/db/services.db 
/usr/local/poudriere/jails/13amd64/etc/services

--- installconfig_subdir_usr.bin ---
--- installconfig_subdir_usr.bin/nl ---
===> usr.bin/nl (installconfig)
--- installconfig_subdir_usr.sbin ---
services_mkdb: Ran out of protocols adding `divert'; recompile with 
larger PROTOMAX


What's the work-around for this?  services_mkdb seems to have been
updated on the first pass off 'poudiere jail -u ...', but still fails
on the second pass.


A typo (tdp was used instead of tcp) in the services file seems to
have been introduced in r361898.  This is the patch that fixes the
problem for me.

Index: usr.sbin/services_mkdb/services
===
--- usr.sbin/services_mkdb/services (revision 368820)
+++ usr.sbin/services_mkdb/services (working copy)
@@ -1788,7 +1788,7 @@
 iscsi-target 3260/udp   # iSCSI port
 mysql  3306/tcp   #MySQL
 mysql  3306/udp   #MySQL
-ms-wbt-server 3389/tdp   rdp #MS WBT Server
+ms-wbt-server 3389/tcp   rdp #MS WBT Server
 ms-wbt-server 3389/udp   #MS WBT Server
 efi-lm  3392/tcp   #EFI License Management
 efi-lm  3392/udp   #EFI License Management


Oops  thanks !

It proved a nice chance to start using git.

Pedro.

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

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

[Pedro Giffuni]

On 11/04/2018 11:53, Lucas Holt wrote:

Machines don’t need to be old to have issues. I have a two year old asus am3+ 
board that cant boot from gpt without secure boot enabled and is hard coded for 
Microsoft keys

Lucas Holt


Interesting. Not sure Clover would help there though, secure boot is a  
different issue:


https://wiki.freebsd.org/SecureBoot

Cheers,

Pedro.


On Apr 11, 2018, at 12:04 PM, Ryan Stone <ryst...@gmail.com> wrote:


On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni <p...@freebsd.org> wrote:
Hi;

FWIW, I use a very old PC of the type where the processor will not be fixed
by Intel and that still needs support for the traditional BIOS. I also
bought a 3TB HD (they were easier to find that 2T).

If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and
will happily use ZFS for everything, however I want to dual boot so after
lots of testing I ended up ignoring 1 TB of HD :(.

It does happen that there is a really nice boot loader that could have saved
the day but it is very difficult to install standalone:

https://sourceforge.net/projects/cloverefiboot

Just in case someone has the time and inclination to play with it :)

Pedro.

Is the issue due to using MBR partitioning?  FreeBSD supports booting
from a GPT partition from a traditional BIOS; you don't need EFI.  Is
this machine so old that its BIOS doesn't support booting from GPT?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

[Pedro Giffuni]

On 11/04/2018 11:04, Ryan Stone wrote:

On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni <p...@freebsd.org> wrote:

Hi;

FWIW, I use a very old PC of the type where the processor will not be fixed
by Intel and that still needs support for the traditional BIOS. I also
bought a 3TB HD (they were easier to find that 2T).

If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and
will happily use ZFS for everything, however I want to dual boot so after
lots of testing I ended up ignoring 1 TB of HD :(.

It does happen that there is a really nice boot loader that could have saved
the day but it is very difficult to install standalone:

https://sourceforge.net/projects/cloverefiboot

Just in case someone has the time and inclination to play with it :)

Pedro.

Is the issue due to using MBR partitioning?  FreeBSD supports booting
from a GPT partition from a traditional BIOS; you don't need EFI.  Is
this machine so old that its BIOS doesn't support booting from GPT?


It's a Dell Optiplex 760 (refurbished). I don't remember the details but 
FreeBSD supports booting just fine if I dedicate all the HD to 
FreeBSD/GPT, but the Windows bootloader wont so I needed a bootloader 
with it's own EFI implementation that would. Clover comes from the 
Apple/Darwin world and does this but I never managed to install it in a 
HD; ideally you have to figure out how to install it before installing 
the OS so I had to install it later in a thumbdrive.


FWIW, the only documentation I could find on the gory details for dual 
booting (with linux) is here:


https://www.rodsbooks.com/gdisk/bios.html

Cheers,

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

CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

[Pedro Giffuni]

Hi;

FWIW, I use a very old PC of the type where the processor will not be 
fixed by Intel and that still needs support for the traditional BIOS. I 
also bought a 3TB HD (they were easier to find that 2T).


If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB 
and will happily use ZFS for everything, however I want to dual boot so 
after lots of testing I ended up ignoring 1 TB of HD :(.


It does happen that there is a really nice boot loader that could have 
saved the day but it is very difficult to install standalone:


https://sourceforge.net/projects/cloverefiboot

Just in case someone has the time and inclination to play with it :)

Pedro.


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

Re: reducing build times; selecting specific clang targets

[Pedro Giffuni]

Just my $0.02:



On 12/09/17 02:50, Ed Schouten wrote:
> Hi Michael,
> 
> 2017-12-09 4:57 GMT+01:00 Michael Butler :

>> As clang builds for multiple targets unconditionally, it takes *days* to
>> build on one of my devices (700MHz Pentium-3).
>>
>> Is there a way to restrict the build targets to i386 only? If not, can we
>> implement one?
> 
> Regardless of the discussion of how and whether this may be

> implemented, do take into consideration that the target specific bits
> in Clang only account for a minority of the build time. It is not as
> if Clang is literally built multiple times, once for every
> architecture. The build will likely still take several days, even if
> this got fixed.
> 
> Have you considered doing builds on some other system and copying the

> results over? According to Wikipedia, they stopped producing Pentium
> III CPUs 14 years ago. Using these systems to do actual builds sounds
> like a waste of electricity.
> 


Far less than the electricity consumed by an entire planet's worth of
BSD systems building for targets they'll never use.

The target system is in a remote data-center to which I have limited
access and is the only remaining one of its type in my network. The old
installer used to be able to select a set of source archives from which
to update but I don't see that functionality in any of the current
tools. What did I miss?


freebsd-update(8)

pkg upgrade

that would mean running a release, but it makes life so much easier.

Cheers,

Pedro.

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

ARM broken since a while

[Pedro Giffuni]

On 11/25/17 15:28, Pedro Giffuni wrote:


...

I have seen problems on arm with zstd though.


For the record:
arm.armv6 buildworld failed, check _.arm.armv6.buildworld for details

===> lib/libzstd (all)
Assertion failed: (LiveCPSR && "CPSR liveness tracking is wrong!"), 
function UpdateCPSRUse, file 
/usr/src/contrib/llvm/lib/Target/ARM/Thumb2SizeReduction.cpp, line 961.

cc: error: unable to execute command: Abort trap (core dumped)
cc: error: clang frontend command failed due to signal (use -v to see 
invocation)
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on 
LLVM 5.0.0svn)

Target: armv6--freebsd12.0-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
cc: note: diagnostic msg: PLEASE submit a bug report to 
https://bugs.freebsd.org/submit/ and include the crash backtrace, 
preprocessed source, and associated run script.

cc: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
cc: note: diagnostic msg: /tmp/zstd_compress-3f783c.c
cc: note: diagnostic msg: /tmp/zstd_compress-3f783c.sh
cc: note: diagnostic msg:


--- zstd_compress.o ---
*** [zstd_compress.o] Error code 254

make[7]: stopped in /scratch/tmp/pfg/head/lib/libzstd



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

Re: head -r326193 (e.g.) buildworld broken: rejecting some . . ./usr/src/amd64.amd64/tmp/usr/include/stdio.h content

[Pedro Giffuni]

Thank you for the report ...


On 11/25/17 15:15, Mark Millard wrote:

[Quick top post:]

Reverting to -r326192 and rebuilding avoided the issue.
  
Prior notes:


On 2017-Nov-25, at 12:02 PM, Mark Millard  wrote:


For example,

/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/stdio.h:449:47:
 error: function definition is not allowed here
static __inline int __sputc(int _c, FILE *_p) {

for:

/*
* The __sfoo macros are here so that we can
* define function versions in the C library.
*/
#define __sgetc(p) (--(p)->_r < 0 ? __srget(p) : (int)(*(p)->_p++))
#if defined(__GNUC__) && defined(__STDC__)
static __inline int __sputc(int _c, FILE *_p) {
if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
return (*_p->_p++ = _c);
else
return (__swbuf(_c, _p));
}
#else
/*
* This has been tuned to generate reasonable code on the vax using pcc.
*/
#define __sputc(c, p) \
(--(p)->_w < 0 ? \
(p)->_w >= (p)->_lbfsize ? \
(*(p)->_p = (c)), *(p)->_p != '\n' ? \
(int)*(p)->_p++ : \
__swbuf('\n', p) : \
__swbuf((int)(c), p) : \
(*(p)->_p = (c), (int)*(p)->_p++))
#endif



More of the prefix of the messages:



--- var.o ---
In file included from /usr/src/bin/sh/var.c:70:
In file included from /usr/src/bin/sh/myhistedit.h:35:
In file included from 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/histedit.h:48:
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/stdio.h:255:6: 
warning: declaration of built-in function 'fprintf' requires inclusion of the header 
 [-Wbuiltin-requires-header]
int  fprintf(FILE * __restrict, const char * __restrict, ...);
 ^
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/stdio.h:260:6: 
warning: declaration of built-in function 'fscanf' requires inclusion of the header 
 [-Wbuiltin-requires-header]
int  fscanf(FILE * __restrict, const char * __restrict, ...);
 ^
--- csh_make ---
Building 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/rescue/rescue/usr/src/bin/csh/sh.init.o
--- sh_make ---
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/stdio.h:284:6: 
warning: declaration of built-in function 'vfprintf' requires inclusion of the header 
 [-Wbuiltin-requires-header]
int  vfprintf(FILE * __restrict, const char * __restrict,
 ^
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/stdio.h:293:6: 
warning: declaration of built-in function 'vfscanf' requires inclusion of the header 
 [-Wbuiltin-requires-header]
int  vfscanf(FILE * __restrict, const char * __restrict, __va_list)
 ^
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/stdio.h:449:47:
 error: function definition is not allowed here
static __inline int __sputc(int _c, FILE *_p) {
  ^
In file included from /usr/src/bin/sh/var.c:70:
In file included from /usr/src/bin/sh/myhistedit.h:35:
In file included from 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/histedit.h:254:
In file included from 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/wchar.h:69:
In file included from 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/_ctype.h:97:
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/runetype.h:96:1:
 error: function definition is not allowed here
{
^
In file included from /usr/src/bin/sh/var.c:70:
In file included from /usr/src/bin/sh/myhistedit.h:35:
In file included from 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/histedit.h:254:
In file included from 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/wchar.h:69:
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/include/_ctype.h:101:1:
 error: function definition is not allowed here
{
^
. . . (much omitted) . . .


I can't reproduce it ...
I have been running tinderbox builds with the changes for a while.

Jenkins wasn't affected either:
https://ci.freebsd.org/job/FreeBSD-head-amd64-build/6040/

I have seen problems on arm with zstd though.

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

Re: localedef broken on current amd64

[Pedro Giffuni]

Yes, I am looking at it,

I suspect there is an underlying bug but I will be reverting the latest 
change.


Thank you,

Pedro.


On 3/9/2017 12:25 PM, Manfred Antar wrote:

I rebuilt localedef on current this morning.
doing a make buildworld:

===> colldef (all)
localedef -D -U -i /usr/src/share/colldef/af_ZA.UTF-8.src  -f 
/usr/src/tools/tools/locale/etc/final-maps/map.UTF-8 
/usr/obj/usr/src/share/colldef/af_ZA.UTF-8
/usr/src/share/colldef/af_ZA.UTF-8.src: 2421: error: Bad file descriptor
*** Error code 4

worked fine yesterday


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

Re: resolvconf Makefile RESTARTCMD sed after r312992

[Pedro Giffuni]

Committed as r313160.

Thanks!

Pedro.

On 2/3/2017 3:24 AM, Guy Yur wrote:

Hi,

In openresolv 3.9.0, the only RESTARTCMD pattern left is @RESTARTCMD@.
The '@RESTARTCMD something@' pattern was dropped from pdns_recursor.in.

r312992 removed RESTARTCMD_WITH_ARG for @RESTARTCMD something@ but
reverted the sed to be '@RESTARTCMD \(.*\)@' and RESTARTCMD= to be
the value of RESTARTCMD_WITH_ARG.

After the change /sbin/resolvconf has 'RESTARTCMD=@RESTARTCMD@' again.

Attaching patch to restore RESTARTCMD=, CMD1=, CMD2= and sed pattern
to values before r312992.

Thanks,
Guy


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

Re: [RFC] remove GNU rcs from FreeBSD 12

[Pedro Giffuni]

+1 to removing GNU RCS.

FWIW;

I did bring OpenRCS to the vendor area:

https://svnweb.freebsd.org/base/vendor/OpenBSD/dist/usr.bin/rcs/

And I have a patch so that it builds on FreeBSD:

https://people.freebsd.org/~pfg/patches/openrcs.diff

It is known to NOT pass the GNU RCS testsuite and I lost interest in it.

Pedro.

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

Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062

[Pedro Giffuni]

On 07/31/16 11:56, Guy Yur wrote:

On Sun, Jul 31, 2016 at 5:46 AM, Pedro Giffuni <p...@freebsd.org> wrote:




Index: sbin/resolvconf/Makefile
===
--- sbin/resolvconf/Makefile(revision 303557)
+++ sbin/resolvconf/Makefile(working copy)
@@ -30,6 +30,7 @@
-e 's:@LIBEXECDIR@:${FILESDIR}:g' \
-e 's:@VARDIR@:${VARDIR}:g' \
-e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \
+   -e 's:@RESTARTCMD@:${RESTARTCMD}:g' \
-e 's:@RCDIR@:${RCDIR}:g' \
-e 's: vpn : ng[0-9]*&:g' \
${DIST}/$@.in > $@





And the underscore was not a typo.
Thanks Guy!

Pedro.


Hi,

I meant for the RESTARTCMD_= statement to be added too.
I should have sent a patch file.



Ugh ... yeah I am really bad at "guessing" patches.

I will play with your patch. Thanks.

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

Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062

[Pedro Giffuni]

On 07/30/16 21:35, Glen Barber wrote:
...



I don't see the error message though. so I need some confirmation that
this fixes the issue.



Likewise, I do not see the error either, so would like definitive
confirmation the patch resolves the issue.



OK, I don't see the error message but I can reproduce it:

 % grep @RESTARTCMD@ *
resolvconf:RESTARTCMD=@RESTARTCMD@



Index: sbin/resolvconf/Makefile
===
--- sbin/resolvconf/Makefile(revision 303557)
+++ sbin/resolvconf/Makefile(working copy)
@@ -30,6 +30,7 @@
-e 's:@LIBEXECDIR@:${FILESDIR}:g' \
-e 's:@VARDIR@:${VARDIR}:g' \
-e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \
+   -e 's:@RESTARTCMD@:${RESTARTCMD}:g' \
-e 's:@RCDIR@:${RCDIR}:g' \
-e 's: vpn : ng[0-9]*&:g' \
${DIST}/$@.in > $@




And the underscore was not a typo.
Thanks Guy!

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

Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062

[Pedro Giffuni]

(CC'ing Glen for review, since he was the last to touch that file and
may know better).

Hi Guy;


On 07/30/16 17:37, Guy Yur wrote:

Hi,

openresolv 3.8.1 added RESTARTCMD=@RESTARTCMD@ in
contrib/openresolv/resolvconf.in.
It is not replaced by the sed expressions in sbin/resolvconf/Makefile.

Error seen is "eval: @RESTARTCMD@: not found".

Current @RESTARTCMD \(.*\)@ sed expression needs to be kept for
pdns_recursor.in and a new expression added to replace @RESTARTCMD@.



I see, you mean here:

https://svnweb.freebsd.org/base/head/sbin/resolvconf/Makefile?revision=298107=markup#l32


The following worked for me:
RESTARTCMD_="/usr/sbin/service \\$$1 onestatus >/dev/null 2>\&1
\&\& /usr/sbin/service \\$$1 restart"

sed ... \
  ... \
  -e 's:@RESTARTCMD@:${RESTARTCMD_}:g' \
  ...


And perhaps something like the attached patch (is the underscore
a typo?).

I don't see the error message though. so I need some confirmation that
this fixes the issue.

Pedro.
Index: sbin/resolvconf/Makefile
===
--- sbin/resolvconf/Makefile	(revision 303557)
+++ sbin/resolvconf/Makefile	(working copy)
@@ -30,6 +30,7 @@
 		-e 's:@LIBEXECDIR@:${FILESDIR}:g' \
 		-e 's:@VARDIR@:${VARDIR}:g' \
 		-e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \
+		-e 's:@RESTARTCMD@:${RESTARTCMD}:g' \
 		-e 's:@RCDIR@:${RCDIR}:g' \
 		-e 's: vpn : ng[0-9]*&:g' \
 		${DIST}/$@.in > $@
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: clang 3.3/3.4 fails to build items that use stdlib.h because of __alloc_size attribute assigned to posix_memalign

[Pedro Giffuni]

Answering to myself 

On 07/05/16 15:24, Pedro Giffuni wrote:

Hmm ...

On 07/05/16 15:14, Conrad Meyer wrote:

Whoops, missed reply-all the first time.

It seems pretty clear that alloc_size (return value is a memory
allocation of size from parameter N) does not apply to posix_memalign,
because posix_memalign's allocation is stored via a pointer argument
rather than return value.

https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes


IMO the attribute should be removed from posix_memalign in stdlib.h

Best,
Conrad



- I am wondering why it hasn't affected -current if it is wrong.


Because newer clang removed alloc_size altogether.


- I am also wondering if we shouldn't just get rid of the attribute.



Nah, it is basically meant for FORTIFY_SOURCE, which is not being
worked on anymore but maybe handy some day.


I will answer to myself those doubts and fix the issue. Thanks!



So, yes, we should remove it from posix_memalign(). I'll ask re@.

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

Re: clang 3.3/3.4 fails to build items that use stdlib.h because of __alloc_size attribute assigned to posix_memalign

[Pedro Giffuni]

Hmm ...

On 07/05/16 15:14, Conrad Meyer wrote:

Whoops, missed reply-all the first time.

It seems pretty clear that alloc_size (return value is a memory
allocation of size from parameter N) does not apply to posix_memalign,
because posix_memalign's allocation is stored via a pointer argument
rather than return value.

https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

IMO the attribute should be removed from posix_memalign in stdlib.h

Best,
Conrad



- I am wondering why it hasn't affected -current if it is wrong.
- I am also wondering if we shouldn't just get rid of the attribute.

I will answer to myself those doubts and fix the issue. Thanks!

Pedro.


On Tue, Jul 5, 2016 at 1:07 PM, Ngie Cooper (yaneurabeya)
 wrote:

Hi,
It looks like clang 3.3/3.4 from ports both don’t like __alloc_size 
being attached to posix_memalign. This only concerns me because it might make 
the src upgrade path from 9.3/10.3 to 11.0 painful.
Thoughts on how this should be fixed or whether or not we care?
Thanks,
-Ngie

$ cd usr.sbin/bhyve; make clean; script ts make all CC=clang34
...
In file included from /usr/src/svn/usr.sbin/bhyve/atkbdc.c:40:
/usr/include/stdlib.h:176:6: error: '__alloc_size__' attribute only applies to 
functions that return a pointer [-Werror,-Wignored-attributes]
__alloc_size(3);/* (ADV) */
^
/usr/include/sys/cdefs.h:241:40: note: expanded from macro '__alloc_size'
#define __alloc_size(x) __attribute__((__alloc_size__(x)))
   ^
1 error generated.
*** Error code 1

Stop.
make: stopped in /usr/src/svn/usr.sbin/bhyve
$ (set -x; clang33 --version; clang34 --version)
+ clang33 --version
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-portbld-freebsd11.0
Thread model: posix
+ clang34 --version
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: x86_64-portbld-freebsd11.0
Thread model: posix

282988pfg intposix_memalign(void **, size_t, size_t) __nonnull(1) 
__alloc_align(2)
281130pfg   __alloc_size(3);/* (ADV) */

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

Re: Patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179721 broke some application (xterm, pidign)

[Pedro Giffuni]

Hello Vitalij;


Hello.

After updating my system to 11.0-ALPHA2 #20 r301583
I'm found that at last some application is broken.

here backtrace for xterm

#0  0x0008022d48b4 in mbsrtowcs_l () from /lib/libc.so.7
[New Thread 804816000 (LWP 102346/)]
(gdb) bt
#0  0x0008022d48b4 in mbsrtowcs_l () from /lib/libc.so.7
#1  0x0008022d1b4f in strcoll_l () from /lib/libc.so.7
#2  0x0008022d0ddf in __collate_range_cmp () from /lib/libc.so.7
#3  0x0008022cf6ce in vfscanf () from /lib/libc.so.7
#4  0x0008022b0114 in vsscanf () from /lib/libc.so.7
#5  0x0008022aee6d in sscanf () from /lib/libc.so.7
#6  0x004523a3 in ?? ()
#7  0x00430edd in ?? ()

for pidgin it's look same.

It seems that patch not fully care about all cases where function like 
__collate_range_cmp used.

Manualy rollback changes from 
http://svnweb.freebsd.org/base?view=revision=301461  fix the problem 
for now.



Thank you very much for the report.
I am testing the fix (replacing __collate_range_cmp in vfscanf()),
right now.

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

Re: CURRENT: bhyve and Kernel SamePage Mergin

[Pedro Giffuni]

Hi oh;

Nothing to worry: for good or bad, FreeBSD has no memory deduplication 
mechanism implemented.


Pedro.

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

Re: CFR: extend use of nitems() macro in the kernel.

[Pedro Giffuni]

On 04/18/16 13:27, John Baldwin wrote:

On Saturday, April 16, 2016 01:25:09 PM Pedro Giffuni wrote:

Hello;

Using coccinelle, and some hand re-formatting, I generated a patch to
make use of the nitems() macro in sys, which is too big for
phabricator [1].

I was careful to exclude anything from the contrib directory or
any code that is shared with userland (as to not have to include
additional headers).

The patch is big but pretty safe, I think. The changes are small but
still it touches many files[1].

I would like some feedback on the convenience of doing such replacement.
If it is a good idea we could do the same for roundup2() and, in fact,
I think DragonFly has already done this.

Regards,

Pedro.

[1] https://people.freebsd.org/~pfg/patches/sys-nitems.diff

[2] For those too lazy to check [1], here is a list of affected files.

M   sys/amd64/amd64/amd64_mem.c
M   sys/amd64/amd64/machdep.c
M   sys/amd64/linux/linux_sysvec.c
M   sys/amd64/linux32/linux32_sysvec.c
M   sys/arm/amlogic/aml8726/aml8726_clkmsr.c
M   sys/arm/arm/db_interface.c
M   sys/arm/at91/at91_pmc.c
M   sys/arm/mv/armadaxp/armadaxp.c
M   sys/arm/ti/cpsw/if_cpsw.c
M   sys/arm/xscale/ixp425/ixp425.c
M   sys/boot/common/part.c
M   sys/boot/efi/loader/bootinfo.c
M   sys/boot/mips/beri/boot2/boot2.c
M   sys/boot/uboot/common/metadata.c
M   sys/cam/ata/ata_da.c
M   sys/cam/ata/ata_xpt.c


I would perhaps remove ata_quirk_table_size entirely and replace its
use with nitems() directly.  Probably best if that was a separate commit
though from the near-mechanical replacement.


M   sys/cam/cam.c


Same here.  num_cam_status_entries is only used in one place and I think
directly using nitems() is probably clearer overall.


M   sys/cam/scsi/scsi_all.c


Possibly the same here with sense_key_table_size.


M   sys/cam/scsi/scsi_cd.c
M   sys/cam/scsi/scsi_da.c
M   sys/cam/scsi/scsi_sa.c
M   sys/cam/scsi/scsi_xpt.c


Same as for ata_quirk_table_size (ironically this used the size in one
place and the expanded form of nitems in another while the ata variant
at least used the size in both places).


M   sys/cam/scsi/smp_all.c
M   sys/compat/linux/linux_socket.c
M   sys/ddb/db_variables.c
M   sys/dev/adb/adb_kbd.c
M   sys/dev/advansys/adv_isa.c
M   sys/dev/advansys/advlib.c
M   sys/dev/advansys/adw_pci.c


Same here for num adw_num_pci_devs (only used once)


M   sys/dev/advansys/adwlib.c


Probably the same here for adw_num_sync_rates (used twice).


M   sys/dev/ae/if_ae.c


Same here for AE_DEVS_COUNT (only used once).


M   sys/dev/age/if_age.c
M   sys/dev/agp/agp.c
M   sys/dev/agp/agp_ali.c
M   sys/dev/agp/agp_amd64.c
M   sys/dev/aha/aha_isa.c
M   sys/dev/aic/aic.c
M   sys/dev/aic/aic_cbus.c


Same here for AIC_ISA_NUMPORTS (only used once).


M   sys/dev/aic/aic_isa.c


As above.


M   sys/dev/ale/if_ale.c
M   sys/dev/altera/atse/if_atse.c
M   sys/dev/atkbdc/atkbd.c
M   sys/dev/atkbdc/atkbdc.c
M   sys/dev/atkbdc/psm.c
M   sys/dev/bktr/bktr_core.c
M   sys/dev/bwi/bwirf.c
M   sys/dev/bwn/if_bwn.c
M   sys/dev/cardbus/cardbus_cis.c
M   sys/dev/digi/digi.c
M   sys/dev/digi/digi_isa.c
M   sys/dev/dwc/if_dwc.c
M   sys/dev/ed/if_ed_hpp.c
M   sys/dev/ed/if_ed_isa.c
M   sys/dev/ed/if_ed_pci.c
M   sys/dev/fb/creator.c


Same here for CREATOR_FB_MAP_SIZE (only used once).


M   sys/dev/fb/fb.c
M   sys/dev/fb/machfb.c
M   sys/dev/fb/vesa.c
M   sys/dev/fb/vga.c
M   sys/dev/flash/mx25l.c
M   sys/dev/hatm/if_hatm.c
M   sys/dev/hifn/hifn7751.c
M   sys/dev/hwpmc/hwpmc_amd.c


Same here for amd_event_codes_size (only used twice).


M   sys/dev/hwpmc/hwpmc_core.c


Same here for niap_events.


M   sys/dev/hwpmc/hwpmc_e500.c


e500_event_codes_size isn't even used.  It should just be removed.


M   sys/dev/hwpmc/hwpmc_mips24k.c
M   sys/dev/hwpmc/hwpmc_mips74k.c
M   sys/dev/hwpmc/hwpmc_mpc7xxx.c


Same here for mpc7xxx_event_codes_size.


M   sys/dev/hwpmc/hwpmc_octeon.c
M   sys/dev/hwpmc/hwpmc_uncore.c


Same here for nucp_events.


M   sys/dev/hwpmc/hwpmc_xscale.c


Same here for xscale_event_codes_size.


M   sys/dev/if_ndis/if_ndis.c
M   sys/dev/jme/if_jme.c
M   sys/dev/kbd/kbd.c
M   sys/dev/le/if_le_isa.c
M   sys/dev/le/if_le_lebuffer.c


Same here for NLEMEDIA (only used once).


M   sys/dev/le/if_le_ledma.c
M   sys/dev/mlx/mlx.c
M   sys/dev/mxge/if_mxge.c
M   sys/dev/nand/nand_id.c
M   sys/dev/ncr/ncr.c
M   sys/dev/nctgpio/nctgpio.c
M   sys/dev/nfe/if_nfe.c
M   sys/dev/patm/if_patm_attach.c
M   sys/dev/pccard/pccard_cis_quirks.c


Same here for n_pccard_cis_quirks (only used once).


M   sys/dev/rc/rc.c
M   sys/dev/re/if_re.c
M   sys/dev/rl/if_rl.c
M   sys/dev/rndtest/rndtest.c


Same here for RNDTEST_NTESTS

Re: CFR: extend use of nitems() macro in the kernel.

[Pedro Giffuni]

On 04/18/16 01:56, Hans Petter Selasky wrote:

On 04/16/16 20:25, Pedro Giffuni wrote:

M   sys/dev/usb/input/ukbd.c
M   sys/dev/usb/serial/u3g.c
M   sys/dev/usb/serial/uchcom.c
M   sys/dev/usb/serial/umcs.c
M   sys/dev/usb/serial/uplcom.c


Approved. Maybe you can remove the superfluous pair of parenthesis after
the substitution?



Thanks: I'll look at improving the script.

FWIW, I already have a roundup2/rounddown2 semantic patch but it
is slow.

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

CFR: extend use of nitems() macro in the kernel.

[Pedro Giffuni]

Hello;

Using coccinelle, and some hand re-formatting, I generated a patch to
make use of the nitems() macro in sys, which is too big for
phabricator [1].

I was careful to exclude anything from the contrib directory or
any code that is shared with userland (as to not have to include
additional headers).

The patch is big but pretty safe, I think. The changes are small but
still it touches many files[1].

I would like some feedback on the convenience of doing such replacement.
If it is a good idea we could do the same for roundup2() and, in fact,
I think DragonFly has already done this.

Regards,

Pedro.

[1] https://people.freebsd.org/~pfg/patches/sys-nitems.diff

[2] For those too lazy to check [1], here is a list of affected files.

M   sys/amd64/amd64/amd64_mem.c
M   sys/amd64/amd64/machdep.c
M   sys/amd64/linux/linux_sysvec.c
M   sys/amd64/linux32/linux32_sysvec.c
M   sys/arm/amlogic/aml8726/aml8726_clkmsr.c
M   sys/arm/arm/db_interface.c
M   sys/arm/at91/at91_pmc.c
M   sys/arm/mv/armadaxp/armadaxp.c
M   sys/arm/ti/cpsw/if_cpsw.c
M   sys/arm/xscale/ixp425/ixp425.c
M   sys/boot/common/part.c
M   sys/boot/efi/loader/bootinfo.c
M   sys/boot/mips/beri/boot2/boot2.c
M   sys/boot/uboot/common/metadata.c
M   sys/cam/ata/ata_da.c
M   sys/cam/ata/ata_xpt.c
M   sys/cam/cam.c
M   sys/cam/scsi/scsi_all.c
M   sys/cam/scsi/scsi_cd.c
M   sys/cam/scsi/scsi_da.c
M   sys/cam/scsi/scsi_sa.c
M   sys/cam/scsi/scsi_xpt.c
M   sys/cam/scsi/smp_all.c
M   sys/compat/linux/linux_socket.c
M   sys/ddb/db_variables.c
M   sys/dev/adb/adb_kbd.c
M   sys/dev/advansys/adv_isa.c
M   sys/dev/advansys/advlib.c
M   sys/dev/advansys/adw_pci.c
M   sys/dev/advansys/adwlib.c
M   sys/dev/ae/if_ae.c
M   sys/dev/age/if_age.c
M   sys/dev/agp/agp.c
M   sys/dev/agp/agp_ali.c
M   sys/dev/agp/agp_amd64.c
M   sys/dev/aha/aha_isa.c
M   sys/dev/aic/aic.c
M   sys/dev/aic/aic_cbus.c
M   sys/dev/aic/aic_isa.c
M   sys/dev/ale/if_ale.c
M   sys/dev/altera/atse/if_atse.c
M   sys/dev/atkbdc/atkbd.c
M   sys/dev/atkbdc/atkbdc.c
M   sys/dev/atkbdc/psm.c
M   sys/dev/bktr/bktr_core.c
M   sys/dev/bwi/bwirf.c
M   sys/dev/bwn/if_bwn.c
M   sys/dev/cardbus/cardbus_cis.c
M   sys/dev/digi/digi.c
M   sys/dev/digi/digi_isa.c
M   sys/dev/dwc/if_dwc.c
M   sys/dev/ed/if_ed_hpp.c
M   sys/dev/ed/if_ed_isa.c
M   sys/dev/ed/if_ed_pci.c
M   sys/dev/fb/creator.c
M   sys/dev/fb/fb.c
M   sys/dev/fb/machfb.c
M   sys/dev/fb/vesa.c
M   sys/dev/fb/vga.c
M   sys/dev/flash/mx25l.c
M   sys/dev/hatm/if_hatm.c
M   sys/dev/hifn/hifn7751.c
M   sys/dev/hwpmc/hwpmc_amd.c
M   sys/dev/hwpmc/hwpmc_core.c
M   sys/dev/hwpmc/hwpmc_e500.c
M   sys/dev/hwpmc/hwpmc_mips24k.c
M   sys/dev/hwpmc/hwpmc_mips74k.c
M   sys/dev/hwpmc/hwpmc_mpc7xxx.c
M   sys/dev/hwpmc/hwpmc_octeon.c
M   sys/dev/hwpmc/hwpmc_uncore.c
M   sys/dev/hwpmc/hwpmc_xscale.c
M   sys/dev/if_ndis/if_ndis.c
M   sys/dev/jme/if_jme.c
M   sys/dev/kbd/kbd.c
M   sys/dev/le/if_le_isa.c
M   sys/dev/le/if_le_lebuffer.c
M   sys/dev/le/if_le_ledma.c
M   sys/dev/mlx/mlx.c
M   sys/dev/mxge/if_mxge.c
M   sys/dev/nand/nand_id.c
M   sys/dev/ncr/ncr.c
M   sys/dev/nctgpio/nctgpio.c
M   sys/dev/nfe/if_nfe.c
M   sys/dev/patm/if_patm_attach.c
M   sys/dev/pccard/pccard_cis_quirks.c
M   sys/dev/rc/rc.c
M   sys/dev/re/if_re.c
M   sys/dev/rl/if_rl.c
M   sys/dev/rndtest/rndtest.c
M   sys/dev/sf/if_sf.c
M   sys/dev/sge/if_sge.c
M   sys/dev/siba/siba.c
M   sys/dev/sio/sio.c
M   sys/dev/sound/isa/gusc.c
M   sys/dev/sound/pci/emu10kx.c
M   sys/dev/speaker/spkr.c
M   sys/dev/stge/if_stge.c
M   sys/dev/uart/uart_kbd_sun.c
M   sys/dev/uart/uart_subr.c
M   sys/dev/usb/input/ukbd.c
M   sys/dev/usb/serial/u3g.c
M   sys/dev/usb/serial/uchcom.c
M   sys/dev/usb/serial/umcs.c
M   sys/dev/usb/serial/uplcom.c
M   sys/dev/vkbd/vkbd.c
M   sys/dev/wbwd/wbwd.c
M   sys/fs/autofs/autofs.c
M   sys/fs/nfs/nfs_commonkrpc.c
M   sys/geom/part/g_part_bsd.c
M   sys/geom/part/g_part_ebr.c
M   sys/geom/part/g_part_ldm.c
M   sys/geom/part/g_part_mbr.c
M   sys/i386/i386/i686_mem.c
M   sys/i386/i386/machdep.c
M   sys/i386/ibcs2/ibcs2_sysvec.c
M   sys/i386/linux/linux_sysvec.c
M   sys/kern/kern_dump.c
M   sys/kern/kern_ffclock.c
M   sys/kern/kern_jail.c
M   sys/kern/kern_ktrace.c
M   sys/kern/subr_hash.c
M   sys/kern/subr_witness.c
M   sys/kern/sysv_msg.c
M   sys/kern/sysv_sem.c
M   sys/kern/uipc_usrreq.c
M   sys/mips/mips/db_interface.c
M   sys/mips/nlm/board.c
M   sys/mips/nlm/xlp_machdep.c
M   sys/mips/rmi/dev/nlge/if_nlge.c
M   sys/net/netisr.c
M   sys/net/rtsock.c
M   

Re: lldb input issue

[Pedro Giffuni]

On 03/06/16 15:20, Pedro Giffuni wrote:



El 06/03/2016 a las 15:05, Baptiste Daroussin escribió:

On Sun, Mar 06, 2016 at 10:55:27PM +0300, Roman Bogorodskiy wrote:

   Baptiste Daroussin wrote:


On Sun, Mar 06, 2016 at 07:44:34PM +0300, Roman Bogorodskiy wrote:

Hi,

I'm seeing an issue with lldb: when I start it (without arguments) and
try to type commands, it looks like this:

$  lldb
(lldb) \U+7F68\U+7F65\U+7F6C\U+7F70\U+7F0A

So, basically, I cannot execute any command and cannot even exit from
its shell, only by ctrl-z and killing it.

This happens to me on today's -CURRENT / amd64.

I was wondering if that's an issue with my user's locale, but the
behavior is same for root.

Also, I can see exactly the same behavior with lldb on FreeBSD.

^^^
Oops, that's supposed to be 'freefall'.


Is that some known issue or maybe configuration problem?

Thanks,

Roman Bogorodskiy



Sounds like an issue with libedit, probably due to the latest import
of libedit
(just a guess)

It could be. BTW, I've installed lldb38 using pkg and it works fine.


Which is linked to libedit from ports (older that in base) so it seems
to prove
that libedit update might be the issue there.


Hmm ... most of the changes were cosmetical. I will take a look though.



Actually we have had two updates lately with sufficient changes that it
is not easy to find which may be the culprit. I will revert the last
change in the hope that it is enough.

Sorry about this.

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

Re: lldb input issue

[Pedro Giffuni]

El 06/03/2016 a las 15:05, Baptiste Daroussin escribió:

On Sun, Mar 06, 2016 at 10:55:27PM +0300, Roman Bogorodskiy wrote:

   Baptiste Daroussin wrote:


On Sun, Mar 06, 2016 at 07:44:34PM +0300, Roman Bogorodskiy wrote:

Hi,

I'm seeing an issue with lldb: when I start it (without arguments) and
try to type commands, it looks like this:

$  lldb
(lldb) \U+7F68\U+7F65\U+7F6C\U+7F70\U+7F0A

So, basically, I cannot execute any command and cannot even exit from
its shell, only by ctrl-z and killing it.

This happens to me on today's -CURRENT / amd64.

I was wondering if that's an issue with my user's locale, but the
behavior is same for root.

Also, I can see exactly the same behavior with lldb on FreeBSD.

^^^
Oops, that's supposed to be 'freefall'.


Is that some known issue or maybe configuration problem?

Thanks,

Roman Bogorodskiy



Sounds like an issue with libedit, probably due to the latest import of libedit
(just a guess)

It could be. BTW, I've installed lldb38 using pkg and it works fine.


Which is linked to libedit from ports (older that in base) so it seems to prove
that libedit update might be the issue there.


Hmm ... most of the changes were cosmetical. I will take a look though.

Pedro.

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

Re: DDB patches

[Pedro Giffuni]

On 11/20/15 08:54, Dan Partelly wrote:

Hi Pedro,

I think you confuse blackmailing with something much simpler and pragmatic.
One needs to asses how things work in your project for real before investing
too much time.



A template for blackmailing is usually in the form:

"I will do this (usually involving saving the world and/or your
evidently miserable life) but first you will have to do this
(unrelated) thing to see that you are worthy."


Adrian was contemplating the fact that none writes code,  so I had some code at 
the
hand with with I can see how things work around here. You want it, good.
You don't want it, its also good.


I don't know about the (new) libxo discussion, but the ddb thing is 
unrelated to such discussion, and when I first looked at it it was

not in good shape.

 You want to trash it… also good.

Its all the same to me. This process is aimed to  give me an idea , if your 
workflow
works for me.



In my experience it is always easier for new contributors to adapt to
the community than to re-shape it. You can try.. but there will likely
be pain.





you discuss your idea and try to get some consensus in the 
lists/IRC/conferences.


I am not particularly interested in promoting ideas and gathering consensus. I 
am not a
politician. I happen to believe that translating some utilities from the  base 
to libraries
  is a very valuable  addition to the project. Id rather spend time with my 
familty and walk
around the city in nature with my GSD dog than embarking on some twisted 
political
campaign.


We are particularly NOT interested in code where the original contributor will 
walk
away as soon as he/she receives criticism or has plans that do not match ours.


Undeerstandable.



Libxo already went through this process.





Libxo already went through this process.


It did, aint it ? And I seen what kind of “consensus” the xoification of base
caused. Apparently, adopted for no better reason than “someone wrote code” .




There was a GSoC that did a different implementation but libxo was
specifically made for FreeBSD after a long discussion.

That doesn't mean everyone is happy with it or that it is perfect
but it went in through an open process. The process, call it politics
or consensus or community building, is important in any opensource
effort that aims to be sustainable.

These days github makes it pretty easy for anyone to play with their
new ideas to the limit. When I mean you can fork your own BSD, I
mean it. You can experiment on your own without waiting on us to decide:
eventually we may decide to bring it in ...

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

Re: DDB patches

[Pedro Giffuni]

On 11/20/2015 11:28 AM, Dan Partelly wrote:

A template for blackmailing is usually in the form:

"I will do this (usually involving saving the world and/or your
evidently miserable life) but first you will have to do this
(unrelated) thing to see that you are worthy.”


It is interesting how much you dwell on this.


Ugh ... yeah ... I am wondering exactly how I got into this.


 I just told you what reasons
I have to take this path, and that it doesn't include the intent to 
blackmail

anyone. I want to experience the process with already existing code,
before contemplating more in the future.


And that's fine with me ... let's leave it at that.

Have fun, that's what FreeBSD is about,

Pedro.


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

Re: DDB patches

[Pedro Giffuni]

Hello;

> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly  
> ha scritto:
> 
> Hey Pedro,
> 
> some times ago you got some DDB patches from me in which I added relational 
> ops support from it. The patch was a bit clobbered, 
> but last I know you cleaned it up and put it somewhere on freebsd.org (prolly 
> your page) up for review. 
> 

It’s here:
https://people.freebsd.org/~pfg/patches/ddb.patch

I haven’t tested it though.

> Could you or Adrian review the patch set , and if it is OK potentially 
> proceed with a commit ? Or if it is not ok for a commit , please advice on a 
> follow up. 
> 

I am having hardware issues so I won’t be able to do much in a while.
Perhaps you should review it and submit it as a PR.

Pedro.

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

Re: DDB patches

[Pedro Giffuni]

> Il giorno 19/nov/2015, alle ore 04:57, Dan Partelly <dan_parte...@rdsor.ro> 
> ha scritto:
> 
> Hey Pedro,
> 
> Thanks a lot , mate. 
> 
> I’m reluctant to put it up as a PR, since some PR are outstanding for years.  
> 

Well, that’s the way the project works: you cannot really depend on me, or
anyone else keeping old patches around. If you want a record of your
submission bugzilla is the place to keep it. And of course there is no guarantee
anyone will look at it but your chances are much better in bugzilla than
in a mailinglist.



> Adrian,
> 
> since Pedro has issue with hardware, could you try the patch and give a 
> resolution on it ? I reviewed it mentally (no FreeBSD atm machine on which I 
> could actually  patch the kernel)  and apart style changes it looks OK . 
> Physically i can test it again fro a couple of days.

Mental reviews don’t count much: if you are not running FreeBSD and standing
behind your patch the chances of being taking seriously are slim.


>  Getting this reviewed & tested / committed or rejected would give me an idea 
> on how things actually work around here. This is actual code which you can 
> commit or reject not commentaries only like in the thread regarding the 
> binary code reuse.  
> 
> 

I recall you stated the patch was “not ready” when you posted it. I haven’t 
really
done anything to say it is ready. Unless someone else finds time to do real
testing it won’t happen.

Adrian tends to do some particularly valuable contributions to the project. I
would prefer if he spends his time on more important tasks.

> [qute from libxo thread ]
>>> It's all fine and good making technical decisions based on drawings and 
>>> handwaving and philosophizing, but at some point someone has to do
>>> the code.
>>> The reason is simple - someone offered to do the work and push it through. 
>>> This isn't a commercial thing where we get to make project >>decisions and 
>>> allocate resources - the juniper folk came up with a solution that
> 
> Once I see how things work around here once someone wrote  the code,  and get 
> this done one way or another , we could proceed to the libification of 
> ifconfig, should you so desire, and you believe we can all benefit from it. 
> 

Wrong approach. You can’t really blackmail someone into taking your changes.

Things work like this:

- You discuss your idea and try to get some consensus in the 
lists/IRC/conferences.
- You *write* a specific proof of concept and get it discussed.
- You finish your prototype.
- Your work gets rejected until you get something some committer is willing to 
support.
- When there are no objections and a committer feels like it, your work gets 
committed,
 which doesn’t necessarily mean it will stay.
- You are expected to maintain it.

Libxo already went through this process.

We are particularly NOT interested in code where the original contributor will 
walk
away as soon as he/she receives criticism or has plans that do not match ours.
If this is not your ideal workflow … fork your own BSD, a lot of intelligent
people do just that.

Pedro.

> 
> Dan
> 
> 
> 
>> On 19 Nov 2015, at 11:17, Pedro Giffuni <p...@freebsd.org> wrote:
> 
>> 
>> Hello;
>> 
>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly <dan_parte...@rdsor.ro> 
>>> ha scritto:
>>> 
>>> Hey Pedro,
>>> 
>>> some times ago you got some DDB patches from me in which I added relational 
>>> ops support from it. The patch was a bit clobbered, 
>>> but last I know you cleaned it up and put it somewhere on freebsd.org 
>>> (prolly your page) up for review. 
>>> 
>> 
>> It’s here:
>> https://people.freebsd.org/~pfg/patches/ddb.patch
>> 
>> I haven’t tested it though.
>> 
>>> Could you or Adrian review the patch set , and if it is OK potentially 
>>> proceed with a commit ? Or if it is not ok for a commit , please advice on 
>>> a follow up. 
>>> 
>> 
>> I am having hardware issues so I won’t be able to do much in a while.
>> Perhaps you should review it and submit it as a PR.
>> 
>> Pedro.
>> 
> 

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

Re: Need help fixing failing locale tests

[Pedro Giffuni]

FWIW;

While I personally don’t use it, Latin is the official language for the
Holy See [1]. I think it is still taught in schools in Italy for cultural
reasons and because it’s supposed to make easier to learn other
“romance” languages.

It shouldn't hurt to keep it but I have no strong opinion.

Pedro.

[1] https://en.wikipedia.org/wiki/Holy_See
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r288669 breaks ports building with USE_GCC=yes

[Pedro Giffuni]

Hi Gerald;

> Il giorno 08/nov/2015, alle ore 19:00, Gerald Pfeifer  ha 
> scritto:
> 
> On Tue, 13 Oct 2015, Justin Hibbits wrote:
>> As Antoine mentioned, the problem is that lang/gcc does not have this
>> patch.  USE_GCC uses lang/gcc, not lang/gcc48.  So lang/gcc needs to
>> be updated.
> 
> I have (finally) managed to steal the team, kicked off testing,
> and plan on committing the patches already in lang/gcc48 also
> to lang/gcc in the next 24 hours.
> 

Great! We already worked around the issue by disabling stack-protector-strong
for gcc48 though. What looks somewhat strange to me is that lang/gcc is an
independent port when it should just be a link to the current gcc default.

> Thanks for the report and suggestions!
> 

BTW, perhaps it’s time to bump the default gcc to gcc49? ;).

Regards,

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

Re: [CFT] Unicode collation string and reworked locale definitions

[Pedro Giffuni]

Hi Baptiste;

> Il giorno 03/nov/2015, alle ore 02:17, Baptiste Daroussin <b...@freebsd.org> 
> ha scritto:
> 
> On Mon, Nov 02, 2015 at 06:59:15PM -0500, Pedro Giffuni wrote:
>> First of all, congratulations to Baptiste and Marino for succeeding where
>> I failed many moons ago. Also huge thanks to Nexenta and Garret D’Amore
>> for relicensing localedef for us.
>> 
>> Concerning regex;
>> 
>> Gabor@ did a lot of work on libtre but according to him it was not up to the
>> task performancewise. We would also lose features if we move to libtre.
>> 
>> I think our regex code actually has most of what is needed for multibyte
>> already. I have a patch that turns on the functionality but I haven’t found
>> any brave soul that will do the testing:
>> 
>> https://people.freebsd.org/~pfg/patches/regex-multibyte.diff
>> 
> I think it this can be tested once the collation branch is merged.

Absolutely: support for collation is critical and badly needed even without
resolving the regex issues.

> Note that
> dragonfly and musl libc both uses a patched version of libtre for the regex
> implementation.
> 

I am aware. Also note that Gabor had some patches too, in order to make
it usable for bsdgrep:

https://wiki.freebsd.org/Regex

> From my non scientific testing libtre was more reliable and performant then 
> our
> current regex.

According to Gabor, the general performance was better until you take into
account multibyte support where it was clearly inferior to GNU regex.

> Anyway it will be relatively "easy" to test using the AT
> testsuite the reliability and performance of both implementations: ours + your
> patch and patched libtre.
> 


What worries me about libtre is that it lacks important functionality like word
delimiters. We even brought the sysv delimiters to be more compatible with
Solaris and GNU and we can’t back those out now:

https://svnweb.freebsd.org/base?view=revision=268066

Pedro.


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

Re: [CFT] Unicode collation string and reworked locale definitions

[Pedro Giffuni]

Hello;

> Il giorno 03/nov/2015, alle ore 10:52, Wolfgang Jenkner <wjenk...@inode.at> 
> ha scritto:
> 
> On Tue, Nov 03 2015, Pedro Giffuni wrote:
> 
>> What worries me about libtre is that it lacks important functionality like 
>> word
>> delimiters. We even brought the sysv delimiters to be more compatible with
>> Solaris and GNU and we can’t back those out now:
>> 
>> https://svnweb.freebsd.org/base?view=revision=268066
> 
> It supports \< and \> out of the box, cf.
> 
> https://github.com/laurikari/tre/blob/master/doc/tre-syntax.html
> 
> And the darwin patch mentioned above implements [[:<:]] and [[:>:]], see
> 
> http://www.opensource.apple.com/source/Libc/Libc-1044.40.1/regex/TRE/lib/tre-parse.c
> 
> That patch also implements the REG_STARTEND flag for regexec(3), which
> is needed for vi.
> 
> Also, tre provides wchar versions for regcomp(3) and friends, so that
> nvi wouldn't need its own private regex library anymore.

Interesting thanks.

I only looked at it transitorily long ago, I noticed there was a big TODO
list and that the Apple patches were partially copyleft (APSL) so I
didn’t dig into it too much.

It certainly has to be evaluated.

Pedro.

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

Re: [CFT] Unicode collation string and reworked locale definitions

[Pedro Giffuni]

First of all, congratulations to Baptiste and Marino for succeeding where
I failed many moons ago. Also huge thanks to Nexenta and Garret D’Amore
for relicensing localedef for us.

Concerning regex;

Gabor@ did a lot of work on libtre but according to him it was not up to the
task performancewise. We would also lose features if we move to libtre.

I think our regex code actually has most of what is needed for multibyte
already. I have a patch that turns on the functionality but I haven’t found
any brave soul that will do the testing:

https://people.freebsd.org/~pfg/patches/regex-multibyte.diff

Thanks again,

Pedro.

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

Re: r288669 breaks ports building with USE_GCC=yes

[Pedro Giffuni]

Hi;

On 10/12/2015 8:28 PM, Justin Hibbits wrote:

Hi Pedro,

...
This is on powerpc64.  I see the patch has been there for 16 months, 
but for some reason, the /usr/local/bin/gcc48 doesn't contain the 
patch.  I ran `strings` on the binary, and it has the following string:


%{fstack-protector|fstack-protector-all:-lssp_nonshared}

Which, if you examine files/patch-stackprotector-gcc, is the unpatched 
string.


I have no idea why this is the case.



I think it is important to determine if this is a problem from upstream or
a problem in the gcc48 backported patches. Please test building with gcc49
or gcc5.

This is just for curiosity ... I am keeping my fingers away from GCC ;).

Pedro.

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

Re: r288669 breaks ports building with USE_GCC=yes

[Pedro Giffuni]

On 10/13/2015 9:59 AM, Justin Hibbits wrote:

Hi Pedro,

...
As Antoine mentioned, the problem is that lang/gcc does not have this
patch.  USE_GCC uses lang/gcc, not lang/gcc48.  So lang/gcc needs to
be updated.


I see now.

FWIW, I installed gcc48 and then I added USE_GCC= yes to the port.
That worked.

Pedro.

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

Re: r288669 breaks ports building with USE_GCC=yes

[Pedro Giffuni]

Hello;

On 12/10/2015 02:56 p.m., Justin Hibbits wrote:

The default ports gcc for USE_GCC is still 4.8, which does not support
-fstack-protector-strong.  This breaks several ports including (from
my poudriere run): libfpx and qt4-sqlite3-plugin.

- Justin


r288669 only applies to base. It was tested with an exp-run and there 
were no

failures so this is something wrong in your setup.

This said, --stack-protector-strong was being considered for ports, so 
portmgr

should consider changing USE_GCC to 4.9 before that.

regards,

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

Re: r288669 breaks ports building with USE_GCC=yes

[Pedro Giffuni]

Hi again;

On 12/10/2015 03:16 p.m., Pedro Giffuni wrote:

Hello;

On 12/10/2015 02:56 p.m., Justin Hibbits wrote:

The default ports gcc for USE_GCC is still 4.8, which does not support
-fstack-protector-strong.  This breaks several ports including (from
my poudriere run): libfpx and qt4-sqlite3-plugin.

- Justin


r288669 only applies to base. It was tested with an exp-run and there 
were no

failures so this is something wrong in your setup.



Ugh ... now that I remember, we actually used -stack-protector-all for 
the exp-run

(which is supported in pretty much every gcc).

Still, the change should only apply to the base system and not ports, and
-stack-protector-strong appears to have been backported to gcc48
last year (see PR 186852).

cheers,

Pedro.

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

Re: r288669 breaks ports building with USE_GCC=yes

[Pedro Giffuni]

(CCing Gerald as this may involve a g++ bug as well.)

Hello;

On 12/10/2015 03:33 p.m., Justin Hibbits wrote:

Hi Pedro,

On Mon, Oct 12, 2015 at 3:28 PM, Pedro Giffuni <p...@freebsd.org> wrote:

Hi again;

On 12/10/2015 03:16 p.m., Pedro Giffuni wrote:

Hello;

On 12/10/2015 02:56 p.m., Justin Hibbits wrote:

The default ports gcc for USE_GCC is still 4.8, which does not support
-fstack-protector-strong.  This breaks several ports including (from
my poudriere run): libfpx and qt4-sqlite3-plugin.

- Justin


r288669 only applies to base. It was tested with an exp-run and there were
no
failures so this is something wrong in your setup.


Ugh ... now that I remember, we actually used -stack-protector-all for the
exp-run
(which is supported in pretty much every gcc).

Still, the change should only apply to the base system and not ports, and
-stack-protector-strong appears to have been backported to gcc48
last year (see PR 186852).

cheers,

Pedro.


All I can say is building with USE_GCC=yes, I see the following error:

g++48: error: unrecognized command line option '-fstack-protector-strong'

This is using the latest gcc48 in ports (full tree updated yesterday).


Well ... gcc48 carries the stack-protector-strong patches:

https://svnweb.freebsd.org/ports/head/lang/gcc48/files/

I will try to reproduce locally.

Pedro.

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

Re: r288669 breaks ports building with USE_GCC=yes

[Pedro Giffuni]

On 10/12/2015 3:33 PM, Justin Hibbits wrote:

Hi Pedro,

On Mon, Oct 12, 2015 at 3:28 PM, Pedro Giffuni <p...@freebsd.org> wrote:

Hi again;

On 12/10/2015 03:16 p.m., Pedro Giffuni wrote:

Hello;

On 12/10/2015 02:56 p.m., Justin Hibbits wrote:

The default ports gcc for USE_GCC is still 4.8, which does not support
-fstack-protector-strong.  This breaks several ports including (from
my poudriere run): libfpx and qt4-sqlite3-plugin.

- Justin


r288669 only applies to base. It was tested with an exp-run and there were
no
failures so this is something wrong in your setup.


Ugh ... now that I remember, we actually used -stack-protector-all for the
exp-run
(which is supported in pretty much every gcc).

Still, the change should only apply to the base system and not ports, and
-stack-protector-strong appears to have been backported to gcc48
last year (see PR 186852).

cheers,

Pedro.


All I can say is building with USE_GCC=yes, I see the following error:

g++48: error: unrecognized command line option '-fstack-protector-strong'

This is using the latest gcc48 in ports (full tree updated yesterday).


OK, I tested graphics/libfpx on i386-current:

-stack-protector-strong indeed gets pulled in due to some non-orthodox
workarounds in files/Makefile.bsd.

g++48 accepts it just fine and the port compiles.

Is this a platform that has GCC issues, perhaps? It looks like one of those
"unfortunately series of events" that may have to be fixed in the port
and/or gcc48.

Pedro.

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

CFR: a new __unreachable() builtin

[Pedro Giffuni]

Hello;

I am looking at the cdefs in other BSDs hoping to avoid adopting the
same definitions with incompatible names and I noticed NetBSD is using
a new __builtin_unreachable (void) function from gcc 4.6:

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

Apparently it was interesting enough that clang implemented it too so
I created a code review differential for it.

https://reviews.freebsd.org/D2536

I don't want to add new C definitions unless they are going to be used
so feel free to comment on the convenience or not of having it.

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

Re: [RFC] Replace gnu groff in base by heirloom doctools

[Pedro Giffuni]

+1

Great idea.

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

Re: What to do about RCS/OpenRCS

[Pedro Giffuni]

On 05/08/15 15:59, Davide Italiano wrote:

On Fri, May 8, 2015 at 1:34 PM, Pedro Giffuni p...@freebsd.org wrote:

Hi;



I guess I see the following options:

1) Just leave GNU RCS in the tree.

2) Improve OpenRCS so it can be swapped in.

3) Remove RCS dependencies from other parts of the tree (e.g.
etcupdate)
   and import just a /bin/ident binary (perhaps from OpenRCS).

Both 2) and 3) require some work.  I suspect 3) requires less. :)


I honestly don't see a real problem with (1): we do want to replace as much
GNU
software as we can but not at the cost of making our life unnecessarily
difficult.


To be honest I'm not entirely sure what's the real reason of this
crusade. FreeBSD can't import newer version of some components of the
toolchain (e.g. compiler, linker, debugger) and some of them are
slowly (or less slowly) bitrotting. I feel that in that case there's a
real goal which justifies all the headache derived from the
conversion.


Having a consistent license for all the OS has important
advantages. The main principle is that while we are fine
about sharing and having other people re-use our code
we don't really want to have to check with a lawyer before
taking any decision.

Some years ago, this was basically impossible due to the
toolchain, now it seems possible although it certainly
requires more work.


   For GNU RCS, I'm not completely sure there is. I've never
heard anybody complaining about lack of features for RCS or bugs.
My $0.02, I suspect very few people really rely on it and just
complain for the sake of doing it, but I'm not gonna argue on this
further.


I think there are legitimate reasons for having it in base.


That said, unfortunately there's a lot more than doing the conversion
and fixing the code so that the testsuite will pass.
You need to upstream the fixes and so deal with another layer and
other maintainers otherwise the code in base and the one upstream will
diverge.


We do that with GNU code anyways. The latest (GPLv3) version
of RCS has already diverged and is incompatible for some third
party software so we basically ran out of support from upstream.
OpenRCS has it's own share of problems but generally we can work
with the OpenBSD maintainers to get things to improve.

I think I found the issue at hand and the code has an

/* XXX: This is wrong ... */

Which doesn't really get me nearer to a solution but at least
upstream knows where to look. We can wait.


People rely from time to time on bugs of old software (e.g. single vs
double dash options) and are gonna complain.
The testsuite, even if comprehensive, unlikely will cover some corner
cases and suddenly software will start breaking. In other words, a lot
of (unneeded) work for you for a software that just worked fine(TM)
until yesterday.
I'm not gonna stop you from doing this, but I learned the hard way
that it's something that can/should be avoided unless really necessary
(and a better license doesn't seem to be a strong enough reason,
IMHO).



No one (or at least not me) is going to replace GNU RCS with
something of considerable less quality just for the license.

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

Re: What to do about RCS/OpenRCS

[Pedro Giffuni]

Hi;

On 08/05/2015 10:44 a.m., John Baldwin wrote:

On Thursday, May 07, 2015 04:18:38 PM NGie Cooper wrote:

On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni p...@freebsd.org wrote:

Hello;

On 05/07/15 14:56, Lyndon Nerenberg wrote:

On Thu, 7 May 2015, Pedro Giffuni wrote:


Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.


If we can have a build-knob to disable GNU RCS and enable the new one I
will happily twist up the new version and hammer on it.


Yes, that's usually the next step in the process. It is a little bit messy
because
there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
perhaps something else that we don't use).

I really want to check out first if there is some strong opinion against
OpenRCS. Perhaps someone that has used it before and thinks it is a
bad idea.

It looks like there are voices against it, so those have to be addressed
first.

Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs
bits); check with jhb first to make sure that OpenRCS works with
etcupdate.
Cheers!

I think this can be fixed by using diff3 instead of merge, I just haven't
sat down and figured out the correct incantation.

That said, I think that having a not-quite-working rcs (OpenRCS) in base
is worse than having no rcs.  If OpenRCS is improved as per Xin's notes
then just switching over is probably the path of least resistance.


To be honest, I just want to have options, and unfortunately OpenRCS is 
not one

at this time.


I guess I see the following options:

   1) Just leave GNU RCS in the tree.

   2) Improve OpenRCS so it can be swapped in.

   3) Remove RCS dependencies from other parts of the tree (e.g. etcupdate)
  and import just a /bin/ident binary (perhaps from OpenRCS).

Both 2) and 3) require some work.  I suspect 3) requires less. :)


I honestly don't see a real problem with (1): we do want to replace as 
much GNU
software as we can but not at the cost of making our life unnecessarily 
difficult.


No. 2 is something that has to be reported/submitted upstream before we can
adopt it. We do that with major components we take from other places and
it is the proven, safe way to do it.

No. 3 is something that seems necessary in any case: apparently the 
WITHOUT_RCS

option has been always broken.

I am currently reporting (2), but doing the /bin/ident part of (3) looks 
easy enough

that I may do it at a later time ;).

Pedro.

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

What to do about RCS/OpenRCS

[Pedro Giffuni]

Hello;

Some of you might recall that right before 10.0-Release there was
a painful attempt to remove GNU RCS from the base system.

From my point of view, the lessons learned from that were:

-A lot more people than you might think find it useful to have
a small version control system for thing like the files in /etc.
-Just removing features without a discussion is not wise.
-IMHO, people wondering about the bloat in the OS should
focus on other bigger VCS we carry, namely svn.

For all I know, it looks like OpenRCS is the most viable option and can
completely replace the old RCS we have in base.

In order to avoid painful surprises late in the release cycle, I started
the process to consider OpenRCS by bringing it to the vendor area
(OpenBSD/usr.bin/rcs/*). I also have an initial patch[1] so that it builds
on FreeBSD.

Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.

All in all, it looks like whatever is done about RCS it may be controversial
so I am opening the discussion in the hope that someone else will
take the lead and do something about it much ahead of 11-Release.

Regards,

Pedro.

[1] Follow the link in:
https://wiki.freebsd.org/GPLinBase
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: What to do about RCS/OpenRCS

[Pedro Giffuni]

 Il giorno 08/mag/2015, alle ore 00:26, Doug Brewer brewer.d...@gmail.com ha 
 scritto:
 
 On Thu, May 07, 2015 at 04:18:38PM -0700, NGie Cooper wrote: 
  
  On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni p...@freebsd.org 
  mailto:p...@freebsd.org wrote: 
   Hello; 
   
   On 05/07/15 14:56, Lyndon Nerenberg wrote: 
   
   On Thu, 7 May 2015, Pedro Giffuni wrote: 
   
   Unfortunately I don't use RCS enough (it looks like I should though) so 
   I am not in a good position to take the next step and deal with any 
   fallout it may produce. 
   
   
   If we can have a build-knob to disable GNU RCS and enable the new one I 
   will happily twist up the new version and hammer on it. 
   
   
   Yes, that's usually the next step in the process. It is a little bit 
   messy 
   because 
   there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and 
   perhaps something else that we don't use). 
  
   I really want to check out first if there is some strong opinion against 
   OpenRCS. Perhaps someone that has used it before and thinks it is a 
   bad idea. 
   
   It looks like there are voices against it, so those have to be addressed 
   first. 
  
  Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs 
  bits); check with jhb first to make sure that OpenRCS works with 
  etcupdate. 
 
 Confirmed.  Pedro, are you also willing to fix fallout as Xin Li pointed out? 
 If not, please revert, thanks.


I haven’t committed anything to base so there’s nothing to revert (?).

Pedro.
 

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

Re: What to do about RCS/OpenRCS

[Pedro Giffuni]

Hello;

On 05/07/15 14:56, Lyndon Nerenberg wrote:

On Thu, 7 May 2015, Pedro Giffuni wrote:


Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.


If we can have a build-knob to disable GNU RCS and enable the new one 
I will happily twist up the new version and hammer on it.




Yes, that's usually the next step in the process. It is a little bit 
messy because

there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
perhaps something else that we don't use).

I really want to check out first if there is some strong opinion against
OpenRCS. Perhaps someone that has used it before and thinks it is a
bad idea.

It looks like there are voices against it, so those have to be addressed 
first.


Pedro.

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

Re: [Heads up] : You may need to update your gcc ports.

[Pedro Giffuni]

On 04/21/15 12:43, Bryan Drewery wrote:

On 4/5/2015 2:10 PM, Pedro Giffuni wrote:

I don't know if someone is keeping up-to-date packages for -current
but I will hold the headers update for a while to help such cases.


We build head packages _at least_ once a week. Currently we always
update the system from head and force rebuild all packages. It would
catch your case fine and rebuild.


Excellent! I will be bringing a couple of more attributes that are useful.

FWIW, as hint for those wanting to avoid rebuilding/upgrading
packages:

As a stop gap measure you could use run the equivalent of
  $PREFIX/libexec/gcc/i386-unknown-freebsd10.1/5.0.0/install-tools/fixinc.sh


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

[Heads up] : You may need to update your gcc ports.

[Pedro Giffuni]

Hello;

I was going to add this to the UPDATING file but this file is not meant
for changes affecting ports so here it goes instead:

20150415:
Our libc headers are starting to use gcc-style attributes to hint
the compiler about probable optimizations or errors. Unfortunately
gcc from ports does some bogus fixing of our system headers and
carries them internally so you may have to update your gcc ports so
that they grab the complete system headers and particularly the
cdefs.h file changes from r280801.


This basically affects only -current users that haven't rebuilt their gcc
ports in a week.

Sorry for the inconvenience,

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

Re: [Heads up] : You may need to update your gcc ports.

[Pedro Giffuni]

On 04/05/15 13:00, Aryeh Friedman wrote:

On Sun, Apr 5, 2015 at 1:39 PM, Pedro Giffuni p...@freebsd.org wrote:

Hello;

I was going to add this to the UPDATING file but this file is not meant
for changes affecting ports so here it goes instead:

20150415:
 Our libc headers are starting to use gcc-style attributes to hint
 the compiler about probable optimizations or errors. Unfortunately
 gcc from ports does some bogus fixing of our system headers and
 carries them internally so you may have to update your gcc ports so
 that they grab the complete system headers and particularly the
 cdefs.h file changes from r280801.


This basically affects only -current users that haven't rebuilt their gcc
ports in a week.

Sorry for the inconvenience,

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


Is there anyway to make the compile of GCC go faster I am
currently compiling lang/gcc on a VM and it has been munching away for
*18 HOURS* on a 4 core machine with 8 GB of RAM


I don't know if someone is keeping up-to-date packages for -current
but I will hold the headers update for a while to help such cases.

Thanks for the feedback,

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

[CFT] Remove NIS

[Pedro Giffuni]

Eh ...

No, I am not planning to remove NIS, au contraire, but now
that I got your attention ...

We have a couple of long standing (2001) NIS-related issues
with patches and I am willing to do something about it.
Please test:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=26486
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=31981

Thanks in advance,

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

Re: Call for testing: elftoolchain tools

[Pedro Giffuni]

FWIW,

A nice testing procedure, or even a pet project if generalized, would be 
to test the tools with a fuzzer like security/afl. Apparently the GNU 
binutils and Fedora elfutils developers having doing that [1].


Regards,

Pedro.

[1] 
https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-December/004346.html

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

NPF (was Re: Future of pf / firewall in FreeBSD ? - does it have one ?)

[Pedro Giffuni]

FWIW, and while I still wonder why we need three packet filters …

There is yet another firewall implementation in NetBSD:

http://www.netbsd.org/~rmind/npf/

It seems to be more portable, it is thought with SMP-friendliness in mind and 
according to a EuroBSDCon talk ports for FreeBSD and Illumos were being 
considered.

Good to have more options … I think.

Pedro. 


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

CFR - fflush() behaviour change

[Pedro Giffuni]

Hi;

Out of curiosity I took a peek at Apple's libc and generated some diffs 
against

the libc in FreeBSD's 8. Most of the changes are not relevant to FreeBSD
anymore as we have grown alternative implementations for things like 
xlocale.

Nevertheless, there are still some small things to look at.

In the hope of avoiding surprises, and because I wanted to try out 
phabricator,

I have this change for review:

https://phabric.freebsd.org/D440

While the change was inspired on Apple's patch, it was cleaned up with 
help from
Bruce Evans. I did some basic testing but it can still use some more 
review/testing.


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

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

[Pedro Giffuni]

(Dropped the cross-posting, which *is* frowned upon)

While I do very much appreciate this work being done, and I agree we should 
have it in the tree, I would really prefer it opt-in rather opt-out, at least 
initially.

I know this may very well be the subject of a bikeshed of historical 
proportions but:

1) Understand this may break some applications (?).

2) It is yet undetermined what the performance effect will be.

I find it very neat that it can be enabled for jails though.

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

Re: svn 260311 breaks gcc builds on releng9 ?

[Pedro Giffuni]

Hello Luigi;

On 17.01.2014 15:18, Luigi Rizzo wrote:

Hi,
I am seeing an odd problem which seems to be triggered by svn260311

I have two machines running snapshots of stable/9 from last fall
(one 255898 sep.26, the other 258126 nov.14). All is amd64

Build a recent head (260311 and newer) with gcc fails on the sep.26 machine:

...
19:51:22 === gnu/usr.bin/cc/cc1plus (all)
PROG CC   
/media/bsd10/usr/home/luigi/FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/main.c
...
PROG CC   
/media/bsd10/usr/home/luigi/FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/except.c
parser.o: In function `cp_parser_objc_tentative_protocol_refs_opt':
parser.c:(.text+0x14665): undefined reference to 
`cp_objc_protocol_id_list'
*** [cc1plus-dummy] Error code 1
1 error

but works on the newer one.

svn 260310 builds on both.

I am a bit unclear on what is going on because the missing symbol
(cp_objc_protocol_id_list) only appears in the source file parser.c
and in a ChangeLog.apple file, so maybe it is generated and
the actual failure is at some earlier stage.

Thanks for the report.

Of course gcc can also have bugs but it would look like you may not be 
doing a clean build or that some how object code from two different 
builds got mixed up.


JIC, the cp_obj_protocol_id_list stuff is obviously objc stuff that we 
don't need at all and that crept in along with other changes from Apple 
so I will remove it to see if it helps somehow.


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

Re: svn 260311 breaks gcc builds on releng9 ?

[Pedro Giffuni]

On 17.01.2014 16:07, Luigi Rizzo wrote:




On Fri, Jan 17, 2014 at 12:50 PM, Pedro Giffuni p...@freebsd.org 
mailto:p...@freebsd.org wrote:


Hello Luigi;


On 17.01.2014 15:18, Luigi Rizzo wrote:

Hi,
I am seeing an odd problem which seems to be triggered by
svn260311

I have two machines running snapshots of stable/9 from last fall
(one 255898 sep.26, the other 258126 nov.14). All is amd64

Build a recent head (260311 and newer) with gcc fails on the
sep.26 machine:

...
19:51:22 === gnu/usr.bin/cc/cc1plus (all)
PROG CC  
/media/bsd10/usr/home/luigi/FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/main.c

...
PROG CC  
/media/bsd10/usr/home/luigi/FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/except.c

parser.o: In function
`cp_parser_objc_tentative_protocol_refs_opt':
parser.c:(.text+0x14665): undefined reference to
`cp_objc_protocol_id_list'
*** [cc1plus-dummy] Error code 1
1 error

but works on the newer one.

svn 260310 builds on both.

I am a bit unclear on what is going on because the missing symbol
(cp_objc_protocol_id_list) only appears in the source file
parser.c
and in a ChangeLog.apple file, so maybe it is generated and
the actual failure is at some earlier stage.

Thanks for the report.

Of course gcc can also have bugs but it would look like you may
not be doing a clean build or that some how object code from two
different builds got mixed up.


i thought so too, but i am building in a completely new dir
and i retried some 10 times rm -rf on the output dir,
resyncing the repo and checking diffs, etc.

Also it is very suspicious that going back to 260310 makes
the problem disappear, and 260311 brings it back in.

Anyways, it is very confusing indeed.



JIC, the cp_obj_protocol_id_list stuff is obviously objc stuff
that we don't need at all and that crept in along with other
changes from Apple so I will remove it to see if it helps somehow.


ok thanks.
let me know if you want me to test a patch before committing,
since I have a way to reproduce the error (i am not upgrading
the offending system on purpose).



The Apple change was incomplete so I guess the compiler in head is not 
being strict enough. I removed the dead code and rebuilt.

Should be fixed as r260831.

Thank you for the report!

Pedro.


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

Re: gcc in -current broken

[Pedro Giffuni]

On 23.11.2013 22:23, Michael Butler wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

After SVN r258501, I get ..

=== gnu/usr.bin/cc/cc1 (all)
- --- cc1-dummy ---
cc -O2 -pipe -DGCCVER=\4.2\ -DIN_GCC -DHAVE_CONFIG_H
- -DPREFIX=\/usr/obj/usr/src/tmp/usr\
- -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools
- -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools
- -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc
- -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config
- -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include
- -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include
- -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber
- -std=gnu89   -I/usr/obj/usr/src/tmp/legacy/usr/include  -static
- -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o
c-lang.o
/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a
/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a
/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a
/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a
- -legacy
/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o):
In function `preprocess_file':
c-ppoutput.c:(.text+0xc75): undefined reference to
`_cpp_preprocess_dir_only'
/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o):
In function `compute_may_aliases':
tree-ssa-alias.c:(.text+0x64cb): undefined reference to
`strict_aliasing_warning_backend'
*** [cc1-dummy] Error code 1


Ugh... can't believe it 

I found the issue.. just one missing commit in gnu/../../libcpp.
Will be fixed shortly.

Thanks!

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

Re: [head tinderbox] failure on amd64/amd64

[Pedro Giffuni]

On 14.11.2013 13:42, Sean Bruno wrote:

[...]
c++  -O2 -pipe -Qunused-arguments -fstack-protector -Wsystem-headers -Werror 
-Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter 
-Wno-parentheses -Wno-c++11-extensions 
-I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c 
/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc
/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: 
format string is empty [-Werror,-Wformat-zero-length]
   , option.get_size_type());
   ^~
/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: 
format string is empty [-Werror,-Wformat-zero-length]
   , option.get_size_type());

Theoretically fixed at svn R258139.

sean


Thank you!

FWIW, I had a similar fix but was waiting for confirmation before 
committing.


Regards,

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

Re: bsd patch regression?

[Pedro Giffuni]

Hi Sean;

El 27/08/2013 5:58 p. m., Sean Bruno escribió:

Colin generated a patch for xen things that does some pretty typical
behavior.  bsdpatch really didn't handle it well and rejected some
things and flat out refused to create sys/modules/xenhvm/Makefile for
me.

http://lists.freebsd.org/pipermail/freebsd-xen/2013-August/001697.html

When applying this patch with gnupatch I get:
http://people.freebsd.org/~sbruno/gnupatch.txt


When applying this patch with bsdpatch I get:
http://people.freebsd.org/~sbruno/bsdpatch.txt



I note that you are using GNU patch from the ports tree.

It would appear that both utilities reject the patches for:
sys/amd64/conf/XENHVM
sys/i386/conf/XENHVM

bsdpatch is uglily more verbose and handles the rejected patches much 
less gracefully but it seems like gpatch also has issues with the same 
patches.


I am not sure we can call this a regression: please note that bsd patch
is meant to replace the ancient GNU patch that we had in the tree (it's
still there under the name gnupatch). We ran an exp-run on ports and
there was only a small regression related to the patch level which is a
little stricter in BSD patch.



Any ideas here?



Not very helpful but I suggest using svn patch when possible. :(

Pedro.


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

Re: [Heads up] BSD-licensed patch becoming the default RSN.

[Pedro Giffuni]

On 26.07.2013 23:11, Jan Beich wrote:

Pedro Giffuni writes:


Now, just some food for thought, but if you are unsure your patch
applies cleanly, why would you choose to use the -s (silent) option?

Because by default patch(1) is overly verbose. At first, I'm only
interested if a patch applies cleanly, then what files fail to apply.
To fix the patch I just repeat over edit a hunk (or two) and confirm
patch(1) no longer rejects it.

With -Cs giving up is easy at any time. One may not care about
a failed hunk in a man page or prefer to edit a patch as the whole
instead of on per-file (.rej file) basis.


I would tend to do -Cs just to see if it applies cleanly or not and
if there is a failure then do -C to see the failure. Actually I always
use -C from the start.

In any case, I find it reasonable to want to preserve the GNU patch
behaviour.  The code is rather simple so I would encourage other
interested people to look at it, or I will look at it at a later time.

Pedro.


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

Re: [Heads up] BSD-licensed patch becoming the default RSN.

[Pedro Giffuni]

OK;
On further revision ...

On 26.07.2013 20:01, Jan Beich wrote:

bsdpatch doesn't list files of the failed hunks with -C and -s option.
This may be less convenient if you edit a patch directly rather than
regen it after polluting the tree.

$ patch -CEfsp0 -i /path/to/varsym.diff
1 out of 1 hunks failed
1 out of 2 hunks failed
2 out of 2 hunks failed
1 out of 5 hunks failed
1 out of 1 hunks failed
1 out of 1 hunks failed
1 out of 1 hunks failed
zsh: exit 1

$ gnupatch -CEfsp0 -i /path/to/varsym.diff
1 out of 1 hunks failed--saving rejects to contrib/openbsm/etc/audit_event.rej
1 out of 2 hunks failed--saving rejects to lib/libc/sys/Makefile.inc.rej
2 out of 2 hunks failed--saving rejects to 
sys/security/audit/audit_private.h.rej
1 out of 5 hunks failed--saving rejects to sys/security/audit/audit.h.rej
1 out of 1 hunks failed--saving rejects to sys/bsm/audit_kevents.h.rej
1 out of 1 hunks failed--saving rejects to sys/kern/syscalls.master.rej
1 out of 1 hunks failed--saving rejects to sys/sys/priv.h.rej
zsh: exit 8

The change came from OpenBSD, which took it from DragonFlyBSD:

http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/patch/patch.c.diff?r1=1.49;r2=1.50

It was merged as part of some OpenBSD syncing in patch.c
http://svnweb.freebsd.org/base?view=revisionrevision=246091

Cheers,

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

[Heads up] BSD-licensed patch becoming the default RSN.

[Pedro Giffuni]

Hello;

After an exp-run it was found that only two ports presented regressions
with the new BSD-licensed patch derived from Open/DragonFly BSD.

The issue was related to some patch level detection the previous
GNU patch has and the new patch lacks. Otherwise both versions
are basically equivalent. Both ports affected have been fixed to
use the specific patch levels so we can throw the switch now.

The new patch has been rather well tested, and (a derivative) is
already the default on the other BSDs, but you never know so
a new WITH_GNU_PATCH option will be available to aid the
transition.

Enjoy!

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

Re: [Heads up] BSD-licensed patch becoming the default RSN.

[Pedro Giffuni]

Hi Jan;

El 26/07/2013 8:01 p. m., Jan Beich escribió:

bsdpatch doesn't list files of the failed hunks with -C and -s option.
This may be less convenient if you edit a patch directly rather than
regen it after polluting the tree.

$ patch -CEfsp0 -i /path/to/varsym.diff
1 out of 1 hunks failed
1 out of 2 hunks failed
2 out of 2 hunks failed
1 out of 5 hunks failed
1 out of 1 hunks failed
1 out of 1 hunks failed
1 out of 1 hunks failed
zsh: exit 1

$ gnupatch -CEfsp0 -i /path/to/varsym.diff
1 out of 1 hunks failed--saving rejects to contrib/openbsm/etc/audit_event.rej
1 out of 2 hunks failed--saving rejects to lib/libc/sys/Makefile.inc.rej
2 out of 2 hunks failed--saving rejects to 
sys/security/audit/audit_private.h.rej
1 out of 5 hunks failed--saving rejects to sys/security/audit/audit.h.rej
1 out of 1 hunks failed--saving rejects to sys/bsm/audit_kevents.h.rej
1 out of 1 hunks failed--saving rejects to sys/kern/syscalls.master.rej
1 out of 1 hunks failed--saving rejects to sys/sys/priv.h.rej
zsh: exit 8



Very interesting, thank you!

Now, just some food for thought, but if you are unsure your patch
applies cleanly, why would you choose to use the -s (silent) option?
It would seem to me that some people may want the -s option to be truly 
silent (those paths may be long) and since those .rej files are not

really being created it is consistent not to list them.

FWIW, one thing that I have been thinking is that it may make sense to
update gnupatch to the latest GPLv2 version and decide later when to
drop it.

Regards,

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

Re: poudriere problems with fuse?

[Pedro Giffuni]

Hi;

El 24/07/2013 1:22 p. m., Adrian Chadd escribió:

Hi Pedro,

Bapt tells me that there are FUSE issues in the most recent -HEAD and
it's stopping poudriere from running.

What's the story here?



I reverted all my birthtime changes, the remaining change is only a 
header update from upstream that helps things get in line with the

header included in the port.

I have no idea what may be broken but it predates my short
involvement with fuse.

Sorry that I have no responsible answer :(.

Pedro.

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

Re: poudriere problems with fuse?

[Pedro Giffuni]

On 24.07.2013 13:34, Baptiste Daroussin wrote:

On Wed, Jul 24, 2013 at 11:22:57AM -0700, Adrian Chadd wrote:

Hi Pedro,

Bapt tells me that there are FUSE issues in the most recent -HEAD and
it's stopping poudriere from running.

Nah poudriere does not use yet fuse :)

What's the story here?


I was about to mail you :)

It is broken since r248084 apparently the update on the fuse_kernel.h you did is
not in sync with fusefs-libs, resulting in no filesystem to properly work.

Do you have any insight on the reason of the changes? and I should look at?


The change came from upstream.  Does it help to revert it all?

Another option could be to teach the port to use the kernel header
but it doesn't look like that would work either :(.

Pedro.


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

Re: poudriere problems with fuse?

[Pedro Giffuni]

On 24.07.2013 14:07, Baptiste Daroussin wrote:

On Wed, Jul 24, 2013 at 01:55:21PM -0500, Pedro Giffuni wrote:

On 24.07.2013 13:34, Baptiste Daroussin wrote:

On Wed, Jul 24, 2013 at 11:22:57AM -0700, Adrian Chadd wrote:

Hi Pedro,

Bapt tells me that there are FUSE issues in the most recent -HEAD and
it's stopping poudriere from running.

Nah poudriere does not use yet fuse :)

What's the story here?


I was about to mail you :)

It is broken since r248084 apparently the update on the fuse_kernel.h you did is
not in sync with fusefs-libs, resulting in no filesystem to properly work.

Do you have any insight on the reason of the changes? and I should look at?

The change came from upstream.  Does it help to revert it all?

Another option could be to teach the port to use the kernel header
but it doesn't look like that would work either :(.

Yes reverting will help r248084 is the last known working revision.


I am perfectly OK with reverting, of course.

Updating the header should be done with modification on the code itself to
implement the missing bits. has some things has changed, I have seen some
interesting things https://github.com/bfleischer/fuse-macosx I might probably
have a look at it later.


I see, there are least two macosx fuse forks but it appears they
were merged into osxfuse.

Things become rather confusing since we are using the linux fuse-libs
with yet another header and NetBSD has a completely different
implementation using puffs with librefuse/libperfuse.

For now let's just fix things :).

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

Re: FUSE not work.

[Pedro Giffuni]

On 24.07.2013 13:49, Baptiste Daroussin wrote:

...

Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to that version
and it will work, I'm investigating.

What I fix is the umount umounting all the FS.

regards,
Bapt

Forgot to say r248084 is the last working revision.


Sorry for the delay,

OK, I reverted the kernel header update in revision 253619
hopefully this will save everyone affected some pain ...


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

Re: FUSE not work.

[Pedro Giffuni]

On 19.07.2013 23:42, Kevin Oberman wrote:

...


fuse is at least partly broken in -current. I discovered that if you 
mount two devices that use fuse, when you umount any of them, ll are 
marked as not mounted and disappear from df(1) or mount(8) output, but 
only one is actually cleanly unmounted and, if it has been written to, 
will likely be corrupt. This applies to at least ntfs.


ATM no one is supporting fuse in current, so this may become a serious 
issue before long.


I reverted my incompatible changes and will try to see if upstream wants
to adopt something compatible for birthtime support.

I do agree that fuse needs a lot of work. I wonder if NetBSD's 
puffs/libperfuse

is any better.

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

Re: FUSE not work.

[Pedro Giffuni]

Hello;

The internal data structures in the FUSE kernel module have been
updated to be more compatible with MacFUSE and the linux FUSE.

This basically measn you have to rebuild your fuse modules
(including NTFS).

We should not really update the FUSE_KERNEL_MINOR_VERSION yet.
I will add a note to UPDATING.

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

Re: FUSE not work.

[Pedro Giffuni]

(re-posting since the original response didn't make it through)

On 19.07.2013 10:29, Alexander Panyushkin wrote:

19.07.2013 17:36, Pedro Giffuni пишет:

Hello;

The internal data structures in the FUSE kernel module have been
updated to be more compatible with MacFUSE and the linux FUSE.

This basically means you have to rebuild your fuse modules
(including NTFS).

We should not really update the FUSE_KERNEL_MINOR_VERSION yet.
I will add a note to UPDATING.

Pedro.




Unfortunately the port is not  build in FreeBSD 10


=== Starting build for sysutils/fusefs-kmod ===



fusefs-kmod is not needed on -current. I meant you have to rebuild
and reinstall fusefs-* ; in particular fusesfs-libs and ntfs.

Since this is a ports issue I will not update the UPDATING file.

Developers that need to know should use  __FreeBSD_version
138 as a reference.


Pedro.

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

Re: FUSE not work.

[Pedro Giffuni]

On 19.07.2013 12:07, Alexander Panyushkin wrote:

19.07.2013 19:42, Pedro Giffuni пишет:

(re-posting since the original response didn't make it through)

On 19.07.2013 10:29, Alexander Panyushkin wrote:

19.07.2013 17:36, Pedro Giffuni пишет:

Hello;

The internal data structures in the FUSE kernel module have been
updated to be more compatible with MacFUSE and the linux FUSE.

This basically means you have to rebuild your fuse modules
(including NTFS).

We should not really update the FUSE_KERNEL_MINOR_VERSION yet.
I will add a note to UPDATING.

Pedro.




Unfortunately the port is not  build in FreeBSD 10


=== Starting build for sysutils/fusefs-kmod ===



fusefs-kmod is not needed on -current. I meant you have to rebuild
and reinstall fusefs-* ; in particular fusesfs-libs and ntfs.

Since this is a ports issue I will not update the UPDATING file.

Developers that need to know should use  __FreeBSD_version
138 as a reference.



I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no 
effect.


sysctl kern.osreldate
kern.osreldate: 137

ntfs-3g /dev/ad10s1 /mnt/ntfs_0
mount
...
/dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous)

ls -la /mnt/ntfs_0
unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053
getattr /
   unique: 18, success, outsize: 112
fuse: writing device: Invalid argument
ls: /mnt/ntfs_0: Input/output error



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

Re: (follow-up) Stale NFS file handle for NFS exported UFS from r252435

[Pedro Giffuni]

Hello guys;

Thank for finding this, however ...

On 10.07.2013 08:53, Claude Buisson wrote:

On 07/10/2013 14:32, Claude Buisson wrote:

Hi,

Upgrading a CURRENT amd64 pure UFS system (watson) from r249744 to 
r253007, I

have hit the following:

claude@zorglub$ mount_nfs watson:/home /mnt
claude@zorglub$ /bin/ls /mnt/
claude  doc.old ports.old   sysref
distfiles   obj portsperso  xorg-dev
doc ports   src xtrafiles
claude@zorglub$ /bin/ls /mnt/claude
ls: /mnt/claude: Stale NFS file handle
claude@zorglub$ /bin/ls /mnt/ports.old
CHANGES UPDATINGdns multimedia textproc
COPYRIGHT   accessibility   editors net www
...

some directories may be listed, for the others the result is Stale 
NFS file handle


This exists for a 8.4-STABLE client system, for a 9.1-STABLE client 
system, and

also with a local mount (localhost) on the server system itself.

I checked with memsticks of official snapshots (to eliminate the 
influence of

local patches and customized kernels), with the result:

FreeBSD-10.0-CURRENT-amd64-20130630-r252387-memstick is not affected

FreeBSD-10.0-CURRENT-amd64-20130707-r252887-memstick is affected

Doing a binary search on the kernel source (without any patch) lead 
to the

culprit:

--
Author: pfg
Date: Mon Jul  1 03:00:15 2013
New Revision: 252435
URL: http://svnweb.freebsd.org/changeset/base/252435

Log:
Change i_gen in UFS to an unsigned type.

In UFS, i_gen is a random generated value and there is not way for
it to be negative. Actually, the value of i_gen is just used to
match bit patterns and it is of not consequence if the values are
signed or not.

Following other filesystems, set it to unsigned and use it as such,

Discussed by:mckusick
Reviewed by:mckusick (previous version)
MFC after:4 weeks

Modified:
head/sys/ufs/ffs/ffs_vfsops.c
head/sys/ufs/ufs/dinode.h
head/sys/ufs/ufs/inode.h
head/sys/ufs/ufs/ufs_extattr.c
--

which is entirely UFS (not NFS) related.



Reverting 252435 + 252437 and rebuilding the kernel seems to give back 
a working

system.

Claude Buisson



While I understand this change caused the issue and I am willing to 
revert it,
I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I 
presume

glusterfs) have unsigned i_gen.

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

Re: (follow-up) Stale NFS file handle for NFS exported UFS from r252435

[Pedro Giffuni]

On 10.07.2013 10:16, Claude Buisson wrote:

On 07/10/2013 17:05, Pedro Giffuni wrote:

Hello guys;

Thank for finding this, however ...



snip



While I understand this change caused the issue and I am willing to
revert it,
I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I
presume
glusterfs) have unsigned i_gen.



I have the same thinking (and was rather astonished by the success of 
my try at
reverting it): there is something somewhere in the NFS code which have 
not been

synced with the UFS change.

It is the reason I CC'ed rmacklem@



There is an ongoing port of glusterfs, and glusterfs is known to use
both NFS and fuse so I think we would have this problem sooner
or later.

I hope it's easy to find: I did a search for i_gen with opengrok before
making this change and couldn't find any user. Fortunately I had no
plans to merge the change for 9.2.

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

Re: (follow-up) Stale NFS file handle for NFS exported UFS from r252435

[Pedro Giffuni]

On 10.07.2013 10:16, Claude Buisson wrote:

On 07/10/2013 17:05, Pedro Giffuni wrote:

Hello guys;

Thank for finding this, however ...



snip



While I understand this change caused the issue and I am willing to
revert it,
I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I
presume
glusterfs) have unsigned i_gen.



I have the same thinking (and was rather astonished by the success of 
my try at
reverting it): there is something somewhere in the NFS code which have 
not been

synced with the UFS change.

It is the reason I CC'ed rmacklem@


Pedro.



Claude Buisson


I found a missing type change. Can you try the attached patch?

Cheers,

Pedro.
Index: sys/ufs/ufs/inode.h
===
--- sys/ufs/ufs/inode.h (revision 253159)
+++ sys/ufs/ufs/inode.h (working copy)
@@ -180,7 +180,7 @@
u_int16_t ufid_len; /* Length of structure. */
u_int16_t ufid_pad; /* Force 32-bit alignment. */
uint32_t  ufid_ino; /* File number (ino). */
-   int32_t   ufid_gen; /* Generation number. */
+   uint32_t  ufid_gen; /* Generation number. */
 };
 #endif /* _KERNEL */
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Problem loading a kld on i386

[Pedro Giffuni]

Hello;

I just built a recent kernel in an i386 virtualbox VM and when trying
to load the ext2fs module I get this:

#kldload ext2fs
link_elf_lookup_symbol: corrupt symbol table
link_elf_lookup_symbol: corrupt symbol table
link_elf: symbol __moddi3 undefined
kldload: can't load ext2fs: No such file or directory

I rebuilt the kernel a couple of times with and without optimizations.
It's probably just a pilot error, but JIC I wanted to see if someone
knows what is wrong.

thanks in advance,

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

Re: DTrace gone quiet?

[Pedro Giffuni]

Hello;

Yes, I was indeed going to post that the culprit is this change from Illumos:

3026 libdtrace should set LD_NOLAZYLOAD=1 to help the pid provider


It is an upstream hack for the Solaris ld that they bundled among
many changes.

I will see how to revert only the part that gives problems.

Sorry for the inconvenience,

Pedro.




 Da: Mark Johnston 
...

Reverting r249367 and rebuilding libdtrace+the kernel fixes the problem
for me.

-Mark



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

Re: DTrace gone quiet?

[Pedro Giffuni]

On 04/16/13 15:54, Mark Johnston wrote:

On Tue, Apr 16, 2013 at 12:57:08PM -0700, Navdeep Parhar wrote:

I just upgraded my kernel and userspace to head (r249552) and I notice
that DTrace doesn't output anything until I hit ctrl-c.  All previous
hits on the probe appear lost.  For example:

# dtrace -n 'fbt::ether_output:entry'
dtrace: description 'fbt::ether_output:entry' matched 1 probe

(No output here.  I waited a long time before the ctrl-c and I know the
system is actively transmitting and receiving Ethernet traffic).

^C
CPU IDFUNCTION:NAME
   9  29354   ether_output:entry
   8  29354   ether_output:entry
   8  29354   ether_output:entry
   8  29354   ether_output:entry


Can anyone confirm or contradict this on a recent HEAD (around r249552
in my case)?

Reverting r249367 and rebuilding libdtrace+the kernel fixes the problem
for me.

-Mark

Thanks for pointing culprit !

Unfortunately upstream merged many changes in the same commit
so it's difficult to separate the specific change that is causing this.

I reverted all the change in r249573.

Regards,

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

Re: Please test upcoming DTrace port mod_usdt for apache22

[Pedro Giffuni]

On 04/16/13 15:55, Olli Hauer wrote:

Hi,

I've created together with Pedro Giffuni (pfg@) a new
DTrace apache port (www/mod_usdt).
We are interested in getting some more test results from
DTrace and apache users.

A complete description is here:
http://dtrace.org/blogs/dap/2011/12/13/usdt-providers-redux/

shar file for mod_usdt can be found here:
http://people.freebsd.org/~ohauer/shar/mod_usdt_2013051601.shar

Thanks,
olli


Most of the work was done by Olli, I only added a -lelf
to linking stage.

We did find out that we still lack some important
providers in FreeBSD so some of the examples
won't work but it should still be useful.

BTW, stuff like the NFS provider should not be difficult
to finish but given that our implementation is not
related to the Solaris one it does require at least
adding probes to our code.
Just something to investigate in the future ;).

Cheers,

Pedro.

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

Dtrace status - material for someone's TODO list.

[Pedro Giffuni]

Hello;

Last year I did an attempt to merge some of the changes from illumos'
Dtrace into FreeBSD. I don't use Dtrace a lot, so this was done mainly
for fun.

In general, merging changes from Illumos was pretty straightforward;
just a matter of readapting the paths to match our layout.

I was able to merge some basic stuff (semilog plots) and fixes but we
are at a point now where they are building upon their own developments
and we need to merge their stuff in the same order they did. Some of
their changes (KVM and zones) we can just ignore.

As of lately, I got stuck because our userland support is different
from the Solaris stuff. The conflicts I am seeing now are not easy
for my (non-)level of inner Dtrace-foo and I am not working more
on this so I will post the links to the patches in the hope that someone
will pick up where I left:

- 1368 enablings on defunct providers prevent providers from unregistering

http://people.freebsd.org/~pfg/patches/dtrace/illumos-gate-8e6add739e38.diff

- 1455 DTrace tracemem() should take an optional size argument

http://people.freebsd.org/~pfg/patches/dtrace/illumos-gate-571b0355c2e3.diff

Once done with those we can continue bringing the nicer features:

http://dtrace.org/blogs/eschrock/2011/10/26/your-mdb-fell-into-my-dtrace/

Cheers,

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

[CFT] WITH_BSD_PATCH

[Pedro Giffuni]

(Not sure the first announcement made it - Sorry if you get this twice)

Fellow FreeBSD developers;

As many of you may have noticed as of r246074 we have a
new version of patch(1) in the tree!

The brief history is this:

- Larry Wall developed the first patch(1) implementation
which was taken by the FSF and greatly enhanced into
what today is GNU patch.
- FreeBSD has been using an early version of GNU patch
(2.1) and made some relatively small enhancements on it.
Two of the files in FreeBSD are under the GPL.
-OpenBSD took a very old version of patch (2.0) and
started from there. The GPL'd files were replaced with
PD or otherwise unrestricted versions.
- The OpenBSD version was ported to DragonFly BSD
and after further enhancements the DF version was also
adopted by NetBSD.

I took the DragonFly version and back-ported some of the
changes that we had in the FreeBSD version. As a result
the new BSD patch that is available as an option in the tree
covers most of the functionality of the patch in FreeBSD
with two exceptions: -I and -S. Both options seem to
be obsolete and don't seem to be used in ports. Furthermore
GNU and BSD patch already uses -I to ignore white spaces.

The new version is expected to be a complete replacement
for our previous GNU patch but has only been lightly tested.
Please test extensively, report bugs, and submit patches.
We would love to use the new patch by default in 10.0 but
only testing will let us know when it's ready.

Special thanks to:
Christoph Mallon - for porting the perforce diff support.
Gabor Kovesdan - for doing the import since he has experience
bringing these jewels into tree :).

Enjoy!

Pedro.




On 01/29/2013 12:03, Gabor Kovesdan wrote:

Author: gabor
Date: Tue Jan 29 17:03:18 2013
New Revision: 246074
URL: http://svnweb.freebsd.org/changeset/base/246074

Log:
   - Add a BSD-licensed patch, ported by Pedro F. Giffuni (pfg) from
 DragonflyBSD and install it as bsdpatch.  WITH_BSD_PATCH makes it
 default and installs GNU patch as gnupatch.

   Submitted by:pfg
   Obtained from:   The DragonflyBSD Project

Added:
   head/tools/build/options/WITH_BSD_PATCH   (contents, props changed)
   head/usr.bin/patch/
   head/usr.bin/patch/Makefile   (contents, props changed)
   head/usr.bin/patch/backupfile.c   (contents, props changed)
   head/usr.bin/patch/backupfile.h   (contents, props changed)
   head/usr.bin/patch/common.h   (contents, props changed)
   head/usr.bin/patch/inp.c   (contents, props changed)
   head/usr.bin/patch/inp.h   (contents, props changed)
   head/usr.bin/patch/mkpath.c   (contents, props changed)
   head/usr.bin/patch/patch.1   (contents, props changed)
   head/usr.bin/patch/patch.c   (contents, props changed)
   head/usr.bin/patch/pathnames.h   (contents, props changed)
   head/usr.bin/patch/pch.c   (contents, props changed)
   head/usr.bin/patch/pch.h   (contents, props changed)
   head/usr.bin/patch/util.c   (contents, props changed)
   head/usr.bin/patch/util.h   (contents, props changed)
Modified:
   head/UPDATING
   head/gnu/usr.bin/patch/Makefile
   head/share/mk/bsd.own.mk
   head/usr.bin/Makefile



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

Re: ctfconvert again

[Pedro Giffuni]

So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting
past the ctfconvert problem that causes a build of 10-CURRENT to say:

ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at
[dwarf_init_attr(400)]

while compiling every kernel source file.  Then I checked out head as
of 245422 into a different partition and tried make buildworld (ran
okay) and make buildkernel (failed with the same error as before).

Do I have to build an early version of head before I can build the
current version of head?  -- George Mitchell


FWIW;

While looking at NetBSD's Dtrace enhancements I found that
this is caused[1] by a known bug in gcc. It was fixed in our base gcc
recently and MFC'd.

Last time I looked, upstream gcc hasn't fixed it, and I am trying
to get the illumos guys to review the NetBSD workaround before
we adopt it.

cheers,

Pedro.

[1] 
https://github.com/jsonn/src/commit/924b243eee68869ee5ed48f2b2fab9815c4f4e82

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

Re: new DragonFly-3.2 scheduler and PostgreSQL comparision with FreeBSD 9.1-RC1

[Pedro Giffuni]

Hello;

On 10/13/2012 13:38, Jakub Lach wrote:

I'm not at all up to date with DragonFly, so does anybody know
what did they change so spectacularly between 3.0/3.2?



I stopped following Dragonfly a while ago but it seems like
it was some VM SMP related work:

http://www.dragonflybsd.org/release30/


Also note that linux had to do some scheduler changes for PostgreSQL too:

http://lwn.net/Articles/518329/

cheers,

Pedro.



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Re-new-DragonFly-3-2-scheduler-and-PostgreSQL-comparision-with-FreeBSD-9-1-RC1-tp5751589p5751733.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org





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

Re: new DragonFly-3.2 scheduler and PostgreSQL comparision with FreeBSD 9.1-RC1

[Pedro Giffuni]

Actually ...

On 10/13/2012 13:38, Jakub Lach wrote:

I'm not at all up to date with DragonFly, so does anybody know
what did they change so spectacularly between 3.0/3.2?


Their explanation of the changes is here:

http://www.shiningsilence.com/dbsdlog/2012/09/19/10403.html

Cheers,

Pedro.


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

Re: Call for bge(4) testers

[Pedro Giffuni]

Success !!!

It fixed kern/169634 for me.

If still possible it should be pushed into 9.1-RELEASE.

Thank you so much for working on this!

Pedro.

On 09/14/2012 16:27, YongHyeon PYUN wrote:

All,

There were lots of reports that stock bge(4) does not work on Dell
Rx20/HP DL 360 G8.  With the help of Broadcom and BCM5719/BCM5720
users I managed to address the issue but I had to touch very
sensitive part of driver. Before committing the change to tree I'd
like to know whether this change introduces regressions on old
bge(4) controllers. If you're bge(4) user, please try latest WIP
version at the following URL and let me know how it goes on your
box. I'm especially interested in whether there is any ASF/IPMI
regression on BCM570x/571x.

http://people.freebsd.org/~yongari/bge/if_bge.c
http://people.freebsd.org/~yongari/bge/if_bgereg.h
http://people.freebsd.org/~yongari/bge/brgphy.c

Build instructions
1. Copy both if_bge.c/if_bgereg.h to /usr/src/sys/dev/bge directory
2. Copy brgphy.c /usr/src/sys/dev/mii
3. Rebuild kernel and reboot to take the change effect.

You can also use the files above for for 9.1/stable/9. For stable/8
it needs slight modification and I couldn't find time to regenerate
the patch.

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





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

Re: Clang as default compiler November 4th

[Pedro Giffuni]

Hello;
 
Just my $0.02.
 
- Original Message -
 ...
 Can you, please, read what I wrote ? Fixing _ports_ to compile with
 clang is plain wrong. Upstream developers use gcc almost always for
 development and testing. Establishing another constant cost on the
 porting work puts burden on the ports submitters, maintainers and even
 ports users.
 
 I do strongly oppose the attempt to drain the freebsd resources by
 forcing porters to port third-party code to other compiler.
 

I can only speak for Apache OpenOffice but since Apple did the switch
already we are feeling a growing pressure to port OpenOffice to clang.

For the time being we need gcc but we would really prefer something
more up to date than gcc 4.2.1 + fixes. In other words, yes making
clang the default may sound drastic but I am OK with killing base
gcc and if clang is what is left I can live with it.

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

[RFT] Some updates to libc/rpc

[Pedro Giffuni]

Hello;

The Bull NFS4 for linux project took our RPC support from libc
and did some enhancements on it for a while. The libraries have
been diverging extensively and many of the changes are linux
specific. The complete log of their changes is here:

http://git.infradead.org/users/steved/libtirpc.git/log


I don't think it would be a good idea to consider them upstream
vendors, but I thought it would be good to attempt to keep partially
in sync. I only took a rather small subset of their changes and got
to this patch:
http://people.freebsd.org/~pfg/patches/patch-rpc


For those interested in the changelog, it's here:
http://people.freebsd.org/~pfg/patches/libtirpc-log


This is libc and rather critical stuff so I have no hurry and would
like extensive testing before considering it for head.

Please give it a try.

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

[CFT] Some updates to libc/rpc (second try)

[Pedro Giffuni]

(Second try with a more benign mailer)

Hello;

A while back the Bull NFS4 for linux project took our RPC support
from libcand did some enhancements on it. The libraries have
been diverging extensively and many of the changes are linux
specific. The complete log of their changes is here:

http://git.infradead.org/users/steved/libtirpc.git/log


I don't think it would be a good idea to consider them upstream
vendors, but I thought it would be good to attempt to keep partially
in sync. I only took a rather small subset of their changes and got
to this patch:
http://people.freebsd.org/~pfg/patches/patch-rpc 
http://people.freebsd.org/%7Epfg/patches/patch-rpc


For those interested in the changelog, it's here:
http://people.freebsd.org/~pfg/patches/libtirpc-log 
http://people.freebsd.org/%7Epfg/patches/libtirpc-log



This is rather critical stuff (libc) so I have no hurry and would
like extensive testing before considering it for head.

Please give it a try and report any issue.

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

MS Hyper-v for FreeBSD announced

[Pedro Giffuni]

Hi guys,

Yesterday, per chance, I had the idea of looking up what the status
of the Hyper-V drivers was and I found the announcement:

http://blogs.technet.com/b/openness/archive/2012/08/09/available-today-freebsd-support-for-windows-server-hyper-v.aspx 


The announcement is much easier to find through Bing than
through Google :).

Kudos to everyone involved and hope we see it soon in -current.

Pedro.

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

Re: MPSAFE VFS -- List of upcoming actions

[Pedro Giffuni]

Hi;

Just thought I'd share a link for the fuse-xfs project (for MacFUSE);

 http://sourceforge.net/projects/fusexfs/

It's read-only so maybe it can be considered a feature compatible
replacement of our kernel driver ;).

cheers,

Pedro.

ps. I added it to the WantedPorts wiki so it won't be forgotten
too soon.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

libedit : feel like obsoleting el_data_get/set

[Pedro Giffuni]

Hello;

In my attempt to update libedit and make it somewhat more in line with
NetBSD's code I found we added two private functions: el_data_get and
el_data_set:

http://svnweb.freebsd.org/base?view=revisionrevision=50070 


According to OpenGrok we are not using those functions at all, plus
we have had for a while the upstream sanctioned el_get() and
el_set(),
.
I have no hurry to remove them but I do think it would be good to
reduce some differences with NetBSD's version so I have this
patch that I would like to commit as soon as next week. 

http://people.freebsd.org/~pfg/patches/libedit/patch-libedit-obsolete


Raise your hand if you happen to use them and would prefer
the change postponed or not done.

best regards,

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

Re: [CFT] Add -Wbounded to gcc

[Pedro Giffuni]

--- Mer 11/7/12, Dimitry Andric d...@freebsd.org ha scritto:
...
 
 Does it catch any really interesting bound overruns?
 

Nah .. I arrived to the conclusion that it's not
really worth it :).

 If the number of false positives is very large, then it
 generally isn't
 worth the pain.  Or the option should be turned off by
 default, and only
 enabled for WARNS=some_arbitrary_high_number.
 

It is nice to have but I don't think we should turn it on
for any level. I will have to look at how to do that.

Thanks,

Pedro.

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

[CFT] Add -Wbounded to gcc

[Pedro Giffuni]

Hello;

I have a patch from OpenBSD that adds -Wbounded to gcc:

http://people.freebsd.org/~pfg/patches/patch-gcc-bounded

Unfortunately it breaks world, or at least binutils, at this time:

_
...
cc1: warnings being treated as errors
peigen.c: In function '_bfd_pei_swap_aux_in':
peigen.c:241: warning: array size (14) smaller than bound length (18)
peigen.c:241: warning: array size (14) smaller than bound length (18)
peigen.c: In function '_bfd_pei_swap_aux_out':
peigen.c:314: warning: array size (14) smaller than bound length (18)
peigen.c:314: warning: array size (14) smaller than bound length (18)
*** Error code 1

Stop in /usr/src/gnu/usr.bin/binutils/libbfd.
*** Error code 1

Stop in /usr/src/gnu/usr.bin/binutils.
___

OpenBSD has a fix but before attempting to clean this, and whatever
else would break, I can't help but ask: is it worth it?

best regards,

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

Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice:

[Pedro Giffuni]

Just IMHO;

--- Mer 4/7/12, Doug Barton do...@freebsd.org ha scritto:
...
 
  This is not what I expect from quality securing! It
  is simply a mess and definitely another reason
  and point for the thread Why NOT using FreeBSD.
 
  sure libreoffice is so easy to port...
  
  /me officially gives up with that libreoffice port,
  open for new volunteers 
 
 If you don't have time to work on the port, then don't,
 that's not a problem. But throwing a hissy fit here
 doesn't help at all.

Even on paid jobs, people always have the right to quit.

The thing, as I see it, is that people have to understand
this is a volunteer project and if people don't do things
by themselves they really can't demand someone else to
do it for them.


 It's a plain fact that a working office suite is a basic
 requirement for most desktop users. If _we_ can't provide
 that (note, not you, personally, we, as a
 project), it's a valid reason for users to avoid FreeBSD for
 desktop use.
 

The system is as strong as it's weakest link. There
are perfectly good office suites for FreeBSD and even
then for some of us that is not enough to use FreeBSD
(or linux) as a desktop.

 If we're ever going to make progress in this area we
 have to be willing to examine and absorb facts; and
 then act accordingly.


If people think a particular office suite is critical
then *they* have to spend time on it. If no one has
the time or skills then maybe it's not that important
at all.


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

Re: [HEADS-UP] BSD sort is the default sort in -CURRENT

[Pedro Giffuni]

--- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto:
...
 
  I believe we do not
  make this kind of work with any vendor code that is
 being updated in the
  base;
 
 Au contraire, we frequently avoid updating the old versions
 of things we have in the base precisely because they are
 not bug-for-bug compatible with existing behaviors that we
 count on.



Really?? I guess you are speaking for bind, because the idea
behind updating and piece of software is precisely shaking
bugs. New functionality counts but fixing bugs takes the
priority. We have three serious bug reports concerning
GNU sort and I even submitted an update but no one cared
to apply it.

I would think only the maintainer of the package has the
authority to make any request in the lines of being
bug-for-bug compatible and in the case of GNU sort and
GNU grep they are both unmaintained and replacements
are welcome.

Please let's stop being an obstacle towards people
bringing real progress to FreeBSD!

Pedro.

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

Re: [HEADS-UP] BSD sort is the default sort in -CURRENT

[Pedro Giffuni]

--- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto:
...
 
 Nope.
 
  I would think only the maintainer of the package has
 the
  authority to make any request in the lines of being
  bug-for-bug compatible
 
 You have a seriously wrong idea of maintainer. The
 community owns the software, it's up to the community
 to decide how it should work.

You have a serious wrong idea of ownership. No one really
owns the code and only few people actually take the time
to take care of it.

 Historically we have looked at the maintainer as the person
 who volunteers to take care of code, not the person who has
 the exclusive lock on it.
 

The maintainer, in this context, doesn't have to be a committer
but it has to be someone that spends time fixing bugs or
enhancing the code. You might think that because you use the
code and are used to certain bug that you depend on that you
somehow have a say on how it shall behave in the future but that
is simply an illusion.


  and in the case of GNU sort and
  GNU grep they are both unmaintained and replacements
  are welcome.
 
 Actually both are maintained, it's just that we don't want
 to import the new GNU versions.

Our forks of such packages are unmaintained. I did the work
(TM) of updating GNU sort and no one cared to commit it.
Oleg, took as reference the latest upstream sort
implementation.

 And yes, having BSD versions of these core tools is a
 nice goal, but it's not one we should pursue for its own
 sake.
 

Having something that we can maintain is a goal we should
pursue for it's own sake.

  Please let's stop being an obstacle towards people
  bringing real progress to FreeBSD!
 
 In the case of grep, there were a fairly large number of
 people who agreed that a BSD grep with orders of magnitude
 worse performance than the previous version was not
 something we, as a project, were willing to
 stomach. Sufficiently such that the default was switched
 back.
 

Performance was an issue and in general it was a good
decision that even the coder involved agreed upon. Once
the issue is within acceptable limits, and there has been
progress on this as I understand, BSD grep will be
back.

Don't expect BSD grep to support something different than
posix behaviour though.

 So can we please stop pretending that it's me who's the
 problem, and start looking at these things rationally?
 

How about rationally pointing out your issues with the new
BSD sort? Any regression that you want to report?

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

Re: [RFT] llquantize for FreeBSD's dtrace

[Pedro Giffuni]

--- Mar 26/6/12, Mark Peek m...@freebsd.org ha scritto:

 
  It's a different assertion.
 
  Probably some difference between Solaris and BSD.
  this is very useful, thanks!
 
 Try this, change the assert on line 1429 in file dt_cc.c
 from:
 
 assert(!(arg  (UINT16_MAX  args[i].shift)));
 
 to
 
 assert(!(arg  ((uint64_t)UINT16_MAX 
 args[i].shift)));
 

This certainly looks correct. Thanks Mark !

I updated the patch:

http://people.freebsd.org/~pfg/patches/patch-dtrace-llquantize

cheers,

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

Re: [RFT] llquantize for FreeBSD's dtrace

[Pedro Giffuni]

--- Mar 26/6/12, Fabian Keil freebsd-lis...@fabiankeil.de ha scritto:

 Pedro Giffuni p...@freebsd.org wrote:
 
  --- Mar 26/6/12, Mark Peek m...@freebsd.org
 ha scritto:
 
   Try this, change the assert on line 1429 in file
 dt_cc.c
   from:
   
   assert(!(arg  (UINT16_MAX 
 args[i].shift)));
   
   to
   
   assert(!(arg  ((uint64_t)UINT16_MAX 
   args[i].shift)));
   
  
  This certainly looks correct. Thanks Mark !
  
  I updated the patch:
  
  http://people.freebsd.org/~pfg/patches/patch-dtrace-llquantize
 
 Thanks a lot. Seems to work for me:
 

Nice!

I don't use Dtrace though ... so I'll ask:

Any objections against committing it? :).

Pedro.


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

Re: [RFT] llquantize for FreeBSD's dtrace

[Pedro Giffuni]

Hello Fabian;

--- Sab 23/6/12, Fabian Keil ha scritto:

 Pedro Giffuni p...@freebsd.org wrote:
 
  I am not a Dtrace user (yet) but I started to port the
 Log/linear
  quantizations from Illumos:
  
  http://dtrace.org/blogs/bmc/2011/02/08/llquantize/
  
  Apparently this patch should do it:
  
  http://people.freebsd.org/~pfg/patches/patch-llquantize-complete
  
  Unfortunately when I tried to build current with Dtrace
  support, my i386 Virtualbox VM got stuck in ctfmerge so
  this is completely untested.
  
  Testers that know how to use it are welcome :).
 
 I applied it on 10-CURRENT amd64 from /usr/src with patch
 -p0 without any conflicts, but it doesn't appear to be
 working.
 
 The example from the blog post above triggers an assertion
 that is still reproducible when reducing the test case:
 
 fk@r500 /tmp $sudo dtrace -n 'tick-1ms{@ = llquantize(i++,
 10, 0, 6, 20);}'
 Assertion failed: (!(arg  (UINT16_MAX 
 args[i].shift))), file
 /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c,
 line 1429.


Thanks for testing!

It seems like the syntax has changed from the time the
example from the blog was made. The code says:

/*
 * For log/linear quantizations, we have between one and five
 * arguments in addition to the expression:
 *
 *arg1 = Factor
 *arg2 = Low magnitude
 *arg3 = High magnitude
 *arg4 = Number of steps per magnitude
 *arg5 = Quantization increment value (defaults to 1)
 */


My suggestion would be to instead try using the test
scripts in
cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/

err.D_LLQUANT_FACTORSMALL.d (for example) has

@ = llquantize(0, 1, 0, 10, 10);

hope that helps!

Pedro.


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

Re: [RFT] llquantize for FreeBSD's dtrace

[Pedro Giffuni]

--- Sab 23/6/12, Fabian Keil freebsd-lis...@fabiankeil.de ha scritto:
...
  My suggestion would be to instead try using the test
  scripts in
 
 cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/
  
  err.D_LLQUANT_FACTORSMALL.d (for example) has
  
  @ = llquantize(0, 1, 0, 10, 10);
 
 The problem appears to be unrelated to the syntax change:
 
 fk@r500
 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize
 $sudo dtrace -s err.D_LLQUANT_FACTORSMALL.d
 Assertion failed: (!(arg  (UINT16_MAX 
 args[i].shift))), file
 

It's a different assertion.

Probably some difference between Solaris and BSD.
this is very useful, thanks!

Pedro.

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

[RFT] llquantize for FreeBSD's dtrace

[Pedro Giffuni]

Hello;

I am not a Dtrace user (yet) but I started to port the Log/linear
quantizations from Illumos:

http://dtrace.org/blogs/bmc/2011/02/08/llquantize/

Apparently this patch should do it:

http://people.freebsd.org/~pfg/patches/patch-llquantize-complete

Unfortunately when I tried to build current with Dtrace support,
my i386 Virtualbox VM got stuck in ctfmerge so this is
completely untested.

Testers that know how to use it are welcome :).

best regards,

Pedro.

ps. just for reference, the original code was taken from here:
https://hg.openindiana.org/upstream/illumos/illumos-gate/rev/15b74a2a9a9d
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD?

[Pedro Giffuni]

FWIW;

--- Lun 4/6/12, Jakub Lach jakub_l...@mailplus.pl ha scritto:

 I'm not (only) pointing finger and whining, but
 maybe PC-BSD could relegate someone permanently
 to help you with libreoffice, if indeed desktop is
 so important to them? 
 

I am aware that PC-BSD has been indeed providing
build resources to our LibreOffice maintainer so
you cant really blame them.

I personally enjoy working on Apache OpenOffice's
FreeBSD port and I am glad about having both suites
available, but eevn though they are very similar I
am not interested in maintaining LibreOffice; not
even if I got paid to do it.

What people should realize is that maintaining
such big packages is difficult and the issue
is ultimately not money: if there is no interest
from developers and porters to spend (a lot of)
time on it no one will do it.

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

Re: Why Are You NOT Using FreeBSD?

[Pedro Giffuni]

--- Lun 4/6/12, Jakub Lach jakub_l...@mailplus.pl ha scritto:
...

 
 I personally do not care if it will be LibreOffice or Apache
 OpenOffice as long as it's working and not pulling in
 KDE4/QT4/GTK (most people/linux distros are abandoning OO
 for Libre though it appears), but if human 
 resources are scarce, shouldn't we (who?) decide that one
 big editor (tm) is plenty?


I am not meaning you should use one or the other, I
really don't care. I am saying that if you want to
see LibreOffice or Chrome or anything working well
then *you* have to do your part and not assume it's
PC-BSD or whomever else's fault when it fails.

If you really think the issue is money then perhaps
you should draw your hand in your pocket and send
a targeted donation to our current port maintainer.

I also think this thread doesn't belong in
-current, maybe in -advocacy or -chat.

Pedro.

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