On Sat, May 05, 2018 at 12:23:00AM +0000, Joseph Herlant wrote: > Hi guys, > Sure we can backport it, there's one bug I need to fix first but we have > to keep in mind that asciidoc is deprecated (see #895462) so it might be > better to just migrate the doc/manpage generation to a tool that has an > actual active upstream... > I was waiting for asciidoctor's release (they did it yesterday so now I > need to push it to Debian) to start again on the migration work with the > different upstreams. > I can prioritize the move of git to something else if that helps. > Joseph > On Fri, May 4, 2018, 5:10 PM Mert Dirik <[1]mertdirik@gmail.com> wrote: > > On Fri, May 4, 2018, 22:58 Nicholas D Steeves <[2]nsteeves@gmail.com> > wrote: > > Dear Joseph, > > Are you interested in maintaining a stretch-backport of asciidoc? > Please let me know either way, because updating the bpo of git > requires it and I'd be happy to maintain a bpo of asciidoc if > necessary. Oh, and please CC me your reply. > > Thank you :-) > Nicholas > > I've recently backported a git version in sid privately and removing the > version constraint of asciidoc dependency was enough to get the package > built and run successfully. AFAIK the newer asciidoc version is only > required for reproducable builds and not a hard requirement for build > and test suite. Joseph, that's a very good point! Yes, I agree that the best way forward would be to transition git to asciidoctor. eg: if asciidoc was backported, and then dropped from unstable (and thus testing) then I think an asciidoc~bpo removal request would become a necessary hassle. Asciidoctor/1.5.4-2 is available in stretch. Is it new enough? In the spirit of quid pro quo, please let me know if there's anything I can do to help with the git-el to magit mini-transition :-) Mert, you're right about minimal requirements. That said, I think the data provided by reproducible builds and autopkgtests/DebCI helps support the case that the backports repository is a higher quality source of updates than other distributions' alternatives. Yes, in this case it seems only documentation is affected... ;-) Honestly, I'm not looking forward to fixing an unreproducible build in one of my own packages (only affects documentation) because it will require adding generate-date-stamp-for-a-specific-date functionality to a project that is dead upstream. Take care, Nicholas
Attachment:
signature.asc
Description: PGP signature