From gdt at lexort.com Sun Nov 1 10:36:58 2020 From: gdt at lexort.com (Greg Troxel) Date: Sun, 01 Nov 2020 10:36:58 -0500 Subject: [Unison-hackers] Windows x86_64 protocol failures Message-ID: We have received sevearl reports or protocol failures in 2.51.3. It is now seeming that the common factor is using the windows x86_64 GHA-built binaries. https://github.com/bcpierce00/unison/issues/166 I wonder if anyone knows of any issue in ocaml that affects only Windows/x86_64? Or has any idea what might be different in terms of wire protocol in that case? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From toivol at gmail.com Mon Nov 2 13:15:08 2020 From: toivol at gmail.com (=?UTF-8?B?VMO1aXZvIExlZWRqw6Rydg==?=) Date: Mon, 2 Nov 2020 19:15:08 +0100 Subject: [Unison-hackers] Windows x86_64 protocol failures In-Reply-To: References: Message-ID: On Sun, Nov 1, 2020 at 4:37 PM Greg Troxel wrote: > > https://github.com/bcpierce00/unison/issues/166 > > I wonder if anyone knows of any issue in ocaml that affects only > Windows/x86_64? Or has any idea what might be different in terms of > wire protocol in that case? The issue has been found and fixed. There are also a couple of test confirmations by the affected users. There is no objective reason why the fix would affect other platforms, but anyone with a possibility to test is welcome to test the latest builds also on non-Windows platforms. From gdt at lexort.com Mon Nov 2 14:04:08 2020 From: gdt at lexort.com (Greg Troxel) Date: Mon, 02 Nov 2020 14:04:08 -0500 Subject: [Unison-hackers] proposal for 2.51.4_rc1 Message-ID: I have merged T?ivo's Windows x86_64 bugfix, and several other things, so it seems time for a new micro release. (It seems that we are getting more testing of the actual release than we did of release candidates, but I'd still like to do them.) Open pull requests are now down to things that need more thought/testing or are more disruptive. I don't see any open issues that I expect to see fixed in the next few days. I have packaged current master 54d8e79 as pkgsrc/net/unison-snapshot and run it on NetBSD/8 against older 2.51 on a Mac and other NetBSD. So from my own testing it looks fine. So I propose to move towards 2.51.4 based on 54d8e79. (This does not mean that a .5 can't happen; my opinion is that extra micro releases that are inter-compatible do not hurt because the updates are easy and don't need to be synchronized. This release also has no bearing on an eventual new wire protocol.) Would anyone like to speak for or against this plan, or propose a different one? Absent comments against, I'll do this, probably Wednesday. Here's what's changed since v2.51.3 $ git log --oneline --reverse v2.51.3.. 26c9245 Allow diffing from older to newer file b9fe878 copyonconflict: create a conflict copy for deleted... 341e9f5 Add signal handler for SIGUSR1 to close logfile 68198b6 Explain SIGUSR1 behavior in help and manual c45c62d Skip user actions after reconciliation in batch mode fc8fc07 Replace deprecated String functions 2825f5f Change version to 2.51.3.70 508f05b Assume documentation strings are in UTF-8 9f57030 Fix const warnings related to safe strings 8d1ca6a Fix another const warning in inotify_stubs.c b477658 Merge pull request #410 from glondu/fix-gtk2-docstrings bfff332 Merge pull request #405 from glondu/fix-const cabbe52 Merge pull request #404 from tleedjarv/fix-latin1 8613b0d Merge pull request #365 from thingsconnected/pullreq1 9aa91d6 report time taken propagating changes 6addcd0 Add ANSI color to text UI, with user preference 4fed48b Merge pull request #360 from tleedjarv/ansicolor b6e3593 Merge pull request #402 from tleedjarv/mem 4078d1d Merge pull request #390 from thingsconnected/pullreq2 b78c829 Stop using deprecated & operator (Closes: #414) 73f1bfa Merge pull request #415 from glondu/fix-deprecated-and 77be198 uitext: selectAction: Fix tail call optimization 05d29d9 Merge pull request #418 from tleedjarv/fix-314 5a4fbbe Merge pull request #362 from tleedjarv/diff cc74f93 Fix incompatible type on certain platforms 83e13e9 Do not set USR1 signal handler on Windows 73d6a8c Merge pull request #420 from tleedjarv/fix-365 de70ac4 Merge pull request #419 from tleedjarv/fix-166 54d8e79 (HEAD -> master, upstream/master) Merge pull request #373 from tleedjarv/fix-6 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From steph at glondu.net Wed Nov 4 01:45:45 2020 From: steph at glondu.net (=?UTF-8?Q?St=c3=a9phane_Glondu?=) Date: Wed, 4 Nov 2020 07:45:45 +0100 Subject: [Unison-hackers] proposal for 2.51.4_rc1 In-Reply-To: References: Message-ID: <0d9d8cd8-3394-2971-5bc6-01096724906c@glondu.net> Le 02/11/2020 ? 20:04, Greg Troxel a ?crit?: > Would anyone like to speak for or against this plan, or propose a > different one? > > Absent comments against, I'll do this, probably Wednesday. Documentation (especially changes.tex) should be updated with (a summary of) the changes, the version number must be updated and strings.ml et al. must be regenerated (LC_ALL=C.UTF-8 make export). Cheers, -- St?phane From gdt at lexort.com Thu Nov 5 10:54:52 2020 From: gdt at lexort.com (Greg Troxel) Date: Thu, 05 Nov 2020 10:54:52 -0500 Subject: [Unison-hackers] mac.app fixes and 2.51.4 In-Reply-To: (Greg Troxel's message of "Mon, 02 Nov 2020 14:04:08 -0500") References: Message-ID: I would really like to get this in for 2.51.4, given the users' list traffic, but it will need some Mac users to test/etc. https://github.com/bcpierce00/unison/pull/423 I do have a mac at 10.13 but it will take me until at least next week to look at it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From gdt at lexort.com Tue Nov 10 08:58:08 2020 From: gdt at lexort.com (Greg Troxel) Date: Tue, 10 Nov 2020 08:58:08 -0500 Subject: [Unison-hackers] relationship of CI and build Message-ID: This is a comment on https://github.com/bcpierce00/unison/pull/427 as part of a larger and very helpful discussion that is untangling and improving a lot of things. I am copying it here as I find the github discussion style to be contrary to the "development discussion is on the mailinglist" norm -- not anyone here's fault: this is what happens with github. ---------------------------------------- I think we need to be very careful about what should be part of tests and what should be part of CI. We should keep in mind that we are off the rails of Free Software by using proprietary CI. While it's convenient now, I don't think it's a good thing, and we should be careful to have it entangled as little as possible. Things should be set up so that anyone who wants can set up some other CI system. Also, with respect to Free Software norms, people being able to build from source has to be the main approach. It may be that many people use binaries, but that is only ok when it is merely a convenience. It's an important principle that users can run builds, packaging, and tests. And use those procedures for CI if they want. So I don't think we should even consider having behavior differ when run under github CI. The desire for differences I see as a clue that there is some other problem, and instead we should fix that problem. So stepping back, there should be documentation of build environment prerequisites a build procedure, that anyone can run by checking out the repo and invoking some short command, via scripts/whatever in the repo a test procedure, that perhaps requires build to have been done, that anyone can run, again scripted an install procedure, that puts the binaries either in the running system, or in some DESTDIR (for packaging), again that anyone can run optionally (as I believe this is really not the proper domain of a project, but obviously users expect this), a packaging procedure that takes the results of the install and bundles it up some kind of CI, that is a wrapper that basically sets up an environment and runs the previous steps. The CI wrapper should not contain anything that belongs in the previous steps, or rather, if it does, that content should be hoisted to the step itself. That means running tests on packaged bits to me feels irregular. Normally, tests are run on the built products before they are installed, and people only install when they pass. So I think we should fix the unison/unison-gtk build collision, not as a CI patch, but for real. I don't think it is hard and all that is required is the will to do it (and picking a name). That takes most of the trouble off the table if after having built, on some platform, one can't run, because of some dll trouble, add a wrapper script that makes that come out right, and then use that wrapper in tests probably a bunch of other small things Finally, I don't mean to criticize anyone's efforts or how we got where we are. This is all complicated and we have had many local optimizations. We are in far far better shape than we ever have been with respect to packaging/etc. I am merely trying to step back and look at the big picture. Greg Troxel From gdt at lexort.com Tue Nov 10 09:19:22 2020 From: gdt at lexort.com (Greg Troxel) Date: Tue, 10 Nov 2020 09:19:22 -0500 Subject: [Unison-hackers] rc not yet, naming of GUI In-Reply-To: (Greg Troxel's message of "Tue, 10 Nov 2020 08:58:08 -0500") References: Message-ID: (I have not made an rc, because there is now a lot of activity that is leading to mergeable improvements.) unison's build system has a notion that one builds with a UISTYLE, and this produces a binary "unison" that either does or doesn't have a GUI. For an individual building unison, this is fine, but it doesn't play well with packaging systems. As I understand it, some packaging systems build it both ways, so that there is unison (text) and unison-gtk (GUI). (pkgsrc has an option, which defaults off, partly because of this problem, and partly to avoid depending on gtk2.) Recently, issues have come up in CI where tests need to be run on the text version (because of another issue that can be fixed), and thus there is sequencing of build text, test, build GUI as a workaround. These two things, packaging system decisions and test awkwardness, argue strongly that building two different things to the same filename is not an ok thing to do. This is captured in https://github.com/bcpierce00/unison/issues/394 I think this is pretty easy to fix, and we just need to pick a name for the GUI build. The only two I've seen talked about are unison-gtk unison-gui The first is in use by packaging systems, so that is less of a change to many people. The second is more general. Looking forward, we hope to move to lablgtk3: https://github.com/bcpierce00/unison/issues/358 but I see that as a move, not being a new option (gtk2 is obsolete). unison-gtk remains a good name for that. (However, I can see the point of picking unison-gtk2, and later gtk3. I favor making UISTYLE=gtk the norm, with gtk2 a deprecated alias.) Should there be some gui that isn't gtk, that might well need a different name, but it is very likely that whereever that new thing runs gtk would too, so a new name seems good. I will observe that if people want 'unison' to be the gtk system on their installed system, they are free to do that, similarly to how packging systems have made the reverse change. We could add an install target "install-gtk-as-unison" that is like "make install" but installs unison-gtk as unison. The biggest reason to do this is to avoid a lot of difficulty in making the build/test/install/packaging process work, and work with CI, and right now that difficulty is falling on a very small number of people. (There is perhaps another issue, which is that individual object files may be built differently and thus need to be in separate dirs, but if so that is far less important and can be addressed as a further step.) So, are they any objections to a commit that would read like Change GUI build to create unison-gtk When builing with UISTYLE=gtk2, place the compiled binary in unison-gtk rather than unison. This avoids overwriting the previous UISTYLE=text build and thus avoids conflicts with CI. It regularizes the notion of which program name has GUI support, aligning with existing packaging. followed by commits to packaging and CI/etc. that adopt to this. A bit of a kerfluffle, but very low risk of hard-to-debug trouble. Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: