Re: WITHOUT_CAPSICUM|CASPER option ignored: it is no longer supported

2023-10-04 Thread Mariusz Zaborski 
On Tue, Oct 03, 2023 at 09:43:41PM -0700, Michael Dexter wrote:
> In exercising the build options on 14.0-BETA4, WITHOUT_CAPSICUM and
> WITHOUT_CASPER appear to be in an ambiguous state: They are present but
> ignored. Fortunately src.conf(5) now reports "This option has no effect."
> 
> Will these be removed prior to the final release? Are they staying to be
> reimplemented?
AFAIK the plan is to remove them completely, but not before final release.

> Thank you!
> 
> Michael
> 

-- 
Mariusz Zaborski
oshogbo//vx | http://oshogbo.vexillium.org
FreeBSD committer   | https://freebsd.org
If it's not broken, let's fix it till it is!!1


signature.asc
Description: PGP signature

Re: [HEADSUP] making /bin/sh the default shell for root

2021-09-22 Thread Mariusz Zaborski 
+1 from me.

On Wed, 22 Sept 2021 at 12:31, Chris Stephan  wrote:

> I completely agree. It will save me the ‘/bin/sh’ at the beginning of each
> ‘su -‘ session. Also, it will simplify building extra small FreeBSD images,
> allowing an easier removal of ‘csh’.
>
> I use csh from time to time, but I do wish it would take a much more
> explicit action so my brain has switched over to ‘csh mode’. I won’t lie
> that I’ve pasted script into my terminal and spent time troubleshooting why
> the commands didn’t work only to realize I forgot to change to /bin/sh
> first.
>
> Chris Stephan
>
> Sent from FreeBSD
> 
> From: owner-freebsd-curr...@freebsd.org 
> on behalf of Baptiste Daroussin 
> Sent: Wednesday, September 22, 2021 3:36:45 AM
> To: curr...@freebsd.org ; a...@freebsd.org
> 
> Subject: [HEADSUP] making /bin/sh the default shell for root
>
> Hello,
>
> TL;DR: this is not a proposal to deorbit csh from base!!!
>
> For years now, csh is the default root shell for FreeBSD, csh can be
> confusing
> as a default shell for many as all other unix like settled on a bourne
> shell
> compatible interactive shell: zsh, bash, or variant of ksh.
>
> Recently our sh(1) has receive update to make it more user friendly in
> interactive mode:
> * command completion (thanks pstef@)
> * improvement in the emacs mode, to make it behave by default like other
> shells
> * improvement in the vi mode (in particular the vi edit to respect $EDITOR)
> * support for history as described by POSIX.
>
> This makes it a usable shell by default, which is why I would like to
> propose to
> make it the default shell for root starting FreeBSD 14.0-RELEASE (not
> MFCed)
>
> If no strong arguments has been raised until October 15th, I will make this
> proposal happen.
>
> Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE!
>
> Best regards,
> Baptiste
>
>

Re: Deadlock involving truss -f, pdfork() and wait4()

2019-09-13 Thread Mariusz Zaborski 
Hello Ryan,

Can you verify is this patch fix your issue:
https://reviews.freebsd.org/D20362

Thanks,
Mariusz

