darcs repository web UI and hosting app. This is the main darcsden trunk, which also runs hub.darcs.net. (https://hub.darcs.net)
#186upgrade darcs dependency to darcs-2.14
My fork at https://hub.darcs.net/bf/darcsden-darcs-2.14 has all the patches needed. However, it does currently not include
patch 6a7d2b2da168d21b83019c5190749574b2c7eb89 Author: alex@xanderio.de Date: Tue Sep 11 23:50:10 CEST 2018 * Added a config file option to disableGravator
This work has been done to make darcsden a little bit GDPR compatible
That one gives me very strange build errors with ghc-8.2.2.
Please review and pull. I think I didn't break anything, but I am not as familiar with darcsden's internals as I would like to and I have no way to test that the changes actually work.
Thanks @bf! I'll check it soon.
I also found and pushed a fix for the problem introduced by the above mentioned patch.
I have successfully built these, after removing the "Add ability to use send from client side to bundles feature" patch (and updating stack.yaml/package.yaml).
I see they make darcsden build only with darcs 2.14. That's ok for darcs hub, is it ok for the other potential darcsden users we discussed on mail list ? I'm ok with it if you are.
Have you exercised your build of this new darcsden much ? Next step for me I guess is to install it as the darcsden dev instance and solicit more testing. And study http://hackage.haskell.org/package/darcs-2.14.2/changelog for things visible to darcshub users. Any notable changes you can think of, from an ops or UX point of view ?
I didn't exercise it much but I don't expect problems. It has been a while since 2.14, so I had to look at the changelog, too. There are almost no new features in 2.14, the vast majority of changes are internal refactors or bug fixes. I guess the most user visible change is the fist mentioned point (fix the encoding business), which means darcs can now finally handle arbitrary encodings of filenames and meta data. None of the API changes that required adapting darcsden were due to changed functionality, it's all been about refactors.
The dev server https://hub-dev.darcs.net is up again, and build with darcs 2.14.4. I'll try to keep it running, and I invite you to use it instead of the production server to give it a shakedown. (It manages the same repos.)
Update: there was a problem, which is visible eg at https://hub-dev.darcs.net/simon/darcsden ("getSymbolicLinkStatus: does not exist (No such file or directory)"). Ben and I had some email discussion in June/July - excerpts:
> It feels like there's some new code in darcs 2.14 that assumes it's in the repo directory, which is a safe assumption for darcs but not for libdarcs.
> "Yes, this is something I have also suspected just now. In general, most of the darcslib functions, especially those from Darcs.Repository.* assume that the cwd is the repo top. This is bad, but it's been this way for a long time."
Reformatted: some notes on reproducing:
> > On Jul 1, 2020, at 2:25 AM, Ben Franksen <ben.franksen@online.de> wrote: > > > > Am 01.07.20 um 02:05 schrieb Simon Michael: > > > On Jun 30, 2020, at 12:18 PM, Simon Michael <simon@joyful.com> wrote: > > > > This file, > > > > _darcs/pristine.hashed/b2ed413769e3d10d891b668698f37b964415dac1b7b4675a38b13f3d4cb50c1d, > > > > exists under /home/darcshub/src/darcsden, so the error doesn't > > > > happen when I run darcsden from there. Usually I run darcsden from > > > > /home/darcshub, which causes the error. I'll find out what part of > > > > code is trying to access this file. > > > > > > > Bah, and now it has fixed itself: the error is gone from > > > https://hub-dev.darcs.net/simon/darcsden > > > <https://hub-dev.darcs.net/simon/darcsden> . I can only think perhaps > > > because of pushes/pulls I've done to that repo ? I'm still running > > > darcsden from /home/darcshub, and that file is still not present in > > > /home/darcshub/_darcs/pristine.hashed. > > > > > If you push to a repo then its pristine will normally change, which > > means some files may no longer be referenced and thus garbage. > > > > When I obliterate the last two patches in a clone > > > > patch 201a47d15c19f3a9233fb210627588891415ddb6 > > Author: Simon Michael <simon@joyful.com> > > Date: Wed Jul 1 02:38:08 CEST 2020 > > * the ghc 8.6 stack build plan requires latest ssh, actually > > > > patch 744025814fcffacad677ad06a7c43caf27872e6e > > Author: Simon Michael <simon@joyful.com> > > Date: Tue Jun 30 21:26:31 CEST 2020 > > * switch to GHC 8.6 > > > > I see the missing file: > > > > ben@home[1]:.../scratch/darcsden>ll > > _darcs/pristine.hashed/b2ed413769e3d10d891b668698f37b964415dac1b7b4675a38b13f3d4cb50c1d > > -rw-rw-r-- 1 ben ben 4518 Jul 1 10:19 > > _darcs/pristine.hashed/b2ed413769e3d10d891b668698f37b964415dac1b7b4675a38b13f3d4cb50c1d > > > > Then a > > > > ben@home[1]:.../scratch/darcsden_1>zcat > > _darcs/pristine.hashed/b2ed413769e3d10d891b668698f37b964415dac1b7b4675a38b13f3d4cb50c1d|head > > > > Tells me this file represents the state of README.md before the "switch > > to GHC 8.6" patch. > > > > The darcsden code you pointed me at looks good and should work. I really > > think this is a darcs bug, not one in darcsden. The symptoms suggest > > that due to some glitch, probably a bug in darcs-2.12.5, the pristine > > was missing the above file. At this point I cannot tell you why this > > problem appeared or why it did not show in darcs-2.12.5 but it did when > > using darcs-2.14.4. > > > > Next time something like this happens, please immediately save the > > affected repo in a tar ball and send it to me. I might be able to figure > > out what's been going wrong but I need to be able to reproduce the exact > > repo state at the point where it fails. > > Thanks for the info Ben. Indeed obliterate / push seems to be a way > to trigger / repair the error, but not reliably. Here's an example I > can reproduce right now, and I think you could too: > > https://hub-dev.darcs.net/simon/ssh is currently in the error state. > > I fork it to make a test copy: > https://hub-dev.darcs.net/simon/ssh/fork , name: ssh-test. The new > branch https://hub-dev.darcs.net/simon/ssh-darcsden-error is also in > the error state. > > I clone this branch to a local copy (or ensure my local ssh copy is > up to date). Now I obliterate the last 3 patches from the branch: > ssh hub.darcs.net obliterate ssh-darcsden-error y y y d. The error > goes away. Note this is using old darcsden-ssh compiled with darcs > 2.12, but I have also seen it happen when I logged in to the server > and used darcs-2.14.4 obliterate on the command line. > > And if I push back just one patch ("* update metadata, add me as > comaintainer"), the error returns.I guess the next thing to do is to call Darcs.Util.Global.setDebugMode at startup and redirect stderr to a file. This is then as if you pass --debug to all darcs commands. This can generate very large amounts of output so make sure you have enough disk space. If you temporarily allow access to this file (via the webserver or in some other way) I could study the debug log to get an idea where precisely things are going wrong.hub-dev is now generating debug output. I haven't yet managed to reproduce the failure reliably enough to capture it. It comes and goes.
Indeed I just tried the link and it worked. If the error comes and goes like this then we have (most probably) a race condition somewhere. I believe before you added debug output the error was easier to reproduce, correct? That would be another indicator for a race condition.
> bfrk: BTW, in case you didn't see it. https://hub.darcs.net/bf/darcsden-darcs-2.16 compiles fine against darcs-2.16.3 with ghc-8.2.2, ghc-8.4.4 ghc-6.5.2 (and probably ghc-8.8.4, it is still compiling pandoc...)
https://hub-dev.darcs.net is now running the latest darcsden code linked with darcs 2.16.5. This issue is either gone, or still intermittently lurking (the page is working right now). Cc @bf
