[Bug 279303] usr.sbin/newsyslog: Fix case of the 'P' flag in newsyslog.conf's manpage

2024-05-26 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279303

--- Comment #7 from Ed Maste  ---
There are two possible follow-on changes that could be made:

- Add a note in the man page that the flags are case insensitive but by
convention are typically uppercase. 

- Switch the switch statement to upper case for diff reduction against NetBSD,
if the two versions of newvers.sh are still sufficiently similar otherwise.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 279303] usr.sbin/newsyslog: Fix case of the 'P' flag in newsyslog.conf's manpage

2024-05-26 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279303

--- Comment #6 from Ed Maste  ---
Thanks for the thorough chase through the rabbit hole! I've merged the patch as
it makes sense for the man page to be consistent.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 279303] usr.sbin/newsyslog: Fix case of the 'P' flag in newsyslog.conf's manpage

2024-05-26 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279303

--- Comment #5 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=a8f86ecd6104b1f127b426be278a9031789b4413

commit a8f86ecd6104b1f127b426be278a9031789b4413
Author: Joshua Kinard 
AuthorDate: 2024-05-25 20:52:11 +
Commit: Ed Maste 
CommitDate: 2024-05-27 01:34:14 +

newsyslog: Fix case of the 'P' flag in newsyslog.conf(5)

PR: 279303
Reviewed-by: emaste
Signed-off-by: Joshua Kinard 

 usr.sbin/newsyslog/newsyslog.conf.5 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 279303] usr.sbin/newsyslog: Fix case of the 'P' flag in newsyslog.conf's manpage

2024-05-26 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279303

--- Comment #4 from Joshua Kinard  ---
(In reply to Joshua Kinard from comment #3)

Why is it always the little things that hide the deepest of rabbit holes?

I dug back into FreeBSD's cgit history, and it looks like the 'p'/'P' flag
(take your pick) was added on 2017-12-31 by @eadler, tracked by git commit
df76ac99518d.  In that commit, the flag was added as lowercase to the
newsyslog.conf.5 man page, and to the newsyslog.c source file as lower case.

I then went and looked into NetBSD's source, and they have ALL of the
newsyslog.conf flags they support listed in their man page as lowercase, but in
their newsyslog.c, they convert those flags to uppercase before checking them
in a switch statement, which is the opposite of what FreeBSD is doing.

Digging further back, I think it's around NetBSD 1.6 is when support for those
flags even first appeared, including 'p'.  In that version, in newsyslog.c,
NetBSD checks for lowercase flags.  On 2007-21-12. when NetBSD was at v5.0, the
'J' flag was added to NetBSD's newsyslog.c by @dogcow, and at that time is when
they modified the switch logic to check for uppercase flags, but added the 'J'
flag to the man page as lowercase 'j', and did not leave a reasoning on these
differences in their commit message:
https://anonhg.netbsd.org/src/rev/e97bbfc29eff

Which is correct?  Both, technically!  Historically, lowercase letters were
first, in both NetBSD's man pages and source.  Then the source later got
updated to check the flags as uppercase values, but the man page still, to this
day, references lower case.  FreeBSD, on the other hand, is using uppercase
flags in its newsyslog.conf(5) man page and config examples, except for 'p',
but checks the flags as all lower case, which was the original logic from
NetBSD.  I assume that when the code for the 'p' flag was copied from NetBSD
and brought into FreeBSD, @eadler either didn't notice such a small nit, or
didn't care.  Both upper and lowercase flag values are technically valid,
because in either OS, the values are forced into one or the other case before
being checked.

If y'all want, I have no problem leaving the flag in the man page as-is as a
historical curiosity for someone to find again in the future.  Or, the patch
can be accepted and the flag changed to uppercase in FreeBSD's man page for
consistency with the other flags.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 279303] usr.sbin/newsyslog: Fix case of the 'P' flag in newsyslog.conf's manpage

2024-05-26 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279303

--- Comment #3 from Joshua Kinard  ---
(In reply to Ed Maste from comment #2)

The switch statement is changing the flag characters to lower case before it
checks them:

> for (; q && *q && !isspacech(*q); q++) {
> switch (tolowerch(*q)) {
> case 'b':
> working->flags |= CE_BINARY;
> break;
> case 'c':
> working->flags |= CE_CREATE;
> break;
In the man page, 'p' is the only config flag that's lowercase, which is why I
am assuming that it's the typo.  If it's the other way around and lowercase is
supposed to be the correct format, then there's fourteen typos for the other
uppercased flags that have gone unnoticed for a long time instead of one :)

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 279303] usr.sbin/newsyslog: Fix case of the 'P' flag in newsyslog.conf's manpage

2024-05-26 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279303

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #2 from Ed Maste  ---
Lower case 'p' is correct it seems, from newsyslog.c:

#define CE_PLAIN0   0x0800  /* Do not compress zero'th history file */

case 'p':
working->flags |= CE_PLAIN0;
break;

-- 
You are receiving this mail because:
You are the assignee for the bug.


Problem reports for b...@freebsd.org that need special attention

2024-05-26 Thread bugzilla-noreply
To view an individual PR, use:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).

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