On Thu, 12 Sep 2019 at 21:37, Ryan Stone  wrote:
>
> I've hit an issue with a simple use of pdfork().  I have a process
> that calls pdfork() and the parent immediately does a wait4() on the
> child pid.  This works fine under normal conditions, but if the parent
> is run under truss -f, the three processes deadlock.  If I switch out
> pdfork() for fork(), the deadlock does not occur.
>
> This C file demonstrates the issue:
>
> https://people.freebsd.org/~rstone/pdfork.c
>
> If I run "truss -f ./pdfork", which uses fork(), it completes within a
> second.  If I run "truss -f ./pdfork -p", which uses pdfork(), the
> processes deadlock.  If I run "./pdfork -p" without truss, it
> completes normally.
>
> procstat reports the following kernel stacks:
>
> 27572 102043 truss   -   mi_switch+0xe2
> sleepq_catch_signals+0x425 sleepq_wait_sig+0xf _sleep+0x1bf
> kern_wait6+0x695 sys_wait6+0x9f amd64_syscall+0x36e
> fast_syscall_common+0x101
> 27573 102469 pdfork  -   mi_switch+0xe2
> sleepq_catch_signals+0x425 sleepq_wait_sig+0xf _sleep+0x1bf
> kern_wait6+0x695 sys_wait4+0x78 amd64_syscall+0x36e
> fast_syscall_common+0x101
> 27574 102053 pdfork  -   mi_switch+0xe2
> thread_suspend_switch+0xd4 ptracestop+0x13b fork_return+0x14e
> fork_exit+0x83 fork_trampoline+0xe
>
> As near as I can tell, truss is blocked waiting for ptrace events, the
> parent process is blocked in wait4, and the child process is perhaps
> waiting for its parent to exit the kernel so it can send the ptrace
> event?
>
> I really don't see anything obvious in the pdfork() code path that
> would cause this to happen when fork() doesn't have the problem.  It
> may be that pdfork() just changes the timing enough to expose a latent
> bug.
>
> I'm seeing this on a recentish current (r351363).
> ___
> 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: -current build failure after SVN r340130

