Nicholas D Steeves <s...@debian.org> writes: > Thank you for the ping! > > Manphiz <manp...@gmail.com> writes: > >> Nicholas D Steeves <s...@debian.org> writes: >>> Manphiz <manp...@gmail.com> writes: >>>> Nicholas D Steeves <s...@debian.org> writes: >>>>> Manphiz <manp...@gmail.com> writes: >>>>>> Nicholas D Steeves <s...@debian.org> writes: >>>>>>>> Nicholas D Steeves <nstee...@gmail.com> writes: >> >>>> However, as it turns out, the savannah repo has a completely different >>>> layout compared to the current one we package (which is actually based >>>> on github). >>> >> I see. Thanks for the background. I think I was meant to say that "the >> repo structure is more like the github one" to be clear. Looking at the >> git log on Savannah, it looks like they changed the directory structure >> on the first commit when importing[2]. > > You're welcome. Yes, I agree that the github fork's structure has > diverged less, and I vaguely remember that that may have been one of the > reasons why I chose to watch it for future releases, but the then tag > never materialised. As noted previously, I'm ok with switching to the > fork if that's what you'd prefer to do long-term! As the maintainer you > get to pick the most high-quality and well-maintained upstream for the > Debian source, because you're the one who is responsible to our users. >
Sounds good. I'll give it a little more thoughts. >>>> In fact, the savannah one uses a Makefile that assumes the project >>>> layout as the github one while some of the directories like "lisp" are >>>> not even there (which makes me think whether targeting the savannah >>>> repo is the correct choice). >>> >>> Some words appear to be missing, so I don't understand what you mean. >>> Please consult d/rules to learn why an upstream Makefile is irrelevant >>> by-design to this package. Also, consult the dh-elpa man page and >>> perhaps also team documentation on our wiki. It's also worth consulting >>> MELPA packages (and the source used by MELPA) to see how Makefile's >>> aren't needed there either. >> >> I kinda know that an Emacs addon doesn't really require a Makefile to be >> usable for melpa. Still, I still consider leaving a non-working >> Makefile around a bad habit. Anyway, point taken. > > Agreed, it's technical debt at this point. As the new Debian > maintainer, please consider sending this upstream a patch or a request > to remove the unused file. > Indeed. Will experiment some more when working on the next revision. >>>> Therefore, I'd like to postpone the sync with savannah repo to a >>>> future upload to avoid more immediate work for uploading if that's OK. >>> >>> That's OK with me! As noted previously, I'll support the decision you >>> make in your choice of future upstream, but it needs to be a conscious >>> and principled decision. If you don't want to decide at this time, >>> please implement a method that will remind you (or a future maintainer) >>> to investigate and fix this issue. Tldr, we don't want to switch back >>> and forth between GNU source and fork source. >>> >> >> Added a reminder in d/watch as a future work[3]. > > Do you mind if I enhance this significantly? Find proposal in-line, at > the end of the email. No problem! Patch applied, rebuilt, and reuploaded to mentors[1]. PTAL. [1] https://mentors.debian.net/package/muse-el/ > Also, I'd like this to be more visible, so I'll > file a bug titled something like "Choose living upstream for muse-el, > and merge updates" if you don't. I'm vaguely starting to remember that > the issue about a future upstream was raised during my early > contributions, but then I forgot all about it ;) Also, as the fixes for > Emacs compat eventually start accumulating we'll end up becoming a > second fork. > Makes sense. Filed Bug#1051247 for tracking. Will probably get to it in the next revision. >>>> Another hackier way I can think of is to build-deps on git and run "git >>>> restore" in override_dh_auto_clean, but I felt requiring the repo to be >>>> a git repo may fail buildd? Not sure though. Anyway, it seems using a >>>> patch is a cleaner solution compared to this. >>> >>> Right, you cannot use git restore. If we used the upstream Makefile's >>> "make clean" target, I would concede that patching the Makefile was the >>> correct approach. >>> >> >> Ah OK. I understand your reasoning. I've reverted the patch approach >> and as an alternative implemented the approach in [4] in the spirit of >> autoreconf. PTAL. > > LGTM. > > > > diff --git a/debian/changelog b/debian/changelog > index b172159..725e7bd 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -19,11 +19,15 @@ muse-el (3.20+dfsg-8) unstable; urgency=medium > workaround #1021502. > * Drop section referencing non-existing file in debian/copyright to fix > lintian warning superfluous-file-pattern. > - * Fix d/watch to track the savannah git repo. > * Drop lintian override of wrong-section-according-to-package-name. > * Save and restore lisp/muse-autoloads.el to prevent it from changing > when build-twice-in-a-row. Closes: #1048114. > > + [ Xiyue Deng & Nicholas D Steeves ] > + * Correct watch file so that it tracks the official GNU project on > Savannah, > + rather than the fork on Github. Additionally, start tracking all > upstream > + activity (not just tags). > + > -- Xiyue Deng <manp...@gmail.com> Thu, 24 Aug 2023 14:12:01 -0700 > > muse-el (3.20+dfsg-7) unstable; urgency=medium > diff --git a/debian/watch b/debian/watch > index 72b2e40..02072a0 100644 > --- a/debian/watch > +++ b/debian/watch > @@ -1,5 +1,7 @@ > -# The current repo is not yet synced to savannah and should be done in a > future > -# commit. > +# The Debian source for upstream version 3.20+dfsg predates the > +# transfer of Muse to GNU, as an official GNU project; Our source has > +# not yet merged any of the upstream activity that this new watch file > +# tracks, but this should be done at some point. > > version=4 > opts="mode=git, dversionmangle=auto, pretty=3.20+git%cd.%h" \ > -- Manphiz
signature.asc
Description: PGP signature
