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.
>>> 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.
>>> 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. 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.
>>> 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" \
signature.asc
Description: PGP signature