2018-11-04 Thread Mariusz Zaborski 
On Sun, Nov 04, 2018 at 01:50:31PM -0500, Michael Butler wrote:
> ===> libexec/dma/dma-mbox-create (all)
> Building
> /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
> In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1:
> error: all paths through this function will call itself
> [-Werror,-Winfinite-recursion]
> {
> ^
> 1 error generated.
> *** [dma-mbox-create.o] Error code 1
> 
> make[5]: stopped in /usr/src/libexec/dma/dma-mbox-create
> 
> The broken function seems to call itself .. ??
> 
> static __inline int
> caph_fcntls_limit(int fd, uint32_t fcntlrights)
> {
> 
> if (caph_fcntls_limit(fd, fcntlrights) < 0 && errno != ENOSYS)
> return (-1);
> 
> return (0);
> }
Sorry, for that just fixed.

Thanks,
-- 
Mariusz Zaborski
oshogbo//vx | http://oshogbo.vexillium.org
FreeBSD committer   | https://freebsd.org
Software developer  | http://wheelsystems.com
If it's not broken, let's fix it till it is!!1


signature.asc
Description: PGP signature

Re: Nvidia issue with CURRENT

2018-04-23 Thread Mariusz Zaborski 
On Mon, Apr 23, 2018 at 06:17:42PM +1000, Greg 'groggy' Lehey wrote:
> On Monday, 23 April 2018 at  9:55:40 +0200, Mariusz Zaborski wrote:
> > On Mon, Apr 23, 2018 at 05:51:01PM +1000, Greg 'groggy' Lehey wrote:
> >> On Monday, 23 April 2018 at  9:00:33 +0200, O. Hartmann wrote:
> >>> On Sun, 22 Apr 2018 14:38:55 +0200  Mariusz Zaborski 
> >>> <osho...@freebsd.org> wrote:
> >>> In /etc/src.conf , therefore you should add something similar to (like I 
> >>> added
> >>> to mine):
> >>>
> >>> PORTS_MODULES=
> >>> PORTS_MODULES+= x11/nvidia-driver
> >>> PORTS_MODULES+= emulators/virtualbox-ose-kmod
> >>>
> >>> This is one of the great advantages of having an operating system which 
> >>> you can
> >>> compile yourself.
> >>
> >> Yes, but this has nothing to do with the bug.  Clearly Marisuz and I
> >> have the configuration correct, but something has changed in the last
> >> few months.
> >
> > Yea this is a known issue so I rebuild nvidia-driver.
> > I'm just not sure if this is a problem with kernel or with the
> > driver itself.
> 
> Almost by definition, it's a driver issue.  Something in the kernel
> has changed which makes it no longer work.
> 
> >> Marisuz, as I commented, your log wasn't appended to the message I
> >> received.  What is your hardware?
> >
> > https://people.freebsd.org/~oshogbo/Xorg.0.log
> 
> A brief scan doesn't show anything very similar to my issues.  I'll
> look again tomorrow when I have time.
> 
> Did you try the most recent driver?
If you mean the 390.48, then yes.
I didn't see any newer then that.

Thanks,
-- 
Mariusz Zaborski
oshogbo//vx | http://oshogbo.vexillium.org
FreeBSD commiter| https://freebsd.org
Software developer  | http://wheelsystems.com
If it's not broken, let's fix it till it is!!1
___
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: Nvidia issue with CURRENT

2018-04-23 Thread Mariusz Zaborski 
On Mon, Apr 23, 2018 at 05:51:01PM +1000, Greg 'groggy' Lehey wrote:
> On Monday, 23 April 2018 at  9:00:33 +0200, O. Hartmann wrote:
> > On Sun, 22 Apr 2018 14:38:55 +0200
> > Mariusz Zaborski <osho...@freebsd.org> wrote:
> >
> >> Hi,
> >>
> >> Normally I build my CURRENT by myself from Xorg - r332861.
> >> But I also tried latest SNAPSHOT.
> >
> > All my boxes running with nVidia hardware running most recent CURRENT 
> > (compiled
> > this morning on an almost daily basis) and I'm using the lates official 
> > driver
> > available from nVidia, 390.48.
> >
> > It happens to be as a natural byproduct of CURRENT that very often
> > the kernel module of the nVidia driver is out of sync so i made it a
> > habit to recompile the module from sources whenever I
> > recompile/install a kernel.
> 
> As I commented, I've had this on -STABLE as well.
> 
> My guess is that this is GPU dependent.  I'm using an old card:
> 
> [32.251] Current Operating System: FreeBSD teevee.lemis.com 11.1-STABLE 
> FreeBSD 11.1-STABLE #2 r327971: Mon Jan 15 1
> 0:55:53 AEDT 2018 
> g...@teevee.lemis.com:/home/obj/eureka/home/src/FreeBSD/svn/stable/11/sys/GENERIC
>  amd64
> ...
> [32.763] (II) NVIDIA dlloader X Driver  390.25  Wed Jan 24 19:00:20 PST 
> 2018
> ...
> [33.785] (II) NVIDIA(0): NVIDIA GPU GeForce GT 710 (GK208) at PCI:1:0:0 
> (GPU-0)
> [33.785] (--) NVIDIA(0): Memory: 2097152 kBytes
> [33.785] (--) NVIDIA(0): VideoBIOS: 80.28.b8.00.45
> [33.785] (II) NVIDIA(0): Detected PCI Express Link width: 8X
> 
> > In /etc/src.conf , therefore you should add something similar to (like I 
> > added
> > to mine):
> >
> > PORTS_MODULES=
> > PORTS_MODULES+= x11/nvidia-driver
> > PORTS_MODULES+= emulators/virtualbox-ose-kmod
> >
> > This is one of the great advantages of having an operating system which you 
> > can
> > compile yourself.
> 
> Yes, but this has nothing to do with the bug.  Clearly Marisuz and I
> have the configuration correct, but something has changed in the last
> few months.
Yea this is a known issue so I rebuild nvidia-driver.
I'm just not sure if this is a problem with kernel or with the driver itself.

> Marisuz, as I commented, your log wasn't appended to the message I
> received.  What is your hardware?
https://people.freebsd.org/~oshogbo/Xorg.0.log

NVIDIA GPU GeForce GTX 1050 Ti

Thanks,
-- 
Mariusz Zaborski
oshogbo//vx | http://oshogbo.vexillium.org
FreeBSD commiter| https://freebsd.org
Software developer  | http://wheelsystems.com
If it's not broken, let's fix it till it is!!1


signature.asc
Description: PGP signature

Re: Nvidia issue with CURRENT

2018-04-22 Thread Mariusz Zaborski 
Hi,

Normally I build my CURRENT by myself from Xorg - r332861.
But I also tried latest SNAPSHOT.

Thanks,
Mariusz

On 22 April 2018 at 14:24, Tommi Pernila <tommi.pern...@iki.fi> wrote:
> Hi,
>
> are you running which version of CURRENT?
> E.g. Some snapshot or did you compile from source?
>
> -Tommi
>
> On Sun, 22 Apr 2018 at 13.47, Mariusz Zaborski <osho...@freebsd.org> wrote:
>>
>> Hello,
>>
>> I upgraded my FreeBSD to CURRENT and nvidia-drvier-390.48. But it's
>> stop working.
>> I tried also nvidia-driver-390.25 without luck as well.
>>
>> I have loaded nvidia-modeset.ko .
>>
>> While I'm rebooting my machine its also core dumping:
>> https://people.freebsd.org/~oshogbo/nvidia-mail.png .
>> I'm attaching also Xorg log.
>>
>> Is this a known issue?
>>
>> Thanks,
>> Mariusz
>> ___
>> 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"

Nvidia issue with CURRENT

2018-04-22 Thread Mariusz Zaborski 
Hello,

I upgraded my FreeBSD to CURRENT and nvidia-drvier-390.48. But it's
stop working.
I tried also nvidia-driver-390.25 without luck as well.

I have loaded nvidia-modeset.ko .

While I'm rebooting my machine its also core dumping:
https://people.freebsd.org/~oshogbo/nvidia-mail.png .
I'm attaching also Xorg log.

Is this a known issue?

Thanks,
Mariusz
___
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: /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main

2018-03-18 Thread Mariusz Zaborski 
I think r331137 fix the problem.

Thanks,
Mariusz

On 18 March 2018 at 18:29, O. Hartmann <ohartm...@walstatt.org> wrote:
> Am Sun, 18 Mar 2018 13:19:08 -0400 (EDT)
> AN <a...@neu.net> schrieb:
>
>> Fyi, I started seeing this error today during buildworld compile.
>>
>> FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #15 r331021: Thu Mar 15
>> 16:30:40 EDT 2018
>> root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64 1200060
>>
>> # svnlite info
>> Path: .
>> Working Copy Root Path: /usr/src
>> URL: svn://svn.freebsd.org/base/head
>> Relative URL: ^/head
>> Repository Root: svn://svn.freebsd.org/base
>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> Revision: 331135
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: markj
>> Last Changed Rev: 331135
>> Last Changed Date: 2018-03-18 13:03:26 -0400 (Sun, 18 Mar 2018)
>> -
>>
>> --- all_subdir_lib/libcasper ---
>> --- all_subdir_lib/libcasper/services/cap_sysctl ---
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main
>> >>> referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74)
>> >>>   /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_create
>> >>> referenced by cap_sysctl.c:64
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:64)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_string
>> >>> referenced by cap_sysctl.c:65
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:65)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_string
>> >>> referenced by cap_sysctl.c:66
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:66)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_number
>> >>> referenced by cap_sysctl.c:67
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:67)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_null
>> >>> referenced by cap_sysctl.c:69
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:69)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_number
>> >>> referenced by cap_sysctl.c:71
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:71)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_binary
>> >>> referenced by cap_sysctl.c:73
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:73)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> cap_xfer_nvlist
>> >>> referenced by cap_sysctl.c:74
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:74)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_get_number
>> >>> referenced by cap_sysctl.c:77
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:77)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_get_number
>> >>> referenced by cap_sysctl.c:78
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:78)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_destroy
>> >>> referenced by cap_sysctl.c:79
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:79)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/

