>On 2021-05-08 13:22, Michael Raskin wrote: >> Hello >> I am trying to maintain a Monotone package in Nixpkgs. Currently >> the Botan 1 version needed to build the latest Monotone release seems to >> get a bunch of vulnerabilities reported (and so is marked insecure in >> Nixpkgs). I have used net.venge.monotone.lapo.botan2 branch and the PCRE >> 8.42 patch by Petr Písař to build Monotone with fresher versions and >> indeed it works fine, syncs with 1.1 releases etc. However, right now >> the only way I can grab it is via Monotone netsync, which is not good >> for a Monotone package in a distribution package repository. > >If a bit of testing effort can be put together I think we better create >a proper new release with those patches included, as when I fixed botan2 >patch in April I just didn't have enough time to ensure it was working >for everyone (I only checked it was working "enough for me").
Thank you again! I can definitely confirm it words well enough for me, which includes sync with an older installation (and normal use, although I happen to do merges inside the same branch and haven't done a propagate recently). I guess the question is how we reach everyone (left)? Then, whether the functional test coverage is complete enough, and maybe do we want to have some amount of installed-tests (given a checklist, I could write those over time as a script, and maybe store nearby the Nix expression so that they can be used in Nixpkgs CI, too) >Basically, I don't have time to be a proper maintainer, but if patches >are created and tested together… I think I can take time to create new >releases from time to time. Proper as in «lead hash function migration»? Because otherwise, it feels like a maintenance-mode where no new features are ever expected but patches forced by outside changes are eventually accepted and released _is_ what I would call maintenance. >Last releases were cut by Markus but with some reading docs I could do >it given enough time, I think. >(I am the maintainer of the server that host's the website too, so >accesses are not a problem) > >-- >Lapo Luchini >[email protected] > >
