Re: svn commit: r345138 - head/share/man/man9
> > In message <201903150152.x2f1q34w027...@gndrsh.dnsmgr.net>, "Rodney W. > Grimes" > writes: > > >> The first versions of CTM used diff -e and ed(1) to transmit changes, > >> and that choked up on binary files. We didn't have patch in the > >> tree back then. > > >patch has always been in the tree. > >https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/usr.bin/patch > > Yes, in *that* tree, but it was not always in *our* tree, particularly > not in the strange time between 1.1.5.1 and 2.0. I would have to go find the 4.4BSD-Lite2_import.sh script, but I would of either imported the one from 4.4, or I would of imported the gnu one into gnu/. > Trust me: if it had been, I would not have used diff-e+ed(1) It would of been pretty impossible to live without patch at that time so I doubt very much that the respository had it missing for more than a day or three, there was the time period from the import of 4.4 to the completion of the 2.0 ncvs repository, though that was only days, the there was the lag while we waited for Greenman/Dyson to fix the missing bits and to get make world running again, but after that we would of had the same patch we had in 1.x as that is external code and uneffected by the lawsuit. > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
In message , Andrew Gallatin writes: >On 3/14/19 11:36 PM, Rodney W. Grimes wrote: >> [ Charset UTF-8 unsupported, converting... ] >>> On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes >>> wrote: 4. There is no easy way to show "changed byte at offset 0x432 from 0xef to 0xfe" >> >> How do we represent Copyright and License in such objects? >> This is an issue that is totally left out of even .uu version. I am pretty sure that some of the .uu files had copyrights in them at various points, but yes, good point. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On 3/14/19 11:36 PM, Rodney W. Grimes wrote: [ Charset UTF-8 unsupported, converting... ] On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes wrote: 4. There is no easy way to show "changed byte at offset 0x432 from 0xef to 0xfe" How do we represent Copyright and License in such objects? This is an issue that is totally left out of even .uu version. This is an excellent point. What I used to do for mxge firmware when I worked at Myricom was to have a shell script that created a source file with the uuencoded bits as a static array. That way, it had copyright info in the file itself. Drew ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Fri, 15 Mar 2019, Poul-Henning Kamp wrote: In message <201903150152.x2f1q34w027...@gndrsh.dnsmgr.net>, "Rodney W. Grimes" writes: The first versions of CTM used diff -e and ed(1) to transmit changes, and that choked up on binary files. We didn't have patch in the tree back then. patch has always been in the tree. https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/usr.bin/patch Yes, in *that* tree, but it was not always in *our* tree, particularly not in the strange time between 1.1.5.1 and 2.0. Trust me: if it had been, I would not have used diff-e+ed(1) patch has been in the tree since FreeBSD.1.1. It was gnu patch, so it had an unbroken history through the transition to 2.0. From a FreeBSD-5.2 repository: XX RCS file: /home/ncvs/src/gnu/usr.bin/patch/patch.c,v XX Working file: patch.c XX head: 1.21 XX branch: XX locks: strict XX access list: XX symbolic names: XX RELENG_4_10_0_RELEASE: 1.16.2.4 XX RELENG_4_10: 1.16.2.4.0.6 XX RELENG_4_10_BP: 1.16.2.4 XX RELENG_5_2_1_RELEASE: 1.21 XX RELENG_5_2_0_RELEASE: 1.21 XX RELENG_5_2: 1.21.0.6 XX RELENG_5_2_BP: 1.21 XX RELENG_4_9_0_RELEASE: 1.16.2.4 XX RELENG_4_9: 1.16.2.4.0.4 XX RELENG_4_9_BP: 1.16.2.4 XX RELENG_5_1_0_RELEASE: 1.21 XX RELENG_5_1: 1.21.0.4 XX RELENG_5_1_BP: 1.21 XX RELENG_4_8_0_RELEASE: 1.16.2.4 XX RELENG_4_8: 1.16.2.4.0.2 XX RELENG_4_8_BP: 1.16.2.4 XX RELENG_5_0_0_RELEASE: 1.21 XX RELENG_5_0: 1.21.0.2 XX RELENG_5_0_BP: 1.21 XX RELENG_4_7_0_RELEASE: 1.16.2.3 XX RELENG_4_7: 1.16.2.3.0.4 XX RELENG_4_7_BP: 1.16.2.3 XX RELENG_4_6_2_RELEASE: 1.16.2.3 XX RELENG_4_6_1_RELEASE: 1.16.2.3 XX RELENG_4_6_0_RELEASE: 1.16.2.3 XX RELENG_4_6: 1.16.2.3.0.2 XX RELENG_4_6_BP: 1.16.2.3 XX RELENG_4_5_0_RELEASE: 1.16.2.1 XX RELENG_4_5: 1.16.2.1.0.6 XX RELENG_4_5_BP: 1.16.2.1 XX RELENG_4_4_0_RELEASE: 1.16.2.1 XX RELENG_4_4: 1.16.2.1.0.4 XX RELENG_4_4_BP: 1.16.2.1 XX RELENG_4_3_0_RELEASE: 1.16.2.1 XX RELENG_4_3: 1.16.2.1.0.2 XX RELENG_4_3_BP: 1.16.2.1 XX RELENG_4_2_0_RELEASE: 1.16.2.1 XX RELENG_4_1_1_RELEASE: 1.16.2.1 XX PRE_SMPNG: 1.18 XX RELENG_4_1_0_RELEASE: 1.16 XX RELENG_3_5_0_RELEASE: 1.14.2.1 XX RELENG_4_0_0_RELEASE: 1.16 XX RELENG_4: 1.16.0.2 XX RELENG_4_BP: 1.16 XX RELENG_3_4_0_RELEASE: 1.14.2.1 XX RELENG_3_3_0_RELEASE: 1.14.2.1 XX RELENG_3_2_PAO: 1.14.0.4 XX RELENG_3_2_PAO_BP: 1.14 XX RELENG_3_2_0_RELEASE: 1.14 XX RELENG_3_1_0_RELEASE: 1.14 XX RELENG_3: 1.14.0.2 XX RELENG_3_BP: 1.14 XX RELENG_2_2_8_RELEASE: 1.6.6.3 XX RELENG_3_0_0_RELEASE: 1.14 XX RELENG_2_2_7_RELEASE: 1.6.6.3 XX RELENG_2_2_6_RELEASE: 1.6.6.3 XX RELENG_2_2_5_RELEASE: 1.6.6.1 XX RELENG_2_2_2_RELEASE: 1.6.6.1 XX RELENG_2_2_1_RELEASE: 1.6.6.1 XX RELENG_2_2_0_RELEASE: 1.6 XX RELENG_2_1_7_RELEASE: 1.6.4.1 XX RELENG_2_1_6_1_RELEASE: 1.6.4.1 XX RELENG_2_1_6_RELEASE: 1.6.4.1 XX RELENG_2_2: 1.6.0.6 XX RELENG_2_2_BP: 1.6 XX RELENG_2_1_5_RELEASE: 1.6.4.1 XX RELENG_2_1_0_RELEASE: 1.6 XX RELENG_2_1_0: 1.6.0.4 XX RELENG_2_1_0_BP: 1.6 XX RELENG_2_0_5_RELEASE: 1.6 XX RELENG_2_0_5: 1.6.0.2 XX RELENG_2_0_5_BP: 1.6 XX RELENG_2_0_5_ALPHA: 1.5 XX RELEASE_2_0: 1.4 XX BETA_2_0: 1.4 XX ALPHA_2_0: 1.4.0.2 XX MOVED_NEWCVS: 1.4 XX FINAL_1_1_5: 1.4 XX ALPHA_1_1_5: 1.4 XX FINAL_1_1: 1.3 XX GAMMA_1_1: 1.3 XX BETA_1_1: 1.3.0.2 XX BP_BETA_1_1: 1.3 XX FINAL_1_0: 1.1.1.1 XX EPSILON_1_0: 1.1.1.1 XX GAMMA_1_0: 1.1.1.1 XX BETA_1_0: 1.1.1.1 XX ALPHA_1_0: 1.1.1.1 XX V2_10: 1.1.1.1 XX keyword substitution: kv XX total revisions: 33; selected revisions: 33 XX description: XX XX revision 1.21 XX date: 2002/10/13 01:18:33; author: kris; state: Exp; lines: +7 -6 XX Prevent stack-smashing buffer overflows in -D and -r options by using XX buffer-safe string functions. The rest of the code is still probably XX unsafe. XX XX MFC after: 1 week XX ... XX XX revision 1.2 XX date: 1994/02/17 22:16:03; author: jkh; state: Exp; lines: +21 -7 XX From Poul-Henning Kamp - Implement a -C option to verify the integrity of XX a patch before actually applying it. XX XX revision 1.1 XX date: 1993/06/19 14:21:51; author: paul; state: Exp; XX branches: 1.1.1; XX Initial revision XX XX revision 1.1.1.1 XX date: 1993/06/19 14:21:52; author: paul; state: Exp; lines: +0 -0 XX b-maked patch-2.10 XX I don't know how to find the old history using svn. svn log doesn't show removed files. It is hard to find where the files were unless you already know the history. svn log on stable/5/gnu/usr.bin/patch/patch.c only shows history on t
Re: svn commit: r345138 - head/share/man/man9
In message <201903150152.x2f1q34w027...@gndrsh.dnsmgr.net>, "Rodney W. Grimes" writes: >> The first versions of CTM used diff -e and ed(1) to transmit changes, >> and that choked up on binary files. We didn't have patch in the >> tree back then. >patch has always been in the tree. >https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/usr.bin/patch Yes, in *that* tree, but it was not always in *our* tree, particularly not in the strange time between 1.1.5.1 and 2.0. Trust me: if it had been, I would not have used diff-e+ed(1) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
Before all of the uuencoded files get decoded in the tree.. are we sure that non-uuencoded binary files will be proper identified if the mime type is nonexistent in svn? What about other VCSes like hg? I’m asking, because not all downstream vendors have the newest versions of svn, once upon a time, may have mashed mime types, etc, which may have interesting downstream effects if the binary type isn’t detected properly. Thank you, -Enji ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
> On Mar 14, 2019, at 20:26, Warner Losh wrote: > > > >> On Thu, Mar 14, 2019 at 9:14 PM Ed Maste wrote: >> On Thu, 14 Mar 2019 at 22:46, Warner Losh wrote: >> > >> > Libarchive tests and a few bzip2 files are all that is left in contrib. >> > All can be converted without hassle from what I can see. >> >> But these (libarchive at least) are uuencoded in the upstream repo, >> and we won't make a local change to undo that. Perhaps libarchive's >> upstream developers will decide that there's no need to uuencode the >> test files any longer, though > > Fair enough, I didn't check upstream. I'd have thought that libarchive was > new enough, but I concur: if they are upstream that way, then it's fine. So > it looks like we're down to a few stragglers that are still uuencoded, but we > don't need to do that any more. And there's hundreds of files in the tree > that are binaries already. Libarchive implements uuencode file type detection, FYI. -Enji ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, Mar 14, 2019 at 9:36 PM Rodney W. Grimes wrote: > [ Charset UTF-8 unsupported, converting... ] > > On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes > > wrote: > > > > > > 4. There is no easy way to show > > >"changed byte at offset 0x432 from 0xef to 0xfe" > > How do we represent Copyright and License in such objects? > This is an issue that is totally left out of even .uu version. > By indirect means. Usually an auxiliary file that describes permissions, when we bother at all. Warner > > But this is not that easy with uuencoded files, either - I'd just end > > up uudecoding both files before running cmp -x. And for the case under > > discussion here (firmware files) we treat them as opaque binary > > objects; comparing them is generally not interesting anyway. > > > > > Do we have a decent binary diff and binary patch tool? > > > > We have bsdiff and bspatch, but their output is not designed for human > > consumption or editing. > > > > -- > Rod Grimes > rgri...@freebsd.org > > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, Mar 14, 2019 at 9:31 PM Ed Maste wrote: > On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes > wrote: > > > > 4. There is no easy way to show > >"changed byte at offset 0x432 from 0xef to 0xfe" > > But this is not that easy with uuencoded files, either - I'd just end > up uudecoding both files before running cmp -x. And for the case under > discussion here (firmware files) we treat them as opaque binary > objects; comparing them is generally not interesting anyway. > All binaries in the tree are versioned opaque objects. #4 isn't a use case we care about, nor is it something we can to today. > > Do we have a decent binary diff and binary patch tool? > > We have bsdiff and bspatch, but their output is not designed for human > consumption or editing. > IIRC, git also has a way to transition from one binary to another in an externalized fashion. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
[ Charset UTF-8 unsupported, converting... ] > On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes > wrote: > > > > 4. There is no easy way to show > >"changed byte at offset 0x432 from 0xef to 0xfe" How do we represent Copyright and License in such objects? This is an issue that is totally left out of even .uu version. > But this is not that easy with uuencoded files, either - I'd just end > up uudecoding both files before running cmp -x. And for the case under > discussion here (firmware files) we treat them as opaque binary > objects; comparing them is generally not interesting anyway. > > > Do we have a decent binary diff and binary patch tool? > > We have bsdiff and bspatch, but their output is not designed for human > consumption or editing. > -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes wrote: > > 4. There is no easy way to show >"changed byte at offset 0x432 from 0xef to 0xfe" But this is not that easy with uuencoded files, either - I'd just end up uudecoding both files before running cmp -x. And for the case under discussion here (firmware files) we treat them as opaque binary objects; comparing them is generally not interesting anyway. > Do we have a decent binary diff and binary patch tool? We have bsdiff and bspatch, but their output is not designed for human consumption or editing. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, Mar 14, 2019 at 9:14 PM Ed Maste wrote: > On Thu, 14 Mar 2019 at 22:46, Warner Losh wrote: > > > > Libarchive tests and a few bzip2 files are all that is left in contrib. > All can be converted without hassle from what I can see. > > But these (libarchive at least) are uuencoded in the upstream repo, > and we won't make a local change to undo that. Perhaps libarchive's > upstream developers will decide that there's no need to uuencode the > test files any longer, though Fair enough, I didn't check upstream. I'd have thought that libarchive was new enough, but I concur: if they are upstream that way, then it's fine. So it looks like we're down to a few stragglers that are still uuencoded, but we don't need to do that any more. And there's hundreds of files in the tree that are binaries already. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, 14 Mar 2019 at 22:46, Warner Losh wrote: > > Libarchive tests and a few bzip2 files are all that is left in contrib. All > can be converted without hassle from what I can see. But these (libarchive at least) are uuencoded in the upstream repo, and we won't make a local change to undo that. Perhaps libarchive's upstream developers will decide that there's no need to uuencode the test files any longer, though. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, 14 Mar 2019 at 22:34, Rodney W. Grimes wrote: > > > We definitely don't want to change files in contrib/ - that's up to > > the upstreams. > > I think you miss understood, I belive in the paste, and possibly even > still, that prep work was done to vendor code before import. We use > to have shell scripts and such to deal with things like having to > .uu files, remove stuff you dont want, etc. Ah, I did misunderstand what you meant. Those sorts of scripts/processes are unique per vendor tree; uuencoding steps could be removed from any that have it (along with changes to our build infrastructure). I have a subset of the vendor tree checked out locally and none of the FreeBSD-Upgrade files I have reference uuencoding -- but I did not check everything. Note that we already have several vendor src trees that have verbatim binary files - for one example, contrib/file/tests/JW07022A.mp3.testfile. > I suspect some of that is inplace and we probably do not want to just > undo it without some careful thought. Fair point; I would leave process changes for vendor/contrib to the individual maintainers. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, Mar 14, 2019, 8:35 PM Rodney W. Grimes wrote: > > On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes > > wrote: > > > > > > Covered this in my reply to Warners reply. I think we also need to > > > look at how this might affect vendor imported stuff, is there some if > > > it that was .uu'ed before import? > > > > We definitely don't want to change files in contrib/ - that's up to > > the upstreams. > > I think you miss understood, I belive in the paste, and possibly even > still, that prep work was done to vendor code before import. We use > to have shell scripts and such to deal with things like having to > .uu files, remove stuff you dont want, etc. > > I suspect some of that is inplace and we probably do not want to just > undo it without some careful thought. > Libarchive tests and a few bzip2 files are all that is left in contrib. All can be converted without hassle from what I can see. Anything that used to be done seems to be gone. Sys/config only has firmware in it, none of which is native format. Some of which can be converted, but there are build fixes that would be needed too. Warner > -- > Rod Grimes > rgri...@freebsd.org > > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
> On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes > wrote: > > > > > The reason not to do it is uuencoding adds about a 40% space penalty, > > > adds to the build time (to uudecode), and makes changes harder to > > > review. In my mind dropping the unnecessary uuencoding is similar to > > > dropping build-time patching of files in the source tree (another > > > workaround we used to have for limitations of our older VCS). > > > > I think I covered all the above in other replies. > > So: > 1. We used to use a VCS which does not support binary files well, but > have not used it for years. > 2. Another source delivery tool (ctm) previously did not support > binary files, but has for some time. > 3. There may have been other reasons, but none that anyone can recall > (at present). 4. There is no easy way to show "changed byte at offset 0x432 from 0xef to 0xfe" So far, that looks right. Do we have a decent binary diff and binary patch tool? > > > Yes, we should look at the other cases where we unnecessarily uuencode > > > things. I'm not quite sure where we would document high level things > > > like this though, do you have a suggestion? I could see a case for > > > somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance) > > > fitting into style.9, but I'm not sure this one does. > > > > I think the committers guide, which needs a revamp. That > > should also cover the 7-bit/... > > Probably, yes. That said, I'm very much in favour of having the > documentation in the tree itself, for those topics pertaining to the > software in that tree (e.g. style(9), ports(7), development(7), > arch(7)). I do not have much problem with it being multiple places, so long as they are all cross referenced either directly in words, or at least in markup comments so that when one place is changed the others are too. -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, 14 Mar 2019 at 22:05, Rodney W. Grimes wrote: > > How do the tools today deal with taking a binary off the vendor branch? > Isn't this still a for-ever night mare merge thing to deal with? There isn't really the concept of taking a file off the vendor branch in the same way as with CVS, although it's still prudent to limit changes to vendor/contrib files to avoid conflicts during future imports. Modifying binary contrib files is a different matter, but that would be difficult to deal with regardless of whether they're uuencoded or not. Anyway, I'm not aware of us having done that before. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
> On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes > wrote: > > > > Covered this in my reply to Warners reply. I think we also need to > > look at how this might affect vendor imported stuff, is there some if > > it that was .uu'ed before import? > > We definitely don't want to change files in contrib/ - that's up to > the upstreams. I think you miss understood, I belive in the paste, and possibly even still, that prep work was done to vendor code before import. We use to have shell scripts and such to deal with things like having to .uu files, remove stuff you dont want, etc. I suspect some of that is inplace and we probably do not want to just undo it without some careful thought. -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes wrote: > > > The reason not to do it is uuencoding adds about a 40% space penalty, > > adds to the build time (to uudecode), and makes changes harder to > > review. In my mind dropping the unnecessary uuencoding is similar to > > dropping build-time patching of files in the source tree (another > > workaround we used to have for limitations of our older VCS). > > I think I covered all the above in other replies. So: 1. We used to use a VCS which does not support binary files well, but have not used it for years. 2. Another source delivery tool (ctm) previously did not support binary files, but has for some time. 3. There may have been other reasons, but none that anyone can recall (at present). > > Yes, we should look at the other cases where we unnecessarily uuencode > > things. I'm not quite sure where we would document high level things > > like this though, do you have a suggestion? I could see a case for > > somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance) > > fitting into style.9, but I'm not sure this one does. > > I think the committers guide, which needs a revamp. That > should also cover the 7-bit/... Probably, yes. That said, I'm very much in favour of having the documentation in the tree itself, for those topics pertaining to the software in that tree (e.g. style(9), ports(7), development(7), arch(7)). ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes wrote: > > Covered this in my reply to Warners reply. I think we also need to > look at how this might affect vendor imported stuff, is there some if > it that was .uu'ed before import? We definitely don't want to change files in contrib/ - that's up to the upstreams. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, Mar 14, 2019, 7:38 PM Rodney W. Grimes wrote: > > I think maybe there was also a limitation on the > (repo-replication-over-email?) mechanism that we used to use? That rings a > very faint bell for me for some reason, even though I'm pretty sure it was > dead long before I got my bit. > > CTM is still in use today, in a recent action to depricate it in base > it was found that there are infact users, and users who wish to maintain > it. I do not know of CTM is impacted by this, that group would need > to respond. > CTM handles binaries just fine these days. We have dozens of binaries in the tree already. In the 90s there was an issue, but that was fixed well before we migrated to subversion. Warner > > > -Ravi (rpokala@) > > > > ?-Original Message- > > From: on behalf of Ed Maste < > ema...@freebsd.org> > > Date: 2019-03-14, Thursday at 12:21 > > To: "Rodney W. Grimes" > > Cc: src-committers , < > svn-src-all@freebsd.org>, > > Subject: Re: svn commit: r345138 - head/share/man/man9 > > > > On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes > > wrote: > > > > > > [ Charset UTF-8 unsupported, converting... ] > > > > Author: emaste > > > > Date: Thu Mar 14 17:09:07 2019 > > > > New Revision: 345138 > > > > URL: https://svnweb.freebsd.org/changeset/base/345138 > > > > > > > > Log: > > > > firmware(9): remove uuencoded example > > > > > > > > We can (should) just commit the binary files to the source tree. > > > > > > This change could use wider discussion. > > > > If you or others have a reason to prefer having uuencoded files in the > > src tree I'll happily revert. I was aware only of CVS limitations as a > > reason for uuencoding. > That was only one of the reasons IIRC. > > > We have many binary files in the tree already (e.g. GIF PNG and JPEG > > images, ELF and PE32 binaries, Berkeley DB files, and various > > compressed formats). I count 430 uuencoded files in the tree, with 328 > > of those coming from libarchive and 64 from sys/*/dev/ > > Why didnt you also count the "binary" files in the tree? > Where are they? > > -- > Rod Grimes > rgri...@freebsd.org > > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes > wrote: > > > > We should of documented what the decision process and criteria was > > that lead to the decission to uuencode the files. > > Doing some archaeology, the first instance of a uuencoded file I can > find is r1796, "Got rid of a couple of binary files by uuencoding. 49 > more to go." There's no explanation of why the change was made. > Evidence suggests that in 1994 it was just accepted as impossible or > not permitted to have binary files in the tree, but this has not been > the case for quite some time. > > > Thus we could easily revist that criteria, see how much of it no > > longer applies, possible add counter criteria, and change this > > decision, with it documented as to why it changed. > > With none of this documented anywhere I'm going to rely on oral > history from you, phk, or other FreeBSD committers active in the mid > 90s to provide guidance on what we can revisit and what to check if it > no longer applies. > > The reason not to do it is uuencoding adds about a 40% space penalty, > adds to the build time (to uudecode), and makes changes harder to > review. In my mind dropping the unnecessary uuencoding is similar to > dropping build-time patching of files in the source tree (another > workaround we used to have for limitations of our older VCS). I think I covered all the above in other replies. > > As is this is just another semi documented project guideline change, > > I believe there are more than just the firmware files that this > > change needs noted on. > > Yes, we should look at the other cases where we unnecessarily uuencode > things. I'm not quite sure where we would document high level things > like this though, do you have a suggestion? I could see a case for > somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance) > fitting into style.9, but I'm not sure this one does. I think the committers guide, which needs a revamp. That should also cover the 7-bit/... > > We should also note that if they are already in uuencode state > > to leave them in uuencode state, or do we intened to convert > > them on next commit, or ??? > > Good point, converting existing .uu files to binary is just > unnecessary churn and is not recommended. If someone is going to make > a change it can be done with the next update. Covered this in my reply to Warners reply. I think we also need to look at how this might affect vendor imported stuff, is there some if it that was .uu'ed before import? -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
> On Thu, Mar 14, 2019 at 3:43 PM Ed Maste wrote: > > > On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes > > wrote: > > > > > > We should of documented what the decision process and criteria was > > > that lead to the decission to uuencode the files. > > > > Doing some archaeology, the first instance of a uuencoded file I can > > find is r1796, "Got rid of a couple of binary files by uuencoding. 49 > > more to go." There's no explanation of why the change was made. > > Evidence suggests that in 1994 it was just accepted as impossible or > > not permitted to have binary files in the tree, but this has not been > > the case for quite some time. > > > > CVS had issues with them. sup had issues with them (remember sup?). CTM > originally didn't cope but does now (not sure when that changed). Diff and patch had issues with them, and still do? > By the time I joined in 95 or so, it was already part of the oral > tradition. It was all over the mailing lists and just something you were > expected to know. I even have a recollection of people screwing up and > there being CVS repo surgery to remove the binary version and bring forward > only the .uu versions. But that was 20ish years ago, so I'm not certain. Yes, there was some cvs admin and/or rm's done, not exactly repo surgery, which did occur on other types of repairs, some very poorly. > > > Thus we could easily revist that criteria, see how much of it no > > > longer applies, possible add counter criteria, and change this > > > decision, with it documented as to why it changed. > > > > With none of this documented anywhere I'm going to rely on oral > > history from you, phk, or other FreeBSD committers active in the mid > > 90s to provide guidance on what we can revisit and what to check if it > > no longer applies. > > > > It no longer applies. svn copes well, git copes well, perforce coped well > (though not too relevant these days). > > IIRC, there used to be something about it in the CVS section of one of the > handbook chapters, but all that stuff was removed a long time ago and may > be hard to find today. This rings a bell. > > The reason not to do it is uuencoding adds about a 40% space penalty, > > adds to the build time (to uudecode), and makes changes harder to > > review. In my mind dropping the unnecessary uuencoding is similar to > > dropping build-time patching of files in the source tree (another > > workaround we used to have for limitations of our older VCS). > > > > Yes. Bringing a file off a vendor branch was generally greeted with much > gnashing of teeth and much bile. And for good reason: the person taking it > off the vendor branch was trivial, but it caused real and lasting conflicts > for every single new import after that. The pain was real, and borne by the > maintainer, not by the taker-off-the-brancher. How do the tools today deal with taking a binary off the vendor branch? Isn't this still a for-ever night mare merge thing to deal with? > > > As is this is just another semi documented project guideline change, > > > I believe there are more than just the firmware files that this > > > change needs noted on. > > > > Yes, we should look at the other cases where we unnecessarily uuencode > > things. I'm not quite sure where we would document high level things > > like this though, do you have a suggestion? I could see a case for > > somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance) > > fitting into style.9, but I'm not sure this one does. > > > > This feels more like committer guide material, not style.9 to me. The > committer guide is showing its age and collection of random detritus that > we need to reorganize and update. This is one of the many issues. I agree on location, in or near the committers guide. It may be time to expand that to have a procedures section (how to vendor import, how to MFC, etc), and a guidelines section (commit messages, must/should/ can/shall not etc) > > > > > We should also note that if they are already in uuencode state > > > to leave them in uuencode state, or do we intened to convert > > > them on next commit, or ??? > > > > Good point, converting existing .uu files to binary is just > > unnecessary churn and is not recommended. If someone is going to make > > a change it can be done with the next update. > > > > I'd convert them when there's some other reason to handle them. I'm not > swayed by the churn argument, but more because there's little gain here, at > the moment, and it would take someone's time. But if someone takes the > time, I wouldn't stand in the way. Agree, and that is probably all the document should say on that subject. > Warner -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
> > In message > > , Ed Maste writes: > >On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes > > >Doing some archaeology, the first instance of a uuencoded file I can > >find is r1796, "Got rid of a couple of binary files by uuencoding. 49 > >more to go." There's no explanation of why the change was made. > > I am pretty sure that we discussed the question of binary files in > the tree on either core@ or hackers@ (not much difference back > then), but that probably predates the "Dont mount the projects mail > archives on /tmp/something" incident. It would of been hackers@, this would of not been a core discussion. > The first versions of CTM used diff -e and ed(1) to transmit changes, > and that choked up on binary files. We didn't have patch in the > tree back then. patch has always been in the tree. https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/usr.bin/patch > > I can't answer definitively if modern CTM has any such restrictions, > but I would not expect so, either way, it should not matter. Warner said in another reply it does not, but this should be listed in the decision criteral, with a "not effected or formally effected" state. > >> We should also note that if they are already in uuencode state > >> to leave them in uuencode state, or do we intened to convert > >> them on next commit, or ??? > > > >Good point, converting existing .uu files to binary is just > >unnecessary churn and is not recommended. If someone is going to make > >a change it can be done with the next update. > > Agreed. So is it leave them forever .uu, on next import/whatever bring in the binary and remove the .uu, Or ? > p...@freebsd.org | TCP/IP since RFC 956 -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
> I think maybe there was also a limitation on the > (repo-replication-over-email?) mechanism that we used to use? That rings a > very faint bell for me for some reason, even though I'm pretty sure it was > dead long before I got my bit. CTM is still in use today, in a recent action to depricate it in base it was found that there are infact users, and users who wish to maintain it. I do not know of CTM is impacted by this, that group would need to respond. > > -Ravi (rpokala@) > > ?-Original Message- > From: on behalf of Ed Maste > > Date: 2019-03-14, Thursday at 12:21 > To: "Rodney W. Grimes" > Cc: src-committers , , > > Subject: Re: svn commit: r345138 - head/share/man/man9 > > On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes > wrote: > > > > [ Charset UTF-8 unsupported, converting... ] > > > Author: emaste > > > Date: Thu Mar 14 17:09:07 2019 > > > New Revision: 345138 > > > URL: https://svnweb.freebsd.org/changeset/base/345138 > > > > > > Log: > > > firmware(9): remove uuencoded example > > > > > > We can (should) just commit the binary files to the source tree. > > > > This change could use wider discussion. > > If you or others have a reason to prefer having uuencoded files in the > src tree I'll happily revert. I was aware only of CVS limitations as a > reason for uuencoding. That was only one of the reasons IIRC. > We have many binary files in the tree already (e.g. GIF PNG and JPEG > images, ELF and PE32 binaries, Berkeley DB files, and various > compressed formats). I count 430 uuencoded files in the tree, with 328 > of those coming from libarchive and 64 from sys/*/dev/ Why didnt you also count the "binary" files in the tree? Where are they? -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, Mar 14, 2019 at 3:43 PM Ed Maste wrote: > On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes > wrote: > > > > We should of documented what the decision process and criteria was > > that lead to the decission to uuencode the files. > > Doing some archaeology, the first instance of a uuencoded file I can > find is r1796, "Got rid of a couple of binary files by uuencoding. 49 > more to go." There's no explanation of why the change was made. > Evidence suggests that in 1994 it was just accepted as impossible or > not permitted to have binary files in the tree, but this has not been > the case for quite some time. > CVS had issues with them. sup had issues with them (remember sup?). CTM originally didn't cope but does now (not sure when that changed). By the time I joined in 95 or so, it was already part of the oral tradition. It was all over the mailing lists and just something you were expected to know. I even have a recollection of people screwing up and there being CVS repo surgery to remove the binary version and bring forward only the .uu versions. But that was 20ish years ago, so I'm not certain. > > Thus we could easily revist that criteria, see how much of it no > > longer applies, possible add counter criteria, and change this > > decision, with it documented as to why it changed. > > With none of this documented anywhere I'm going to rely on oral > history from you, phk, or other FreeBSD committers active in the mid > 90s to provide guidance on what we can revisit and what to check if it > no longer applies. > It no longer applies. svn copes well, git copes well, perforce coped well (though not too relevant these days). IIRC, there used to be something about it in the CVS section of one of the handbook chapters, but all that stuff was removed a long time ago and may be hard to find today. > The reason not to do it is uuencoding adds about a 40% space penalty, > adds to the build time (to uudecode), and makes changes harder to > review. In my mind dropping the unnecessary uuencoding is similar to > dropping build-time patching of files in the source tree (another > workaround we used to have for limitations of our older VCS). > Yes. Bringing a file off a vendor branch was generally greeted with much gnashing of teeth and much bile. And for good reason: the person taking it off the vendor branch was trivial, but it caused real and lasting conflicts for every single new import after that. The pain was real, and borne by the maintainer, not by the taker-off-the-brancher. > > As is this is just another semi documented project guideline change, > > I believe there are more than just the firmware files that this > > change needs noted on. > > Yes, we should look at the other cases where we unnecessarily uuencode > things. I'm not quite sure where we would document high level things > like this though, do you have a suggestion? I could see a case for > somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance) > fitting into style.9, but I'm not sure this one does. > This feels more like committer guide material, not style.9 to me. The committer guide is showing its age and collection of random detritus that we need to reorganize and update. This is one of the many issues. > > We should also note that if they are already in uuencode state > > to leave them in uuencode state, or do we intened to convert > > them on next commit, or ??? > > Good point, converting existing .uu files to binary is just > unnecessary churn and is not recommended. If someone is going to make > a change it can be done with the next update. > I'd convert them when there's some other reason to handle them. I'm not swayed by the churn argument, but more because there's little gain here, at the moment, and it would take someone's time. But if someone takes the time, I wouldn't stand in the way. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
In message , Ed Maste writes: >On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes >Doing some archaeology, the first instance of a uuencoded file I can >find is r1796, "Got rid of a couple of binary files by uuencoding. 49 >more to go." There's no explanation of why the change was made. I am pretty sure that we discussed the question of binary files in the tree on either core@ or hackers@ (not much difference back then), but that probably predates the "Dont mount the projects mail archives on /tmp/something" incident. The first versions of CTM used diff -e and ed(1) to transmit changes, and that choked up on binary files. We didn't have patch in the tree back then. I can't answer definitively if modern CTM has any such restrictions, but I would not expect so, either way, it should not matter. >> We should also note that if they are already in uuencode state >> to leave them in uuencode state, or do we intened to convert >> them on next commit, or ??? > >Good point, converting existing .uu files to binary is just >unnecessary churn and is not recommended. If someone is going to make >a change it can be done with the next update. Agreed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes wrote: > > We should of documented what the decision process and criteria was > that lead to the decission to uuencode the files. Doing some archaeology, the first instance of a uuencoded file I can find is r1796, "Got rid of a couple of binary files by uuencoding. 49 more to go." There's no explanation of why the change was made. Evidence suggests that in 1994 it was just accepted as impossible or not permitted to have binary files in the tree, but this has not been the case for quite some time. > Thus we could easily revist that criteria, see how much of it no > longer applies, possible add counter criteria, and change this > decision, with it documented as to why it changed. With none of this documented anywhere I'm going to rely on oral history from you, phk, or other FreeBSD committers active in the mid 90s to provide guidance on what we can revisit and what to check if it no longer applies. The reason not to do it is uuencoding adds about a 40% space penalty, adds to the build time (to uudecode), and makes changes harder to review. In my mind dropping the unnecessary uuencoding is similar to dropping build-time patching of files in the source tree (another workaround we used to have for limitations of our older VCS). > As is this is just another semi documented project guideline change, > I believe there are more than just the firmware files that this > change needs noted on. Yes, we should look at the other cases where we unnecessarily uuencode things. I'm not quite sure where we would document high level things like this though, do you have a suggestion? I could see a case for somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance) fitting into style.9, but I'm not sure this one does. > We should also note that if they are already in uuencode state > to leave them in uuencode state, or do we intened to convert > them on next commit, or ??? Good point, converting existing .uu files to binary is just unnecessary churn and is not recommended. If someone is going to make a change it can be done with the next update. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
CTM was fixed years ago... Warner On Thu, Mar 14, 2019, 1:32 PM Ravi Pokala wrote: > I think maybe there was also a limitation on the > (repo-replication-over-email?) mechanism that we used to use? That rings a > very faint bell for me for some reason, even though I'm pretty sure it was > dead long before I got my bit. > > -Ravi (rpokala@) > > -Original Message- > From: on behalf of Ed Maste < > ema...@freebsd.org> > Date: 2019-03-14, Thursday at 12:21 > To: "Rodney W. Grimes" > Cc: src-committers , , > > Subject: Re: svn commit: r345138 - head/share/man/man9 > > On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes > wrote: > > > > [ Charset UTF-8 unsupported, converting... ] > > > Author: emaste > > > Date: Thu Mar 14 17:09:07 2019 > > > New Revision: 345138 > > > URL: https://svnweb.freebsd.org/changeset/base/345138 > > > > > > Log: > > > firmware(9): remove uuencoded example > > > > > > We can (should) just commit the binary files to the source tree. > > > > This change could use wider discussion. > > If you or others have a reason to prefer having uuencoded files in the > src tree I'll happily revert. I was aware only of CVS limitations as a > reason for uuencoding. > > We have many binary files in the tree already (e.g. GIF PNG and JPEG > images, ELF and PE32 binaries, Berkeley DB files, and various > compressed formats). I count 430 uuencoded files in the tree, with 328 > of those coming from libarchive and 64 from sys/*/dev/ > > > > > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
I think maybe there was also a limitation on the (repo-replication-over-email?) mechanism that we used to use? That rings a very faint bell for me for some reason, even though I'm pretty sure it was dead long before I got my bit. -Ravi (rpokala@) -Original Message- From: on behalf of Ed Maste Date: 2019-03-14, Thursday at 12:21 To: "Rodney W. Grimes" Cc: src-committers , , Subject: Re: svn commit: r345138 - head/share/man/man9 On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes wrote: > > [ Charset UTF-8 unsupported, converting... ] > > Author: emaste > > Date: Thu Mar 14 17:09:07 2019 > > New Revision: 345138 > > URL: https://svnweb.freebsd.org/changeset/base/345138 > > > > Log: > > firmware(9): remove uuencoded example > > > > We can (should) just commit the binary files to the source tree. > > This change could use wider discussion. If you or others have a reason to prefer having uuencoded files in the src tree I'll happily revert. I was aware only of CVS limitations as a reason for uuencoding. We have many binary files in the tree already (e.g. GIF PNG and JPEG images, ELF and PE32 binaries, Berkeley DB files, and various compressed formats). I count 430 uuencoded files in the tree, with 328 of those coming from libarchive and 64 from sys/*/dev/ ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes wrote: > > [ Charset UTF-8 unsupported, converting... ] > > Author: emaste > > Date: Thu Mar 14 17:09:07 2019 > > New Revision: 345138 > > URL: https://svnweb.freebsd.org/changeset/base/345138 > > > > Log: > > firmware(9): remove uuencoded example > > > > We can (should) just commit the binary files to the source tree. > > This change could use wider discussion. If you or others have a reason to prefer having uuencoded files in the src tree I'll happily revert. I was aware only of CVS limitations as a reason for uuencoding. We have many binary files in the tree already (e.g. GIF PNG and JPEG images, ELF and PE32 binaries, Berkeley DB files, and various compressed formats). I count 430 uuencoded files in the tree, with 328 of those coming from libarchive and 64 from sys/*/dev/ ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345138 - head/share/man/man9
[ Charset UTF-8 unsupported, converting... ]
> Author: emaste
> Date: Thu Mar 14 17:09:07 2019
> New Revision: 345138
> URL: https://svnweb.freebsd.org/changeset/base/345138
>
> Log:
> firmware(9): remove uuencoded example
>
> We can (should) just commit the binary files to the source tree.
We should of documented what the decision process and criteria was
that lead to the decission to uuencode the files.
I do not believe it was just that the VCS could not handle them,
that there was some other reasoning as well. There is also down
streams to consider, does this in any way effect things outside
the project.
Thus we could easily revist that criteria, see how much of it no
longer applies, possible add counter criteria, and change this
decision, with it documented as to why it changed.
As is this is just another semi documented project guideline change,
I believe there are more than just the firmware files that this
change needs noted on.
We should also note that if they are already in uuencode state
to leave them in uuencode state, or do we intened to convert
them on next commit, or ???
This change could use wider discussion.
> Reviewed by:bz, imp, 0mp
> Differential Revision: https://reviews.freebsd.org/D19581
>
> Modified:
> head/share/man/man9/firmware.9
>
> Modified: head/share/man/man9/firmware.9
> ==
> --- head/share/man/man9/firmware.9Thu Mar 14 17:05:46 2019
> (r345137)
> +++ head/share/man/man9/firmware.9Thu Mar 14 17:09:07 2019
> (r345138)
> @@ -23,7 +23,7 @@
> .\"
> .\" $FreeBSD$
> .\"
> -.Dd August 2, 2008
> +.Dd March 14, 2019
> .Dt FIRMWARE 9
> .Os
> .Sh NAME
> @@ -248,12 +248,11 @@ IxNpeMicrocode.fwo optional npe_fw
> \\
> -r -d -o ${.TARGET} IxNpeMicrocode.dat" \\
> no-implicit-rule\\
> clean "IxNpeMicrocode.fwo"
> -IxNpeMicrocode.dat optional npe_fw \\
> -dependency ".PHONY"\\
> -compile-with"uudecode <
> $S/contrib/dev/npe/IxNpeMicrocode.dat.uu" \\
> -no-obj no-implicit-rule \\
> -clean "IxNpeMicrocode.dat"
> .Ed
> +.Pp
> +Firmware was previously committed to the source tree as uuencoded files,
> +but this is no longer required; the binary firmware file should be committed
> +to the tree as provided by the vendor.
> .Pp
> Note that generating the firmware modules in this way requires
> the availability of the following tools:
>
>
--
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r345138 - head/share/man/man9
Author: emaste
Date: Thu Mar 14 17:09:07 2019
New Revision: 345138
URL: https://svnweb.freebsd.org/changeset/base/345138
Log:
firmware(9): remove uuencoded example
We can (should) just commit the binary files to the source tree.
Reviewed by: bz, imp, 0mp
Differential Revision:https://reviews.freebsd.org/D19581
Modified:
head/share/man/man9/firmware.9
Modified: head/share/man/man9/firmware.9
==
--- head/share/man/man9/firmware.9 Thu Mar 14 17:05:46 2019
(r345137)
+++ head/share/man/man9/firmware.9 Thu Mar 14 17:09:07 2019
(r345138)
@@ -23,7 +23,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd August 2, 2008
+.Dd March 14, 2019
.Dt FIRMWARE 9
.Os
.Sh NAME
@@ -248,12 +248,11 @@ IxNpeMicrocode.fwo optional npe_fw
\\
-r -d -o ${.TARGET} IxNpeMicrocode.dat" \\
no-implicit-rule\\
clean "IxNpeMicrocode.fwo"
-IxNpeMicrocode.dat optional npe_fw \\
-dependency ".PHONY"\\
-compile-with"uudecode < $S/contrib/dev/npe/IxNpeMicrocode.dat.uu"
\\
-no-obj no-implicit-rule \\
-clean "IxNpeMicrocode.dat"
.Ed
+.Pp
+Firmware was previously committed to the source tree as uuencoded files,
+but this is no longer required; the binary firmware file should be committed
+to the tree as provided by the vendor.
.Pp
Note that generating the firmware modules in this way requires
the availability of the following tools:
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