Re: /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main

2018-03-18 Thread Mariusz Zaborski 
Thank you for reporting - I'm checking it.
Do you use option MK_CASPER=no ?

On 18 March 2018 at 18:19, AN  wrote:
> Fyi, I started seeing this error today during buildworld compile.
>
> FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #15 r331021: Thu Mar 15
> 16:30:40 EDT 2018 root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL
> amd64 1200060
>
> # svnlite info
> Path: .
> Working Copy Root Path: /usr/src
> URL: svn://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 331135
> Node Kind: directory
> Schedule: normal
> Last Changed Author: markj
> Last Changed Rev: 331135
> Last Changed Date: 2018-03-18 13:03:26 -0400 (Sun, 18 Mar 2018)
> -
>
> --- all_subdir_lib/libcasper ---
> --- all_subdir_lib/libcasper/services/cap_sysctl ---
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main

 referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74)
   /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_create

 referenced by cap_sysctl.c:64
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:64)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_string

 referenced by cap_sysctl.c:65
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:65)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_string

 referenced by cap_sysctl.c:66
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:66)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_number

 referenced by cap_sysctl.c:67
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:67)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_null

 referenced by cap_sysctl.c:69
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:69)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_number

 referenced by cap_sysctl.c:71
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:71)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_binary

 referenced by cap_sysctl.c:73
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:73)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> cap_xfer_nvlist

 referenced by cap_sysctl.c:74
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:74)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_get_number

 referenced by cap_sysctl.c:77
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:77)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_get_number

 referenced by cap_sysctl.c:78
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:78)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_destroy

 referenced by cap_sysctl.c:79
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:79)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_get_number

 referenced by cap_sysctl.c:84
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:84)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_get_binary

 referenced by cap_sysctl.c:86
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:86)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_destroy

 referenced by cap_sysctl.c:91
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:91)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined

