Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On 1 Jul 2020, at 00:03, Stefan Eßer wrote: > > Am 30.06.20 um 23:29 schrieb Dimitry Andric: ... >> This is because you are supposed to commit stuff to ^/base/vendor/xxx >> first, then svn cp it to ^/head/contrib/xxx, at least from Subversion >> 1.8 onwards. The 'cp' action establishes the ancestral relation. > > Yes, I thought so - the problem I want to fix is the premature import > to /contrib and I had been hoping that it was possible to use the > --record-only merge to edit the merge history (as suggested by John > Baldwin and Ed Maste). I have never been able to find a way to 'force' the ancestral relation after the fact. Subversion does not seem to expose this as a user-manipulable property. The --record-only option does what it says, i.e. not actually merging but only updating the svn:mergeinfo property, but it will still only work on ancestrally related objects. > I want to upgrade to the next release and I'm wondering whether it > would be possible to just svn copy that new version over from the > vendor directory to the contrib directory. The import to the vendor > area and the contrib directory have very similar commit messages and > thus there would be no loss of commit history. If you don't have many (or no) customizations, then indeed it will be fairly easy. In one commit, you can svn rm the old version, and svn cp the new version from the vendor area. Subversion will later show the directory to have been "Replaced". There are lots of examples of this in the tree, and I would hope the Git converter can handle it, or there will be much more trouble. :) -Dimitry signature.asc Description: Message signed with OpenPGP
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
Am 30.06.20 um 23:29 schrieb Dimitry Andric: > On 30 Jun 2020, at 22:01, Stefan Eßer wrote: >> >> Am 29.06.20 um 20:09 schrieb Ed Maste: >>> On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: I suspect just doing the 'merge --record-only' is the simplest method assuming Git handles it ok. I suspect since Git ignores mergeinfo this is fine, but it would be good for Ed to confirm. You can always restore the tests in the future in contrib/bc when you want to add them. >>> >>> I think a --record-only merge is the best approach; in any case we >>> have a number of these in the tree already and Git will have to deal >>> with them. >> >> $ cd /usr/svn/base/head/contrib/bc >> >> $ svn merge --record-only ^/vendor/bc/dist >> svn: E195016: 'svn+ssh://repo.freebsd.org/base/vendor/bc/dist@362810' >> must be ancestrally related to >> 'svn+ssh://repo.freebsd.org/base/head/contrib/bc@362810' > > This is because you are supposed to commit stuff to ^/base/vendor/xxx > first, then svn cp it to ^/head/contrib/xxx, at least from Subversion > 1.8 onwards. The 'cp' action establishes the ancestral relation. Yes, I thought so - the problem I want to fix is the premature import to /contrib and I had been hoping that it was possible to use the --record-only merge to edit the merge history (as suggested by John Baldwin and Ed Maste). > Some of our older contrib areas were imported using cvs2svn, and these > also suffer the same problem, i.e. Subversion complains that the vendor > and contrib areas are not ancestrally related. I see. >> Adding the option --ignore-ancestry to the merge command does not help. > ... >> Any idea how to merge from the vendor area in this situation? > > As far as I know, you have these alternatives: > > * Delete the contrib/bc tree, and do a fresh svn cp from the vendor > area. You will have to apply any customizations on top again. I did > something like this to fixup contrib/libc++ in > https://svnweb.freebsd.org/base?view=revision=287679 Yes, I could delete the files in contrib/bc and then immediately svn copy over the contents of vendor/bc/dist - and I guess that is the only real "clean" way forward. > * Figure out the right value of the svn:mergeinfo property, and apply > that by hand, using svn propset. This will be tricky, and has to be > re-done manually every time you want to merge again. Not my preferred approach ... > * Merge with Subversion 1.7 or earlier. If this would result in a sane state of the repository I might give it a try. > * Ignore all this, merge patches by hand and wait for the Git > transition to be completed. I want to upgrade to the next release and I'm wondering whether it would be possible to just svn copy that new version over from the vendor directory to the contrib directory. The import to the vendor area and the contrib directory have very similar commit messages and thus there would be no loss of commit history. If this is possible and does not cause problems for the SVN repo or the Git conversion, this might be the simplest solution. Thank you for your reply and the clarification of the situation! Best regards, STefan ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On 30 Jun 2020, at 22:01, Stefan Eßer wrote: > > Am 29.06.20 um 20:09 schrieb Ed Maste: >> On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: >>> >>> I suspect just doing the 'merge --record-only' is the simplest method >>> assuming Git handles it ok. I suspect since Git ignores mergeinfo this >>> is fine, but it would be good for Ed to confirm. You can always restore >>> the tests in the future in contrib/bc when you want to add them. >> >> I think a --record-only merge is the best approach; in any case we >> have a number of these in the tree already and Git will have to deal >> with them. > > $ cd /usr/svn/base/head/contrib/bc > > $ svn merge --record-only ^/vendor/bc/dist > svn: E195016: 'svn+ssh://repo.freebsd.org/base/vendor/bc/dist@362810' > must be ancestrally related to > 'svn+ssh://repo.freebsd.org/base/head/contrib/bc@362810' This is because you are supposed to commit stuff to ^/base/vendor/xxx first, then svn cp it to ^/head/contrib/xxx, at least from Subversion 1.8 onwards. The 'cp' action establishes the ancestral relation. Some of our older contrib areas were imported using cvs2svn, and these also suffer the same problem, i.e. Subversion complains that the vendor and contrib areas are not ancestrally related. > Adding the option --ignore-ancestry to the merge command does not help. ... > Any idea how to merge from the vendor area in this situation? As far as I know, you have these alternatives: * Delete the contrib/bc tree, and do a fresh svn cp from the vendor area. You will have to apply any customizations on top again. I did something like this to fixup contrib/libc++ in https://svnweb.freebsd.org/base?view=revision=287679 * Figure out the right value of the svn:mergeinfo property, and apply that by hand, using svn propset. This will be tricky, and has to be re-done manually every time you want to merge again. * Merge with Subversion 1.7 or earlier. * Ignore all this, merge patches by hand and wait for the Git transition to be completed. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
Am 29.06.20 um 20:09 schrieb Ed Maste: > On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: >> >> I suspect just doing the 'merge --record-only' is the simplest method >> assuming Git handles it ok. I suspect since Git ignores mergeinfo this >> is fine, but it would be good for Ed to confirm. You can always restore >> the tests in the future in contrib/bc when you want to add them. > > I think a --record-only merge is the best approach; in any case we > have a number of these in the tree already and Git will have to deal > with them. $ cd /usr/svn/base/head/contrib/bc $ svn merge --record-only ^/vendor/bc/dist svn: E195016: 'svn+ssh://repo.freebsd.org/base/vendor/bc/dist@362810' must be ancestrally related to 'svn+ssh://repo.freebsd.org/base/head/contrib/bc@362810' Adding the option --ignore-ancestry to the merge command does not help. I have performed a clean check-out of base/head and base/vendor, but the error message stays the same ... SVN info for the relevant directories involved in the merge attempt: $ svn info /usr/svn/base/head/contrib/bc /usr/svn/base/vendor/bc/dist Path: usr/svn/base/head/contrib/bc Working Copy Root Path: /usr/svn/base URL: svn+ssh://repo.freebsd.org/base/head/contrib/bc Relative URL: ^/head/contrib/bc Repository Root: svn+ssh://repo.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 362810 Node Kind: directory Schedule: normal Last Changed Author: se Last Changed Rev: 362681 Last Changed Date: 2020-06-27 14:02:01 +0200 (Sat, 27 Jun 2020) Path: usr/svn/base/vendor/bc/dist Working Copy Root Path: /usr/svn/base URL: svn+ssh://repo.freebsd.org/base/vendor/bc/dist Relative URL: ^/vendor/bc/dist Repository Root: svn+ssh://repo.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 362810 Node Kind: directory Schedule: normal Last Changed Author: se Last Changed Rev: 362697 Last Changed Date: 2020-06-27 17:03:19 +0200 (Sat, 27 Jun 2020) Any idea how to merge from the vendor area in this situation? Regards, STefan ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On 29/06/2020 16:11, Stefan Eßer wrote: Am 29.06.20 um 20:09 schrieb Ed Maste: On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: I suspect just doing the 'merge --record-only' is the simplest method assuming Git handles it ok. I suspect since Git ignores mergeinfo this is fine, but it would be good for Ed to confirm. You can always restore the tests in the future in contrib/bc when you want to add them. I think a --record-only merge is the best approach; in any case we have a number of these in the tree already and Git will have to deal with them. Thank you for this advice. There is a new version, which differs only in the man-pages. These used to mention optional features (of which only NLS support is actually optional in the version built on FreeBSD, all other are always compiled in, and I had mentioned to the author that this might irritate FreeBSD users). FWIW, since it was rewritten it would have been actually nice to have it in modern C++. I have suggested to the author to add SPDX BSD-2-Clause tags, which would change a large fraction of the currently committed files. We only use the SPDX tags for internal software. For stuff from contrib it is not necessary. Is it required to perform the --record-only merge, then? Since you are going to bring it through the vendor area you should keep the merge information yes. Or would it be OK to import the new release into the vendor branch and then svn copy that version completely (including the tests and other files that I had omitted in the initial import) to contrib? I expect the svn copy without prior svn merge --record-only to result in the same repository state after the conversion to Git, but I do not really know ... It is likely git won't care. cheers, Pedro. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On 6/29/20 2:11 PM, Stefan Eßer wrote: > Am 29.06.20 um 20:09 schrieb Ed Maste: >> On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: >>> >>> I suspect just doing the 'merge --record-only' is the simplest method >>> assuming Git handles it ok. I suspect since Git ignores mergeinfo this >>> is fine, but it would be good for Ed to confirm. You can always restore >>> the tests in the future in contrib/bc when you want to add them. >> >> I think a --record-only merge is the best approach; in any case we >> have a number of these in the tree already and Git will have to deal >> with them. > > Thank you for this advice. > > There is a new version, which differs only in the man-pages. These > used to mention optional features (of which only NLS support is > actually optional in the version built on FreeBSD, all other are > always compiled in, and I had mentioned to the author that this > might irritate FreeBSD users). > > I have suggested to the author to add SPDX BSD-2-Clause tags, which > would change a large fraction of the currently committed files. > > > Is it required to perform the --record-only merge, then? > > Or would it be OK to import the new release into the vendor branch > and then svn copy that version completely (including the tests and > other files that I had omitted in the initial import) to contrib? > > I expect the svn copy without prior svn merge --record-only to > result in the same repository state after the conversion to Git, > but I do not really know ... You can do a --record-only merge now, and then use 'svn merge' to merge in the new version via the normal workflow. -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
Am 29.06.20 um 20:09 schrieb Ed Maste: > On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: >> >> I suspect just doing the 'merge --record-only' is the simplest method >> assuming Git handles it ok. I suspect since Git ignores mergeinfo this >> is fine, but it would be good for Ed to confirm. You can always restore >> the tests in the future in contrib/bc when you want to add them. > > I think a --record-only merge is the best approach; in any case we > have a number of these in the tree already and Git will have to deal > with them. Thank you for this advice. There is a new version, which differs only in the man-pages. These used to mention optional features (of which only NLS support is actually optional in the version built on FreeBSD, all other are always compiled in, and I had mentioned to the author that this might irritate FreeBSD users). I have suggested to the author to add SPDX BSD-2-Clause tags, which would change a large fraction of the currently committed files. Is it required to perform the --record-only merge, then? Or would it be OK to import the new release into the vendor branch and then svn copy that version completely (including the tests and other files that I had omitted in the initial import) to contrib? I expect the svn copy without prior svn merge --record-only to result in the same repository state after the conversion to Git, but I do not really know ... Regards, STefan ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: > > I suspect just doing the 'merge --record-only' is the simplest method > assuming Git handles it ok. I suspect since Git ignores mergeinfo this > is fine, but it would be good for Ed to confirm. You can always restore > the tests in the future in contrib/bc when you want to add them. I think a --record-only merge is the best approach; in any case we have a number of these in the tree already and Git will have to deal with them. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On 6/28/20 1:28 AM, Stefan Eßer wrote: > I could delete what's currently in contrib/bc and use svn copy to make > the whole contents of vendor/bc/dist available in contrib/bc. The tests > require 1112 KB of space, while the rest of the sources takes up less > than 900 KB. > > I could revert the full import to contrib/bc, but that would also revert > changes to e.g. usr.bin/Makefile and I'd rather remove just what's now > in contrib/bc and then use svn copy to make vendor/bc/dist available > there. The sources from the dist directory can be used unmodified, the > reason for cherry-picking was just that I did not want to import more > than is used at this time ... I do not think you should do a full revert but just fixup contrib/bc. I think it would be good to get advice from emaste@ about what is most Git-conversion-friendly. You might be able to just do a 'svn merge --record-only' to bootstrap the merge info and commit that. Barring that, you might be able to svn rm contrib/bc and then 'svn cp' it from the vendor area. You'd probably have to do that as two separate commits to make use of a URL for the 'svn cp' though which would break the tree for one commit. I suspect just doing the 'merge --record-only' is the simplest method assuming Git handles it ok. I suspect since Git ignores mergeinfo this is fine, but it would be good for Ed to confirm. You can always restore the tests in the future in contrib/bc when you want to add them. -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
Am 27.06.20 um 23:52 schrieb Eric van Gyzen: > On 6/27/20 8:11 AM, John Baldwin wrote: >> On 6/27/20 5:02 AM, Stefan Eßer wrote: >>> Author: se >>> Date: Sat Jun 27 12:02:01 2020 >>> New Revision: 362681 >>> URL: https://svnweb.freebsd.org/changeset/base/362681 >>> >>> Log: >>> Import new 2-clause BSD licenced implementation of the bc and dc >>> commands >> >> Hmm, I didn't see a commit to add the vendor sources into ^/vendor >> first via our >> standard process for contrib sources, nor any discussion about that in >> the review. > > When you add this to the vendor area, please include the tests, to > remove a barrier to integration. Hi Eric, I have already imported the full sources into the vendor area, including the tests. These tests compare the output of this bc and dc with that of GNU bc/dc and are run as regression tests by the author before a release is tagged (and have been extended over time for each area where an issue has been found). Extensive fuzzing is also performed to verify that the low level math functions give correct results (again using another bc/dc as reference), but we do not want to include those particular tests. I'd like to make the tests available as regression tests in FreeBSD, but have not looked at the best way to integrate them, yet. (The tests are meant to be run within the source directory after building from sources in place, for example, which is not at all what we do in FreeBSD.) Independently of the issue of tests, I'm not sure about the best way to proceed from the current situation with regard to what's in contrib/bc now, and I have decided to leave the incomplete import untouched in contrib/bc until I understand the best way forward. I could delete what's currently in contrib/bc and use svn copy to make the whole contents of vendor/bc/dist available in contrib/bc. The tests require 1112 KB of space, while the rest of the sources takes up less than 900 KB. I could revert the full import to contrib/bc, but that would also revert changes to e.g. usr.bin/Makefile and I'd rather remove just what's now in contrib/bc and then use svn copy to make vendor/bc/dist available there. The sources from the dist directory can be used unmodified, the reason for cherry-picking was just that I did not want to import more than is used at this time ... I'd appreciate any advice given about what causes the least repo churn and extra effort for the Git conversion. Regards, STefan ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On 6/27/20 8:11 AM, John Baldwin wrote: On 6/27/20 5:02 AM, Stefan Eßer wrote: Author: se Date: Sat Jun 27 12:02:01 2020 New Revision: 362681 URL: https://svnweb.freebsd.org/changeset/base/362681 Log: Import new 2-clause BSD licenced implementation of the bc and dc commands Hmm, I didn't see a commit to add the vendor sources into ^/vendor first via our standard process for contrib sources, nor any discussion about that in the review. When you add this to the vendor area, please include the tests, to remove a barrier to integration. Eric ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/
On 6/27/20 5:02 AM, Stefan Eßer wrote: > Author: se > Date: Sat Jun 27 12:02:01 2020 > New Revision: 362681 > URL: https://svnweb.freebsd.org/changeset/base/362681 > > Log: > Import new 2-clause BSD licenced implementation of the bc and dc commands Hmm, I didn't see a commit to add the vendor sources into ^/vendor first via our standard process for contrib sources, nor any discussion about that in the review. -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/b...
Author: se Date: Sat Jun 27 12:02:01 2020 New Revision: 362681 URL: https://svnweb.freebsd.org/changeset/base/362681 Log: Import new 2-clause BSD licenced implementation of the bc and dc commands These implementations of the bc and dc programs offer a number of advantages compared to the current implementations in the FreeBSD base system: - They do not depend on external large number functions (i.e. no dependency on OpenSSL or any other large number library) - They implements all features found in GNU bc/dc (with the exception of the forking of sub-processes, which the author of this version considers as a security issue). - They are significantly faster than the current code in base (more than 2 orders of magnitude in some of my tests, e.g. for 12345^10). - They should be fully compatible with all features and the behavior of the current implementations in FreeBSD (not formally verified). - They support POSIX message catalogs and come with localized messages in Chinese, Dutch, English, French, German, Japanese, Polish, Portugueze, and Russian. - They offer very detailed man-pages that provide far more information than the current ones. The upstream sources contain a large number of tests, which are not imported with this commit. They could be integrated into our test framework at a latter time. Installation of this version is controlled by the option "MK_GH_BC=yes". This option will be set to yes by default in 13-CURRENT, but will be off by default in 12-STABLE. Approved by: imp Obtained from:https://git.yzena.com/gavin/bc MFC after:4 weeks Relnotes: yes Differential Revision:https://reviews.freebsd.org/D19982 Added: head/contrib/bc/LICENSE.md head/contrib/bc/Makefile.in (contents, props changed) head/contrib/bc/NEWS.md head/contrib/bc/NOTICE.md head/contrib/bc/README.md head/contrib/bc/RELEASE.md head/contrib/bc/gen/bc_help.txt (contents, props changed) head/contrib/bc/gen/dc_help.txt (contents, props changed) head/contrib/bc/gen/lib.bc head/contrib/bc/gen/lib2.bc head/contrib/bc/gen/strgen.sh (contents, props changed) head/contrib/bc/include/args.h (contents, props changed) head/contrib/bc/include/bc.h (contents, props changed) head/contrib/bc/include/dc.h (contents, props changed) head/contrib/bc/include/file.h (contents, props changed) head/contrib/bc/include/history.h (contents, props changed) head/contrib/bc/include/lang.h (contents, props changed) head/contrib/bc/include/lex.h (contents, props changed) head/contrib/bc/include/num.h (contents, props changed) head/contrib/bc/include/opt.h (contents, props changed) head/contrib/bc/include/parse.h (contents, props changed) head/contrib/bc/include/program.h (contents, props changed) head/contrib/bc/include/rand.h (contents, props changed) head/contrib/bc/include/read.h (contents, props changed) head/contrib/bc/include/status.h (contents, props changed) head/contrib/bc/include/vector.h (contents, props changed) head/contrib/bc/include/vm.h (contents, props changed) head/contrib/bc/locales/ head/contrib/bc/locales/de_DE.ISO8859-1.msg head/contrib/bc/locales/de_DE.UTF-8.msg head/contrib/bc/locales/en_US.UTF-8.msg (contents, props changed) head/contrib/bc/locales/en_US.msg head/contrib/bc/locales/es_ES.UTF-8.msg head/contrib/bc/locales/fr_FR.ISO8859-1.msg head/contrib/bc/locales/fr_FR.UTF-8.msg head/contrib/bc/locales/ja_JP.UTF-8.msg (contents, props changed) head/contrib/bc/locales/ja_JP.eucJP.msg (contents, props changed) head/contrib/bc/locales/nl_NL.ISO8859-1.msg head/contrib/bc/locales/nl_NL.UTF-8.msg head/contrib/bc/locales/pl_PL.ISO8859-2.msg head/contrib/bc/locales/pl_PL.UTF-8.msg head/contrib/bc/locales/pt_PT.ISO8859-1.msg head/contrib/bc/locales/pt_PT.UTF-8.msg head/contrib/bc/locales/ru_RU.CP1251.msg (contents, props changed) head/contrib/bc/locales/ru_RU.CP866.msg (contents, props changed) head/contrib/bc/locales/ru_RU.ISO8859-5.msg (contents, props changed) head/contrib/bc/locales/ru_RU.KOI8-R.msg (contents, props changed) head/contrib/bc/locales/ru_RU.UTF-8.msg (contents, props changed) head/contrib/bc/locales/zh_CN.GB18030.msg (contents, props changed) head/contrib/bc/locales/zh_CN.GB2312.msg (contents, props changed) head/contrib/bc/locales/zh_CN.GBK.msg (contents, props changed) head/contrib/bc/locales/zh_CN.UTF-8.msg (contents, props changed) head/contrib/bc/locales/zh_CN.eucCN.msg (contents, props changed) head/contrib/bc/manuals/algorithms.md head/contrib/bc/manuals/bc.1 (contents, props changed) head/contrib/bc/manuals/bc.1.ronn head/contrib/bc/manuals/bc.md (contents, props changed) head/contrib/bc/manuals/benchmarks.md head/contrib/bc/manuals/build.md head/contrib/bc/manuals/dc.1 (contents, props changed)
