Re: pkg.c revision 367687 breaks pkg
Not for me, it's not .. imb@toshi:/usr/src/usr.sbin/pkg> pkg info -a The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: n And yet .. imb@toshi:/home/imb> ll /usr/local/sbin/pkg -rwxr-xr-x 1 root wheel 2890304 Oct 11 09:54 /usr/local/sbin/pkg* Reverting to SVN r367686 works correctly. mailwrapper is similarly broekn, imb On 11/15/20 1:55 PM, Scott Long wrote: This is fixed in revision 367701 Scott On Nov 15, 2020, at 11:52 AM, Manfred Antar wrote: pkg.c revision 367687 breaks pkg : (pkg)5052}pkg The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: This is after upgrading to the latest pkg and libutil. pkg.c version 367075 works: (pkg)5057}pkg pkg: not enough arguments Usage: pkg [-v] [-d] [-l] [-N] [-j |-c |-r ] [-C ] [-R ] [-o var=value] [-4|-6] [] For more information on available commands and options see 'pkg help’. ___ 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: pkg.c revision 367687 breaks pkg
Am 15.11.20 um 21:34 schrieb Kyle Evans: On Sun, Nov 15, 2020 at 2:05 PM Stefan Esser wrote: Am 15.11.20 um 20:41 schrieb Kyle Evans: This is a separate (valid) problem, but not directly related to Scott's work here. sysctlbyname now goes directly to the kernel with no chance for the user.* sysctls to intercept. That should independently be fixed to maintain the illusion that they're real sysctl's. user.localbase is a real sysctl, but with a default value returned when sysctl(3) is used. Yup. The getlocalbase() function should not depend on this default value, since it contains an identicl default value that can be returned if sysctlbyname fails (or rather returns a zero length string in case no other value has been written to the kernel). I don't care about this particular application, to be honest, but about the general problem. libc has a sizable chunk of code in sysctl(3) dealing with user.* sysctls, and sysctlbyname will never see it. This isn't documented in the manpage, and IMO it's really just an oversight; libc should still be able to provide the values as seen in ^/lib/libc/gen/sysctl.c whether you've invoked sysctl() or sysctlbyname(). At a glance, it looks like localbase is the only one that's also tunable, most of these don't really even need to take a trip to the kernel to read. I have added user.localbase a few days back to -CURRENT. Having it under "user" seemed a logical choice and I have preserved the semantics of all the existing R/O cases. The trip through the kernel has the effect, that the conditions for access that are specified in kern_mib.c are checked, before the value is then provided by libc. I do consider this is a sensible approach, since it consolidates the access checks / policy in the kernel, independently of detailed checks in libc. The values returned by libc are read-only system parameters, and they could also be passed into the kernel, to be returned from there, but this would not provide any useful added functionality. Having getsysctlbyname() implement the same logic for accesses to the user sysctl name-space seems sensible, and if nobody beats me, I'd be willing to provide a patch for review. Back to getlocalbase() and its supposed semantics: Is it useful to have it return a NULL prefix (functionally equivalent to returning "/")? Having LOCALBASE/etc identical to /etc could lead to unexpected behavior (e.g. to files being found twice if a program collects data from both places), but might still be valid? I'd consider an undefined return value from sysctl() to indicate that the system default of (e.g.) "/usr/local" should be used, while a value of "/" maps LOCALBASE files to be found relative to the root directory. Regards, STefan ___ 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: pkg.c revision 367687 breaks pkg
On Sun, Nov 15, 2020 at 2:05 PM Stefan Esser wrote: > > Am 15.11.20 um 20:41 schrieb Kyle Evans: > > This is a separate (valid) problem, but not directly related to > > Scott's work here. sysctlbyname now goes directly to the kernel with > > no chance for the user.* sysctls to intercept. That should > > independently be fixed to maintain the illusion that they're real > > sysctl's. > > user.localbase is a real sysctl, but with a default value returned > when sysctl(3) is used. > Yup. > The getlocalbase() function should not depend on this default value, > since it contains an identicl default value that can be returned if > sysctlbyname fails (or rather returns a zero length string in case > no other value has been written to the kernel). > I don't care about this particular application, to be honest, but about the general problem. libc has a sizable chunk of code in sysctl(3) dealing with user.* sysctls, and sysctlbyname will never see it. This isn't documented in the manpage, and IMO it's really just an oversight; libc should still be able to provide the values as seen in ^/lib/libc/gen/sysctl.c whether you've invoked sysctl() or sysctlbyname(). At a glance, it looks like localbase is the only one that's also tunable, most of these don't really even need to take a trip to the kernel to read. Thanks, Kyle Evans ___ 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: pkg.c revision 367687 breaks pkg
> On Nov 15, 2020, at 1:05 PM, Stefan Esser wrote: > > Am 15.11.20 um 20:41 schrieb Kyle Evans: >> This is a separate (valid) problem, but not directly related to >> Scott's work here. sysctlbyname now goes directly to the kernel with >> no chance for the user.* sysctls to intercept. That should >> independently be fixed to maintain the illusion that they're real >> sysctl's. > > user.localbase is a real sysctl, but with a default value returned > when sysctl(3) is used. > > The getlocalbase() function should not depend on this default value, > since it contains an identicl default value that can be returned if > sysctlbyname fails (or rather returns a zero length string in case > no other value has been written to the kernel). > sysctlbyname() was returning success and an empty string. getlocalbase() has no way to know if this was intentional or not, so it can’t rationally check. Switching to sysctlnametomib() + sysctl() seems to solve this problem. However, I’m going to revert all of this and let the experts decide on the best path forward. Scott ___ 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: pkg.c revision 367687 breaks pkg
Am 15.11.20 um 20:41 schrieb Kyle Evans: This is a separate (valid) problem, but not directly related to Scott's work here. sysctlbyname now goes directly to the kernel with no chance for the user.* sysctls to intercept. That should independently be fixed to maintain the illusion that they're real sysctl's. user.localbase is a real sysctl, but with a default value returned when sysctl(3) is used. The getlocalbase() function should not depend on this default value, since it contains an identicl default value that can be returned if sysctlbyname fails (or rather returns a zero length string in case no other value has been written to the kernel). Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: pkg.c revision 367687 breaks pkg
> On Nov 15, 2020, at 12:41 PM, Kyle Evans wrote:
>
> On Sun, Nov 15, 2020 at 1:33 PM Guy Yur wrote:
>>
>> On 15/11/20 8:55 pm, Scott Long wrote:
>>> This is fixed in revision 367701
>>>
>>> Scott
>>
>> Hi,
>>
>> I am on revision 367710 (newer) and have the same problem.
>> sysctlbyname() returns an empty string and length of 1.
>> sysctl() with name converted to mib works fine.
>>
>> ssize_t tmplen;
>> char path[1000] = { 0 };
>>
>> tmplen = getlocalbase(path, sizeof(path));
>> printf("%s : %zd\n", path, tmplen);
>>
>> tmplen = sizeof(path);
>> if (sysctlbyname("user.localbase", path, (size_t *), NULL, 0) == 0)
>> printf("%s : %zd\n", path, tmplen);
>>
>> int mib[100] = { 0 };
>> size_t miblen;
>> if (sysctlnametomib("user.localbase", mib, ) == 0) {
>> for (int i = 0; i < miblen; i++)
>> printf("%d ", mib[i]);
>> printf("\n");
>> }
>>
>> tmplen = sizeof(path);
>> if (sysctl(mib, miblen, path, (size_t *), NULL, 0) == 0)
>> printf("%s : %zd\n", path, tmplen);
>>
>> prints:
>> : 1
>> : 1
>> 8 21
>> /usr/local : 11
>>
>> Thanks,
>> Guy Yur
>>
>
> This is a separate (valid) problem, but not directly related to
> Scott's work here. sysctlbyname now goes directly to the kernel with
> no chance for the user.* sysctls to intercept. That should
> independently be fixed to maintain the illusion that they're real
> sysctl’s
It turns out the my userland, kernel, and startup scripts were out of
sync and this was succeeding in error for me. Thanks for the hint, I
think I have it working now.
Scott
___
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: pkg.c revision 367687 breaks pkg
On Sun, Nov 15, 2020 at 1:33 PM Guy Yur wrote:
>
> On 15/11/20 8:55 pm, Scott Long wrote:
> > This is fixed in revision 367701
> >
> > Scott
>
> Hi,
>
> I am on revision 367710 (newer) and have the same problem.
> sysctlbyname() returns an empty string and length of 1.
> sysctl() with name converted to mib works fine.
>
> ssize_t tmplen;
> char path[1000] = { 0 };
>
> tmplen = getlocalbase(path, sizeof(path));
> printf("%s : %zd\n", path, tmplen);
>
> tmplen = sizeof(path);
> if (sysctlbyname("user.localbase", path, (size_t *), NULL, 0) == 0)
>printf("%s : %zd\n", path, tmplen);
>
> int mib[100] = { 0 };
> size_t miblen;
> if (sysctlnametomib("user.localbase", mib, ) == 0) {
>for (int i = 0; i < miblen; i++)
> printf("%d ", mib[i]);
>printf("\n");
> }
>
> tmplen = sizeof(path);
> if (sysctl(mib, miblen, path, (size_t *), NULL, 0) == 0)
>printf("%s : %zd\n", path, tmplen);
>
> prints:
> : 1
> : 1
> 8 21
> /usr/local : 11
>
> Thanks,
> Guy Yur
>
This is a separate (valid) problem, but not directly related to
Scott's work here. sysctlbyname now goes directly to the kernel with
no chance for the user.* sysctls to intercept. That should
independently be fixed to maintain the illusion that they're real
sysctl's.
Thanks,
Kyle Evans
___
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: pkg.c revision 367687 breaks pkg
On 15/11/20 8:55 pm, Scott Long wrote:
This is fixed in revision 367701
Scott
Hi,
I am on revision 367710 (newer) and have the same problem.
sysctlbyname() returns an empty string and length of 1.
sysctl() with name converted to mib works fine.
ssize_t tmplen;
char path[1000] = { 0 };
tmplen = getlocalbase(path, sizeof(path));
printf("%s : %zd\n", path, tmplen);
tmplen = sizeof(path);
if (sysctlbyname("user.localbase", path, (size_t *), NULL, 0) == 0)
printf("%s : %zd\n", path, tmplen);
int mib[100] = { 0 };
size_t miblen;
if (sysctlnametomib("user.localbase", mib, ) == 0) {
for (int i = 0; i < miblen; i++)
printf("%d ", mib[i]);
printf("\n");
}
tmplen = sizeof(path);
if (sysctl(mib, miblen, path, (size_t *), NULL, 0) == 0)
printf("%s : %zd\n", path, tmplen);
prints:
: 1
: 1
8 21
/usr/local : 11
Thanks,
Guy Yur
On Nov 15, 2020, at 11:52 AM, Manfred Antar wrote:
pkg.c revision 367687 breaks pkg :
(pkg)5052}pkg
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]:
This is after upgrading to the latest pkg and libutil.
pkg.c version 367075 works:
(pkg)5057}pkg
pkg: not enough arguments
Usage: pkg [-v] [-d] [-l] [-N] [-j |-c |-r ] [-C
] [-R ] [-o var=value] [-4|-6] []
For more information on available commands and options see 'pkg help’.
___
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: pkg.c revision 367687 breaks pkg
This is fixed in revision 367701 Scott > On Nov 15, 2020, at 11:52 AM, Manfred Antar wrote: > > pkg.c revision 367687 breaks pkg : > > (pkg)5052}pkg > The package management tool is not yet installed on your system. > Do you want to fetch and install it now? [y/N]: > > This is after upgrading to the latest pkg and libutil. > pkg.c version 367075 works: > > (pkg)5057}pkg > pkg: not enough arguments > Usage: pkg [-v] [-d] [-l] [-N] [-j |-c |-r > ] [-C ] [-R ] [-o var=value] > [-4|-6] [] > > For more information on available commands and options see 'pkg help’. > ___ 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"
pkg.c revision 367687 breaks pkg
pkg.c revision 367687 breaks pkg : (pkg)5052}pkg The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: This is after upgrading to the latest pkg and libutil. pkg.c version 367075 works: (pkg)5057}pkg pkg: not enough arguments Usage: pkg [-v] [-d] [-l] [-N] [-j |-c |-r ] [-C ] [-R ] [-o var=value] [-4|-6] [] For more information on available commands and options see 'pkg help’. ___ 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"
in between freeBSD and ghostBSD
hiya,
have this: https://www.unitedbsd.com/d/310-ghostbsd-to-be-made-current
what do you think of it? laptop still compiling (29 hours for the
userspace mostly llvm and clang). I think a good idea is a "('pkg update
-f '*')", compiling from which ports. in ghostBSD it's simply pkg
install ports but the freeBSD checked out with .svn.
will post results here (maybe from the other netBSD if nothing works),
inkl. the crash-trace from the drm-kmod-current; how about
drm-kmod-devel? there's a binary for ghostBSD but I get a kernel panic
when loading the driver; stacktrace to be rescued and brought to netBSD.
any suggestions or tipps for that kinda situation?
lizbeth
___
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"