Re: r 328531: installworld failure: /usr/share/man/man3/cap_syslog.3.gz: No such file or directory

2018-01-29 Thread Mariusz Zaborski 

On Mon, Jan 29, 2018 at 06:31:31AM +0100, O. Hartmann wrote:
> 
> "make installworld' fails on r328531 with the follwoing error:
> 
> [...]
> --- maninstall ---
> rm -f /usr/share/man/man3/cap_syslog.3 /usr/share/man/man3/cap_syslog.3.gz;
> install -l
> h  /usr/share/man/man3/cap_syslog.3.gz /usr/share/man/man3/cap_syslog.3.gz
> install: link /usr/share/man/man3/cap_syslog.3.gz
> -> /usr/share/man/man3/cap_syslog.3.gz: No such file or directory ***
> [maninstall] Error code 71
> 
> make[7]: stopped in /usr/src/lib/libcasper/services/cap_syslog
> 1 error

Hello,

Thank you for reporting.
Did r328532 fix the problem for you?

Thanks,
-- 
Mariusz Zaborski
oshogbo//vx | http://oshogbo.vexillium.org
FreeBSD commiter| https://freebsd.org
Software developer  | http://wheelsystems.com
If it's not broken, let's fix it till it is!!1


signature.asc
Description: PGP signature

Re: casper issues with pkgbase

2017-11-08 Thread Mariusz Zaborski 
On Wed, Nov 08, 2017 at 01:01:59AM +, Glen Barber wrote:
> On Wed, Nov 08, 2017 at 06:43:44AM +0800, Ben Woods wrote:
> > Hi everyone,
> > 
> > I recently upgraded my FreeBSD 12-current machine which uses pkgbase from
> > r324720 to r325426, and it looks like an error has been introduced in the
> > naming of base packages for casper.
> > 
> > Without having looked into it deeper, I suspect one of the following
> > changes is at fault:
> > https://svnweb.freebsd.org/base/head/lib/libcasper/libcasper/Makefile?r1=325062=325061=325062
> 
> It appears to be this one.  Should be fixed as of r325524.  Thank you
> for the report.
> 
Thanks, for reporting and fixing it.

-- 
Mariusz Zaborski
oshogbo//vx | http://oshogbo.vexillium.org
FreeBSD commiter| https://freebsd.org
Software developer  | http://wheelsystems.com
If it's not broken, let's fix it till it is!!1


signature.asc
Description: PGP signature

Re: Can't build -current incrementally due to libnv changes

2016-08-27 Thread Mariusz Zaborski 
Sorry I missed somehow header file.
Done in r304912.

Thanks,
Mariusz

On 27 August 2016 at 17:00, Andrey Chernov <a...@freebsd.org> wrote:
> Yes, 'make includes' (and 'make obj' and 'make depend') is done before
> 'make all' in /usr/src/lib
> ===> libnv (all)
> cc  -O2 -pipe -march=sandybridge  -I/usr/src/lib/libnv/../../sys
> -I/usr/src/lib/libnv -MD  -MF.depend.cnvlist.o -MTcnvlist.o -std=gnu99
> -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k
> -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts
> -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition
> -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Qunused-arguments  -c
> /usr/src/lib/libnv/../../sys/contrib/libnv/cnvlist.c -o cnvlist.o
> /usr/src/lib/libnv/../../sys/contrib/libnv/cnvlist.c:49:10: fatal error:
>   'sys/cnv.h' file not found
> #include 
>  ^
> 1 error generated.
> *** Error code 1
> ___
> 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: Hello fdclose

