Re: MOTD is not created correctly (since 2022/02/18)
On 22 May 2023, at 23:18, Jamie Landeg-Jones wrote: I've just finally updated to 13-stable, and can't be the first to notice this?! /etc/rc.d/motd contains the line: uname -v | sed -e 's,^\([^#]*\) #\(.* [1-2][0-9][0-9][0-9]\).*/\([^\]*\) $,\1 (\3) #\2,' Note the space before the "$" - needed because the uname -v output used to have a trailing space. This was fixed and comitted on 2022/02/18: https://cgit.freebsd.org/src/commit/usr.bin/uname/uname.c?id=7e05fa3b449007adaa6e588ebb3b8d76f30b355c Since then, the sed doesn't match, so the uname(1) output is unchanged. There's no point altering the sed to work with both possibilities, so can someone commit the fix of removing the ' ' before the '$' in /etc/rc.d/motd ? Not that it helps you much, but I did notice it and have an alternate version of rc.d/motd on my own systems. I had no particular attachment to the earlier format, so my motd starts out by printing the two lines of: ``` -KU 1302505 1302505 -b 18fa15f83c483db67b818e3a48bbb312908754b1 FreeBSD 13.2-STABLE (Garance-13x) #0 -- Fri May 5 17:53:55 EDT 2023 ``` (that first line is the output from ```printf '-KU %s -b %s\n' "$(uname -KU)" "$(uname -b)"``` ) But I thought that committing that would trigger a bikeshed debate, so I also have an option to produce the output we previously had. And given that no one seemed to be complaining about the "full uname" version, I figured I had an option for that too. And then I thought all these options were overkill and would trigger and even longer debate, so I never brought the ideas forward. :) -- Garance Alistair Drosehn= dro...@rpi.edu Lead Developer @rpi andg...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA
Re: OpenSSL breaks factor(6)
On 29 Dec 2019, at 2:17, Steve Kargl wrote: > On Sun, Dec 29, 2019 at 01:34:28AM -0500, Garance A Drosehn wrote: >>> >>> An interested user will need to add that support. AFAIK, factor(6) >>> has never recognized the 0x prefix, and I'm not trying to add new >>> features. I'm simply fixing factor(6) to match its documentation, >>> and trying to ensure WITH_OPENSSL and WITHOUT_OPENSSL give the >>> same results where applicable. >> >> Well, I'd be willing to do the work to add the new feature, and also >> make the commit. It'd be a nice easy task for me to tackle... :) >> >> But I think documenting that "hex works, but only for hex values >> which have at least one A-F in the value" is not something that I'd >> want to draw attention to via documentation. >> > > You have a 17 year history to worry about as hexadecimal support > was added by "r104720 | fanf | 2002-10-09". Compiling factor(6) > with and without OpenSSL support after 2002-10-09 gives a utility > with different inconsistent behavior. If I understand you right, that behavior has not been documented for 17 years. If it continues to be un-documented, that cannot possibly break any scripts. I'm not saying we should remove the behavior, I'm just saying we don't need to document it. Especially not if we add support for a better way to specify hex values. On 29 Dec 2019, at 1:50, Steve Kargl wrote: > >Do what you want with the patch (including ignoring it). >Hopefully, someone in the FreeBSD project will now >recognize that factor(6) with and without OpenSSL gives >inconsistent results, and neither matches factor(6)'s >manpage. Oh. I tend to lose track with who is and isn't a src-committer on FreeBSD. I've seen your name enough that I assumed you were one. If you're not, I can handle committing these changes, including the new feature. That'll keep my commit bit alive for another year! -- Garance Alistair Drosehn = dro...@rpi.edu or g...@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: OpenSSL breaks factor(6)
On 29 Dec 2019, at 0:10, Steve Kargl wrote: > On Sat, Dec 28, 2019 at 10:46:52PM -0500, Garance A Drosehn wrote: >> >> What if the user wants to factor a hexadecimal value which does not >> happen to include [a...f]? >> >> How about recognizing a prefix of '0x' as a way to indicate the value >> is hexadecimal? > > An interested user will need to add that support. AFAIK, factor(6) > has never recognized the 0x prefix, and I'm not trying to add new > features. I'm simply fixing factor(6) to match its documentation, > and trying to ensure WITH_OPENSSL and WITHOUT_OPENSSL give the > same results where applicable. Well, I'd be willing to do the work to add the new feature, and also make the commit. It'd be a nice easy task for me to tackle... :) But I think documenting that "hex works, but only for hex values which have at least one A-F in the value" is not something that I'd want to draw attention to via documentation. -- Garance Alistair Drosehn = dro...@rpi.edu or g...@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: OpenSSL breaks factor(6)
On 27 Dec 2019, at 17:42, Steve Kargl wrote: > > This patch now includes a fix for hexadecimal conversion. It > simple scans the string for a hex digit in [a,...,f] and assumes > that a hexadecimal string has been entered. A string that includes > character from the decimal digits is assumed to by a decimal > representation. What if the user wants to factor a hexadecimal value which does not happen to include [a...f]? How about recognizing a prefix of '0x' as a way to indicate the value is hexadecimal? -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ 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: Does someone keep track of how long it takes to buildworld/kernel?
On 13 Jan 2017, at 17:27, Garance A Drosehn wrote: > On 13 Jan 2017, at 15:23, Eric Joyner wrote: > >> ^ Message ^ >> >> It takes forever, but I keep on forgetting to time how long it takes, >> so I don't know how long "forever" is. > > I do build on older hardware, so it takes a long time. (hours, iirc) Here's some sample stats from a build of 9.3-stable back in May: start=2016-0505-15:30:49real=9531.41user=7850.36sys=920.24 duration=9531 outsize=27322524 target='buildworld' start=2016-0505-18:09:53real=1713.81user=1323.83sys=162.50 duration=1713 outsize=4611462 target='buildkernel' start=2016-0505-18:38:32real=41.59 user=13.56 sys=4.68 duration=41 outsize=119067 target='installkernel' start=2016-0505-18:42:38real=161.52 user=35.09 sys=17.70 duration=161 outsize=1235184 target='installworld' -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ 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: Does someone keep track of how long it takes to buildworld/kernel?
On 13 Jan 2017, at 15:23, Eric Joyner wrote: > ^ Message ^ > > It takes forever, but I keep on forgetting to time how long it takes, > so I don't know how long "forever" is. I have scripts which do buildworld's for me, and they keep all kinds of extra information for each step (buildkernel, installkernel, buildworld, installworld). Unfortunately I haven't been building world very much lately, and I haven't built anything on release-11. I do build on older hardware, so it takes a long time. (hours, iirc) -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ 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: HEADS-UP: installworld on r299292 through r299317 will replace master.passwd, passwd, and group files
On 10 May 2016, at 2:24, Glen Barber wrote:
> On Tue, May 10, 2016 at 08:18:44AM +0200, O. Hartmann wrote:
>>
>> It is not only master.passwd, it is also group and several other
>> config files, I suspect it is the whole bunch of files located
>> in /etc/ getting reset to their initial file values.
>>
>> My OpenLDAP environment isn't working anymore due to /etc/pam.d
>> reset. X11 doesn't start anymore due to reset of /etc/ttys. also,
>> sysctl.conf has been reset.
>
> The change (incorrectly) invoked the 'distribution' target, so
> anything that gets "touched" by that will likely be affected.
>
> You are correct that we should have an additional failsafe for
> this kind of thing, not just a subset of files arbitrarily placed
> in /var/backups via a periodic(8) script.
Hmm. When working on some non-BSD open-source system, I found it
prudent to backup /etc. And I'm lazy, so I went with a simple
tactic of:
MLET=$(awk -v "MDIG=$(date +%m)" \
'BEGIN { print substr("ABCDEFGHJKLMxyz", MDIG, 1); }')
ETCTARNAME="/tmp/$(hostname -s)-etc-$(date +%Y${MLET}%d).tbz2"
ETCLNKNAME="etc-$(hostname -s)-$(date +%Y${MLET}%d)"
cd /
ln -s etc "$ETCLNKNAME"
nice tar cjf "$ETCTARNAME" "$ETCLNKNAME"/*
scp -p "$ETCTARNAME" $ETCSAV_DEST:Downloads/SAV-etcs
rm -f "$ETCTARNAME" "$ETCLNKNAME"
The idea is to create a symlink of etc which includes a timestamp
(eg: "etc-freefall-2016E10"), and create a compressed tar archive
which saves all the files as being under that directory-name instead
of /etc. I then copy that to a different host, and remove the
archive file. Maybe I should add something like that to my own
installworld script. Probably should adjust it somewhat to pay
better attention to potential security issues. (you wouldn't want
to copy that archive file to a public FTP server, for instance!)
Then when something goes haywire, I would create a new archive
and then compare the two complete sets of /etc files to see what
has changed.
--
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY; USA
___
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"
libXO-ification - tangent on JSON choices
First let me say that I wish I had more time to contribute to the project, but I seem to be caught in variety of long drawn-out hassles in real-life. Otherwise I would already know the answer to this question: Is there some specification for what JSON is created by the various FBSD utilities? I did not see any discussion of that in the earlier threads on this. I don't mean "what is syntatically correct JSON?", I mean some kind of guidelines of what property-names would be used across commands, and what values should be for those properties. I came across the following project while watching a series of videos on youtube. I think I started out watching something about Clojure, or ruby, or d-lang, and ended up at this: http://jsonapi.org/ http://jsonapi.org/format/ And I must admit I haven't even taken the time to read the whole spec, but what I did read seemed interesting. It doesn't cover much, so I'd expect a spec for freebsd command outputs would need to be more detailed. Is there such a spec already written up, at least in a rough outline? -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ 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: mtree patch for WITHOUT_LPR
On 7 Nov 2015, at 6:08, Dmitry Morozovsky wrote: as you're still maintaining lpr, I'm passing this through you. If one build his server WITHOUT_LPR, there are constantly few directories that are created by make hierarchy and then reported my make check-old. Attached is a small patch against -current that should eliminate it (inspired by BSD.groff.mtree). Your thoughts? Thanks for checking with me. While I've done a lot with 'lpr', I have not done much of anything with mtree files. After having read through the rest of this thread, I have the impression that we're no longer interested in a separate mtree subfile for 'lpr'. Instead we'll go with Brian's observation that: "if a directory is in the dist mtrees, it should not be listed as an OLD_DIRS." Am I correct in thinking that? -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ 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: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/
On 30 Oct 2014, at 12:49, Ed Maste wrote: On 30 October 2014 02:20, John-Mark Gurney j...@funkthat.com wrote: Oh, make sure that make install (or installkernel) properly handles moving the debug data too... i.e. kernel to kernel.old... Yes, in the case that /boot/kernel is moved to /boot/kernel.old /usr/lib/debug/boot/kernel is moved to /usr/lib/debug/boot/kernel.old. I definitely like the idea of moving the debug symbols out to /usr/lib/debug I'm another person who sometimes has multiple kernels sitting in /boot (which is one reason I'd like the debug symbols elsewhere!). I may shuffle those around by hand, and I'm sure I won't remember to shuffle around information under /usr/lib/debug. I also do things like cp -rp kernel kernel-PreBigChange where I save away a copy of the kernel for possible fallback (at some unknown future date), but I wouldn't need two copies of the debug info. When we build a kernel, could we tag it with some unique-ID (by putting that ID in a plain-text file inside the kernel's directory), and then that unique-ID could be used for finding the correct debug info under /usr/lib/debug? This way we wouldn't need to move around any of the debug info under /usr/lib/debug. And we could tell which sets of debug info should be removed by comparing the existing sets of debug info with the kernel-unique-ID's which still exist under /boot. If debug tools need to have the debug-info for the booted kernel to be in a fixed location, then maybe the boot-up process could create a symlink from some fixed pathname to the correct debug info for the kernel which the system booted up on. -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ 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: newsyslog patch implementing file includes
At 10:15 AM +0100 4/22/10, krad wrote: On 22 April 2010 08:33, Alex Keda ad...@lissyara.su wrote: 22.04.2010 11:29, Gordon Tetlow ?: On Thu, Apr 22, 2010 at 12:17 AM, Alex Keda ad...@lissyara.su mailto: ad...@lissyara.su wrote: It's need feature. I test patch - it work for me (CURRENT, amd64) Can I use some as: include /path/to/dir/*.conf ? and can I create recursive include? Yes, wildcards and recursive includes are supported. great job! Thanks! I also think this is a great feature to add. Just to be clear: This allows a config file to include some other file, and that other file can also include more files with additional newsyslog entries. In that sense it allows recursive includes. Note that it will detect when such recursion causes one file to end up indirectly including itself, and will reject *that* situation. So you shouldn't be able to get into an infinite loop of included files. i would be real nice is newsyslog also supported a date based file renaming shceme rather than the cyclic 0,1,2,3, much like the datext option in logrotate. eg messages messages.20100422 messages.20100421 messages.20100420 ... The cyclic renaming is a pain for incremental backups as all the log files are backed up every time as their contents changes compared to their filename I hope to do this after Gordon commits the new feature that he's implemented. I know I've said that before, but I do have some vacation time coming up soon and expect to do it then. -- Garance Alistair Drosehn = dros...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ 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: COMPAT_IA32 renamed COMPAT_FREEBSD32
At 12:59 PM -0600 3/12/10, Mark Linimon wrote: On Fri, Mar 12, 2010 at 09:22:55AM -0800, David O'Brien wrote: Yes it is. Where was it discussed first? I do not see anything in my freebsd-arch or freebsd-current archive; or any other FreeBSD list. http://docs.freebsd.org/cgi/mid.cgi?4B971CA3.9090301 crossposted on amd64@, ia64@, emulat...@. While those are logical mailing lists for this topic to have come up on, it shouldn't be much of a surprise that there are many freebsd users and committers who are not on those lists. Many people who do know about the existing COMPAT_FREEBSD* variables, and thus will be surprised at this variable name. My understanding is that there has already been a lot of furor over this name, so let me first say I don't mean to infuriate anyone. However, my own vote would be for some other name than COMPAT_FREEBSD32. -- Garance Alistair Drosehn = dros...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ 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: Nt source licenses...
At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: Are we going to get this license? I am interested in NTFS source code a lot... I would be very careful about getting an NT source license if your intention is to write NTFS support for some other operating system. Microsoft is not doing this licensing for the benefit of mankind, they are doing it to attract college-type users to sticking with WinNT over open-source unixes. The last thing we need is some code from WinNT which causes us to be sued by Microsoft... --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer(MIME NeXTmail capable) Rensselaer Polytechnic Institute; Troy NYUSA To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
