[Bug 279268] [patch] xdm dies when pressing CTRL-C if pam_xdg.so is used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279268 Emmanuel Vadot changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed --- Comment #2 from Emmanuel Vadot --- Commited, thanks a lot. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279268] [patch] xdm dies when pressing CTRL-C if pam_xdg.so is used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279268 --- Comment #1 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=cca0ce62f367d03ed429bf99e41e6aca8cb7f2ac commit cca0ce62f367d03ed429bf99e41e6aca8cb7f2ac Author: Andre Albsmeier AuthorDate: 2024-05-27 06:31:34 + Commit: Emmanuel Vadot CommitDate: 2024-05-27 06:33:14 + pam_xdg: pam_get_item can return NULL Fix pam_xdg as pam_get_item can return NULL, this happens when pressing control + C in xdm for example. MFC after: 1 week PR: 279268 lib/libpam/modules/pam_xdg/pam_xdg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 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.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279285 --- Comment #11 from Oleh Vinichenko --- i was too early in my conclusions about sound changes are root cause of a problem. in reality, the problem is suspend. when sound card is taken by an application such as musicpd and notebook is then goes into suspend state, either by `zzz` or lid close, upon returning back from suspend, there is no sound. the symptom is as if sound is completely muted, there is no error from application, nothing in dmesg. it keeps playing as before but with no output. i think this report can be closed as not valid. i will probably file new one based on new observations. -- 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
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
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
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
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
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
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
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.
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.
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.
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.