2014-03-25 Thread Mariusz Zaborski 
 Does this patch allow perl to stop writing to FILE._file? As pointed out
 in
 http://lists.freebsd.org/pipermail/freebsd-current/2013-January/039024.html
 perlio.c in the perl source contains a function
 PerlIOStdio_invalidate_fileno() that should modify a FILE such that
 fclose() does not close the file descriptor but still frees all memory
 (Perl has already called fflush()). Although using fdclose() could solve
 this without touching the internals of FILE, this will make perlio.c
 uglier with even more #ifdefs.
Yes it should help. I start some work on it but i have some troubles
with perl (I'm not perl hacker :(), so I will try to prepare some
patch for it in the nearest feature. There are some other places also
where we could use it.

 [snip]
 --- //depot/user/oshogbo/capsicum/lib/libc/stdio/Symbol.map   2013-06-28 
 08:51:28.0 
 +++ /home/oshogbo/p4/capsicum/lib/libc/stdio/Symbol.map   2013-06-28 
 08:51:28.0 
 @@ -156,6 +156,7 @@
   putwc_l;
   putwchar_l;
   fmemopen;
 + fdclose;
   open_memstream;
   open_wmemstream;
  };

 This should be in the FBSD_1.4 namespace (which does not exist yet).

Oh - thx, so this will be good now?

@@ -160,6 +160,10 @@
  open_wmemstream;
 };