Status  |Bug Id | Description
+---+---
New |252123 | fetch(3): Fix wrong usage of proxy when request i 
New |262764 | After DVD1 13.0-R install with ports tree, portsn 
New |262989 | sys/conf/files, sys/conf/options, sys/conf/NOTES: 
New |269994 | build options have different kernel and userland  
New |276571 | makefs(8) creates broken UFS images with sectorsi 
New |276985 | crash in LinuxKPI/drm 
Open| 46441 | sh(1): Does not support PS1, PS2, PS4 parameter e 
Open|177821 | sysctl: Some security.jail nodes are funky, dupli 
Open|220246 | syslogd does not send RFC3164-conformant messages 
Open|250309 | devmatch: panic: general protection fault: sysctl 
Open|255130 | Issue with rtsx driver
Open|256952 | kqueue(2): Improve epoll Linux compatibility (com 
Open|257149 | CFLAGS not passed to whole build  
Open|257646 | opensm: rc service is installed by default, but o 
Open|258665 | lib/libfetch: Add Happy Eyeballs (RFC8305) suppor 
Open|259292 | vmware/pvscsi: UNMAP fails on VMWare 6.7 thinly p 
Open|259636 | multiple components: Change "Take Affect" to "Tak 
Open|259655 | periodic: security/security.functions does not re 
Open|259703 | In sys/dev/pci/pci.c, error in do_power_nodriver  
Open|259808 | etc/periodic/daily/100.clean-disks: Fix error (Di 
Open|260245 | swap/vm: Apparent memory leak: 100% swap usage
Open|261640 | sysctl: Add -F option to display sysctl format st 
Open|261641 | drm-kmod: Launch message is written into (possibl 
Open|261771 | nvme(4): Reports errors every 5 minutes: PRP OFFS 
Open|261971 | kernel crash launching bhyve guest on ZFS: #15 bu 
Open|262157 | su+j: Crashes during mmc(4) fsck after timeout: E 
Open|262192 | Crashes at boot with kern.random.initial_seeding. 
Open|264028 | loader: Incorrect (32gb) memory reported by BTX l 
Open|264075 | freebsd-update in 13.1-RELEASE detects an install 
Open|264188 | kinit(1): Ignores KRB5CCNAME environment variable 
Open|264226 | setting kern.vty=sc causes hang during UEFI boot  
Open|264757 | fetch: Show correct port number in -vv output 
Open|264833 | 12.3-STABLE panic on sync and reboot: panic: slee 
Open|266419 | mrsas: Corrupts memory (crashes) when reading dat 

34 problems total for which you should take action.


[Bug 279285] no sound on stable/14 with vchans disabled and bitperfect setup.

2024-05-26 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285

--- Comment #10 from Christos Margiolis  ---
(In reply to Oleh Vinichenko from comment #8)
So, I have one or two commits after 8771127d75a1295dd32abd0022ff3750bc564706 in
mind that could potentially be the culprit, but I want to ask the following
first:

1. Do you get sound with VCHANs and without bitperfect?
2. Is there any message related to the problem, popping up on dmesg(8) once the
device is attached? Perhaps you can attach the output of dmesg(8) after a
verbose boot.
3. Is it a specific application that breaks or do you not have sound in
general?
4. Can you provide /dev/sndstat with hw.snd.verbose=2 set?

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 279285] no sound on stable/14 with vchans disabled and bitperfect setup.

2024-05-26 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285

--- Comment #9 from Oleh Vinichenko  ---
also, are the commits related, or independent of each other? in latter case it
make sense to go through every commit one by one.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 279285] no sound on stable/14 with vchans disabled and bitperfect setup.

2024-05-26 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285

--- Comment #8 from Oleh Vinichenko  ---
unfortunately, very latest changes did not change the situation. i will start
reverting of /usr/src before commit 8771127d75a1295dd32abd0022ff3750bc56470 is
there more robust way of doing it? because i need to recompile every commit to
sound system and reboot each time. it is not a problem simply too laborious.

-- 
You are receiving this mail because:
You are the assignee for the bug.