Re: Is monotone dead, or is there a path forward?
Michael Raskin <[email protected]> Sun, 06 Jun 2021 16:41:43 +0200
| Newsgroups | gmane.comp.version-control.monotone.devel |
|---|---|
| Message-ID | <[email protected]> |
>On Sat, Jun 05, 2021 at 05:51:38PM +0200, Michael Raskin wrote: >> >Is anything being done about this? >> >Is the current botan so incompatible that it's hopeless to adapt? >> > >> >Or is monotone development and maintenance truly dead and I need to=20 >> >abandon ship and take what data I ca with me? >>=20 >> 1. You can easily check out a branch that actually works with botan2. >> I package it for Nixpkgs and it seems to work just fine. Unfortunately >> from bootstrapping point of view, you need some monotone to check out >> botan2-compatible monotone (for packaging I exported the branch to=20 >> GitHub) > >Very interesting. So it looks like making a proper devuan package for=20 >monotone would require taking the old source deb, replacing the code=20 >with your code, and updating the various dependencies in the old=20 >manifest to new ones. Not even my code! People involved in Monotone development for a long=20 time had already done all the actual work=E2=80=A6 just not the release. >Even without understanding much about debian packaging, that sounds=20 >feasible. > >Where do I find the relevant monotone repositories. (I very much want=20 >to preserve history while doing this.) Yeah, I used monotone's git-export for the same reason. I had to assign=20 some dates to some commits where I did not pull the proper date certs (and Monotone's fast-export dummy date is before git's epoch leading to=20 problems) mtn://code.monotone.ca?net.venge.monotone.lapo.botan2 We already had the following patch applied, so it is not incorporated in the mirror as it was not in the original branch: https://github.com/NixOS/nixpkgs/blob/92c9d7975a828bce3bc8597a83b0bd091fd1= ab72/pkgs/applications/version-management/monotone/monotone-1.1-Adapt-to-c= hanges-in-pcre-8.42.patch >Do the repositories also contain the code normally used to create deb=20 >packages? I am no very familiar with the existing monotone code=20 >infrastructure, nor with the processes required to submit an update to a=20= >dropped Debian package. I think this lives separately in tags like debian-monotone-1.1-8 >And what kind of test procedures are there for vetting a monotone=20 >release? Good question=E2=80=A6 also, good question whether this is now a forgotten=20 arcane knowledge.