+FBSD_1.4 {
+ fdclose;
+};
+

 [snip]
 --- //depot/user/oshogbo/capsicum/lib/libc/stdio/fclose.c 2013-06-28 
 08:51:28.0 
 +++ /home/oshogbo/p4/capsicum/lib/libc/stdio/fclose.c 2013-06-28 
 08:51:28.0 
 [snip]
 +int
 +fdclose(FILE *fp)
 +{
 + int fd, r, err;
 +
 + if (fp-_flags == 0) {  /* not open! */
 + errno = EBADF;
 + return (EOF);
 + }
 +
 + r = 0;
 + FLOCKFILE(fp);
 + fd = fp-_file;
 + if (fp-_close != __sclose) {
 + r = EOF;
 + errno = EOPNOTSUPP;
 + } else if (fd  0) {
 + r = EOF;
 + errno = EBADF;
 + }
 + if (r == EOF) {
 + err = errno;
 + (void)cleanfile(fp, true);
 + errno = err;
 + } else {
 + r = cleanfile(fp, false);
 + }
   FUNLOCKFILE(fp);
 +
 + return (r == 0 ? fd : r);

 If a file descriptor would be returned but cleanfile() returns an error
 (e.g. write error on flush), the file descriptor is not returned and not
 closed.

 I think that in cases where fdclose() would be used, it is essential
 that the file descriptor is never closed. This means that the API needs
 to be different so it can report a write error but still return a file
 descriptor. One way to do this is to return the file descriptor by
 reference. Another is to expect the application to call fileno() and not
 return the descriptor from the new function.
You have very good point. The first question is where function will
return error:
1* When there is different _close function from std (it will behave
like fclose with some errno)
2* When __sflush fails (and it will free structure)
3* When fd in structure is not correct (it will behave like fclose
with some errno)

I think those assumptions about when close fd are reasonable. When I
wrote this function I discouse this with Pawel, and we decided that if
_close function is different from std we should work same as fclose
function plus return errno about EOPNOTSUPP.

So in my opinion only second point is unwanted by us. So if __sflush
fails we could not return any err (I don't thing this is wanted
solution) or we could return error returned by __sflush and not free
structure. In my opinion last option will be the best one. What you
think Jilles?

In this moment I don't like idea of changing API of this function.

Cheers,
Mariusz
___
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: Hello fdclose

2014-03-25 Thread Mariusz Zaborski 
On 22 March 2014 08:04, Kevin Oberman rkober...@gmail.com wrote:
 On Fri, Mar 21, 2014 at 5:51 PM, Dag-Erling Smørgrav d...@des.no wrote:

 Warner Losh i...@bsdimp.com writes:
  It does serve a useful purpose, though, which is why it has endured.
  If you were to have a man page that said 'Putc(3) returns ...' then the
  automated tools (and web links) that find Putc.3 wouldn't be able to
  since
  it doesn't exist.

 Moreover - if FreeBSD were written in Pascal, it might not matter, but
 in C, _exit(2) and _Exit(3) are two different functions.

 (I'm sure there are other examples without a leading underscore)

 (eww, starting a sentence with a non-alphabetic character would be even
 worse...)


 3Com was once a very important networking company. 3M still is.

 /me duck and runs.
 --
 R. Kevin Oberman, Network Engineer, Retired
 E-mail: rkober...@gmail.com

Hello,

Thx guys for such big interested of the fdclose function :)
When we decide how API will look and how the fdclose function will
behave then I will correct man page.

Thx,
Mariusz
___
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: Hello fdclose

2014-03-25 Thread Mariusz Zaborski 

  +FBSD_1.4 {
  + fdclose;
  +};
  +

 You also need to update the lib/libc/Versions.def file.  Look e.g. at
 the r226217 for the proper way to introduce new version.


Updated - thank you.

Cheers,
Mariusz
___
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

Hello fdclose

2014-03-17 Thread Mariusz Zaborski 
Hi,

After our previous discuss  [1] I prepare fdclosedir(3) function which
was committed by Pawel (cc'ed) in commit r254499.

A while ago I also prepare the fdclose function. Unfortunately, this
new function is a little bit more tricky then previous one. Can I ask
you for a review of this patch?

Thanks,
Mariusz

[1] http://lists.freebsd.org/pipermail/freebsd-arch/2013-August/014688.html
--- //depot/user/oshogbo/capsicum/include/stdio.h	2013-06-28 08:51:28.0 
+++ /home/oshogbo/p4/capsicum/include/stdio.h	2013-06-28 08:51:28.0 
@@ -396,6 +396,7 @@
 int	 asprintf(char **, const char *, ...) __printflike(2, 3);
 char	*ctermid_r(char *);
 void	 fcloseall(void);
+int	 fdclose(FILE *);
 char	*fgetln(FILE *, size_t *);
 const char *fmtcheck(const char *, const char *) __format_arg(2);
 int	 fpurge(FILE *);
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/Symbol.map	2013-06-28 08:51:28.0 
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/Symbol.map	2013-06-28 08:51:28.0 
@@ -156,6 +156,7 @@
 	putwc_l;
 	putwchar_l;
 	fmemopen;
+	fdclose;
 	open_memstream;
 	open_wmemstream;
 };
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/fclose.3	2013-06-28 08:51:28.0 
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/fclose.3	2013-06-28 08:51:28.0 
@@ -1,5 +1,6 @@
-.\ Copyright (c) 1990, 1991, 1993
-.\	The Regents of the University of California.  All rights reserved.
+.\ Copyright (c) 1990, 1991, 1993 The Regents of the University of California.
+.\ Copyright (c) 2014 Mariusz Zaborski osho...@freebsd.org
+.\ All rights reserved.
 .\
 .\ This code is derived from software contributed to Berkeley by
 .\ Chris Torek and the American National Standards Committee X3,
@@ -32,11 +33,12 @@
 .\ @(#)fclose.3	8.1 (Berkeley) 6/4/93
 .\ $FreeBSD: head/lib/libc/stdio/fclose.3 165903 2007-01-09 00:28:16Z imp $
 .\
-.Dd April 22, 2006
+.Dd March 17, 2014
 .Dt FCLOSE 3
 .Os
 .Sh NAME
 .Nm fclose ,
+.Nm fdclose ,
 .Nm fcloseall
 .Nd close a stream
 .Sh LIBRARY
@@ -45,6 +47,8 @@
 .In stdio.h
 .Ft int
 .Fn fclose FILE *stream
+.Ft int
+.Fn fdclose FILE *stream
 .Ft void
 .Fn fcloseall void
 .Sh DESCRIPTION
@@ -59,22 +63,64 @@
 .Xr fflush 3 .
 .Pp
 The
+.Fn fdclose
+function is equivalent to the
+.Fn fclose
+function except that this function returns file descriptor instead of
+closing it.
+.Pp
+The
 .Fn fcloseall
 function calls
 .Fn fclose
 on all open streams.
 .Sh RETURN VALUES
-Upon successful completion 0 is returned.
+The
+.Fn fcloseall
+function return no value.
+.Pp
+Upon successful completion
+.Fn fclose
+return 0.
+Otherwise,
+.Dv EOF
+is returned and the global variable
+.Va errno
+is set to indicate the error.
+.Pp
+The
+.Fn fdclose
+function return the file descriptor if successfull.
 Otherwise,
 .Dv EOF
 is returned and the global variable
 .Va errno
 is set to indicate the error.
+.Pp
 In either case no further access to the stream is possible.
 .Sh ERRORS
+.Bl -tag -width Er
+.It Bq Er EOPNOTSUPP
 The
+.Fa _close
+method in
+.Fa stream
+argument to
+.Fn fdclose ,
+was not default.
+.It Bq Er EBADF
+The
+.Fa stream
+argument to
+.Fn fdclose ,
+does not contains valid file descriptor.
+.El
+.Pp
+The
 .Fn fclose
-function
+and
+.Fn fdclose
+functions
 may also fail and set
 .Va errno
 for any of the errors specified for the routines
@@ -84,7 +130,9 @@
 .Sh NOTES
 The
 .Fn fclose
-function
+and
+.Fn fdclose
+functions
 does not handle NULL arguments; they will result in a segmentation
 violation.
 This is intentional - it makes it easier to make sure programs written
@@ -104,8 +152,13 @@
 function
 conforms to
 .St -isoC .
-.Pp
+.Sh History
 The
 .Fn fcloseall
 function first appeared in
 .Fx 7.0 .
+.Pp
+The
+.Fn fdclose
+function first appeared in
+.Fx 11.0 .
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/fclose.c	2013-06-28 08:51:28.0 
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/fclose.c	2013-06-28 08:51:28.0 
@@ -1,6 +1,7 @@
 /*-
- * Copyright (c) 1990, 1993
- *	The Regents of the University of California.  All rights reserved.
+ * Copyright (c) 1990, 1993 The Regents of the University of California.
+ * Copyright (c) 2014 Mariusz Zaborski osho...@freebsd.org
+ * All rights reserved.
  *
  * This code is derived from software contributed to Berkeley by
  * Chris Torek.
@@ -38,6 +39,7 @@
 
 #include namespace.h
 #include errno.h
+#include stdbool.h
 #include stdio.h
 #include stdlib.h
 #include un-namespace.h
@@ -45,19 +47,17 @@
 #include libc_private.h
 #include local.h
 
-int
-fclose(FILE *fp)
+static int
+cleanfile(FILE *fp, bool c)
 {
 	int r;
 
-	if (fp-_flags == 0) {	/* not open! */
-		errno = EBADF;
-		return (EOF);
+	r = fp-_flags  __SWR ? __sflush(fp) : 0;
+	if (c) {
+		if (fp-_close != NULL  (*fp-_close)(fp-_cookie)  0)
+			r = EOF;
 	}
-	FLOCKFILE(fp);
-	r = fp-_flags  __SWR ? __sflush(fp) : 0;
-	if (fp-_close != NULL  (*fp-_close)(fp-_cookie)  0)
-		r = EOF;
+
 	if (fp-_flags  __SMBF)
 		free((char *)fp-_bf._base

panic: worklist_remove

2000-03-29 Thread mariusz 

Hi

New system FreeBSD 5.0, cvsup today.

System reboot in message:

panic: worklist_remove: not on list
syncing disks... panic: softdep_lock: locking against myself

watch is wrong ?

Mariusz



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Freebsd 4.0 and Linux

1999-10-12 Thread mariusz 

Hi 
   
   What depth of FreeBSD's support for Linux applications under 
   FreeBSD 4.0?  I can't seem to find adequate information online.  
   Does the support comply with our current requirements for Linux?:
   
   minimum kernel version: 2.0.34
   minimum glibc version: 2.0.7-19
   
Mariusz



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message