Bug#1016558: ITA: muse-el
- To: Nicholas D Steeves <sten@debian.org>
- Cc: 1016558@bugs.debian.org
- Subject: Bug#1016558: ITA: muse-el
- From: Manphiz <manphiz@gmail.com>
- Date: Sun, 03 Sep 2023 02:59:48 -0700
- Message-id: <[🔎] 878r9n8tm3.fsf@debian-hx90.lan>
- Reply-to: Manphiz <manphiz@gmail.com>, 1016558@bugs.debian.org
- In-reply-to: <87o7ivwmwc.fsf@debian-hx90.lan> (manphiz@gmail.com's message of "Fri, 25 Aug 2023 01:23:47 -0700")
- References: <87350xbaee.fsf@navis.mail-host-address-is-not-set> <87h6pd3we1.fsf@debian-hx90.lan> <871qggdi2p.fsf@digitalmercury.freeddns.org> <87cz004ldt.fsf@debian-hx90.lan> <165947710558.381266.4431546207937753844.reportbug@bras-base-mtrlpq0313w-grc-09-50-100-165-107.dsl.bell.ca> <CAD=QJKhmQv768aPr0b2=CwoRLZnDuHyq0yP49=Q1wDbpOs76sw@mail.gmail.com> <87il9lypye.fsf_-_@debian-hx90.lan> <878rabkjnh.fsf@digitalmercury.freeddns.org> <877cpskm4x.fsf@debian-hx90.lan> <87msyhla95.fsf@digitalmercury.freeddns.org> <87sf88w1l3.fsf@debian-hx90.lan> <87fs47ex7l.fsf@digitalmercury.freeddns.org> <87o7ivwmwc.fsf@debian-hx90.lan> <165947710558.381266.4431546207937753844.reportbug@bras-base-mtrlpq0313w-grc-09-50-100-165-107.dsl.bell.ca>
Manphiz <manphiz@gmail.com> writes:
> Nicholas D Steeves <sten@debian.org> writes:
>
>> Manphiz <manphiz@gmail.com> writes:
>>
>>> Nicholas D Steeves <sten@debian.org> writes:
>>>
>>>> Manphiz <manphiz@gmail.com> writes:
>>>>
>>>>> Nicholas D Steeves <sten@debian.org> writes:
>>>>>>> Nicholas D Steeves <nsteeves@gmail.com> writes:
>>>
>>> Hmm, indeed I also cannot search it through my email. However, directly
>>> search the fingerprint works:
>> [snip]
>>> I wonder what I could have done wrong that it doesn't index my email
>>> address?
>>
>> gpg --search-keys 88A41F77AA3CD668C8F8B5802DE965ED63825C93
>> gpg: data source: https://keys.openpgp.org:443
>> (1) 4096 bit RSA key 2DE965ED63825C93, created: 2015-11-20
>> Keys 1-1 of 1 for "88A41F77AA3CD668C8F8B5802DE965ED63825C93". Enter number(s), N)ext, or Q)uit > 1
>> gpg: key 2DE965ED63825C93: new key but contains no user ID - skipped
>> gpg: Total number processed: 1
>> gpg: w/o user IDs: 1
>
> OK, so it turns out I'm missing an important RTFM step when trying to
> use keys.openpgp.org[1]: I need to manually verify each of my
> identities. I get mixed feeling about this as pgp.mit.edu worked
> out-of-the-box with just "gpg --send-key". Ah well, they have their
> reasons.
>
>>
>> It appears that all identities were deleted. Since you agree this can
>> be defer this for later, this is just an FYI :) I think the way your QA
>> page will work is that all identities attached to
>> 88A41F77AA3CD668C8F8B5802DE965ED63825C93 will appear, so we can
>> introduce it later, but to be honest I've never tested this approach.
>>
>> https://qa.debian.org/developer.php
>> https://contributors.debian.org/
>>
>>> 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'm partially to blame for this confusion; just now, I used
>> git-timemachine to step back through the watch history until I found
>> d7dea867b86c. My mistake was thinking it was ok to use the github
>> tag/release service as a notification mechanism, when the true source of
>> this release (not git snapshot) was git://repo.or.cz; if I remember
>> correctly, the fork was just a mirror back then, and/or it was still in
>> the "wait and see what GNU does" period of this software's maturation.
>> See the changelog entry for 3.20+dfsg-1.
>>
>> The github fork of course replicates the history of repo.or.cz, and at
>> the time I set the watch file to track github, uscan didn't yet have
>> mode=git (or it was experimental and/or we didn't have lightweight
>> clones yet). In other words, that was an inaccurate hack of mine, and I
>> should have written a comment in the watch file...sorry about that, I
>> didn't know better at the time.
>>
>> No, our source is not "actually based on github". Did you notice that
>> we don't have upstream git history in this repository? 3.20 was never
>> imported from git. Tldr: I created this repo with 'gbp import-dsc'.
>>
>> v3.20 from the official source at the time 3.20 was imported:
>> https://repo.or.cz/muse-el.git/snapshot/caaa41cbf959afb379516e88776ec374160b8a94.tar.gz
>>
>> which is identical to https://github.com/alexott/muse/archive/refs/tags/v3.20.tar.gz
>>
>
> 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].
>
>>> 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.
>
>>
>>> 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].
>
>> At some point it might also be nice to see DEP12 implemented in this
>> package: https://dep-team.pages.debian.net/deps/dep12/
>>
>
> Will take a look at the detail when merging the codebase.
>
>>> Meanwhile, when trying to figure out the emacs/elpa.git repo structure I
>>> realized that this repo is actually synced package repo on GNU Elpa as
>>> one of its branch, and the entry of muse in elpa-packages[2] says:
>>>
>>> ,----
>>> | (muse :url "https://github.com/alexott/muse") ;FIXME: Not nearly in-sync
>>> `----
>>>
>>> I guess the plot thickens, but I'll just let it be for now :P
>>
>> :) Fair, and yeah, the GNU monorepo is ugly... The new Debian
>> maintainer of this package should contact GNU via email on publicly
>> archived lists. If you don't want to do this at this time, that's ok,
>> but please do something with the watch file that makes this issue more
>> visible. If you don't want to contact upstream at this time, please
>> file a bug against the muse-el package to track this long-term
>> outstanding issue (future upstream source of the package).
>>
>
> Ditto. See above regarding [3].
>
>>>>> [1] https://github.com/alexott/muse/issues/16
>>>>> [2] https://salsa.debian.org/emacsen-team/muse-el/-/commit/f5c217162d9c6f45c971cec2b8c70b2794bb77fe
>>>>
>>>> This doesn't look like the right approach to me, the changelog entries
>>>> related to it are unclear/misleading, and a description is missing in
>>>> the patch header.
>>>
>>> Added an explanation[3] to the patch. So basically the file gets
>>> regenerated in this build rule[4], and as the generated file changes, it
>>> fails the second build. Use a patch is the simplest way so that the
>>> file stays the same each time it builds.
>>
>> Yes, I understood how it functions, which is why I was able to say that
>> it doesn't look like the right approach, and that the changelog entries
>> relating to it are unclear/misleading.
>>
>> Concretely, why is this approach a solution and not the introduction of
>> technical debt? We can discuss that here if necessary, but that's what
>> your patch and especially changelog entry need to say.
>>
>>>> Have you checked Savannah for a fix?
>>>
>>> The Savannah repo doesn't even work as the Makefile is broken.
>>
>> Why do you believe that the Makefile isn't an irrelevant cruft file?
>>
>>>> Rather than a Debian-specific approach, it's best to stay close to
>>>> upstream source whenever possible.
>>>
>>> Agreed. Probably we can forward the patch upstream for inclusion.
>>
>> In addition to writing why it's not introducing technical debt, yes,
>> please forward your patch to the GNU mailing list (check the Homepage
>> key in the source package)
>>
>>>> If the issue is truly Debian-specific, then why not use dh_auto_clean or
>>>> dh_clean, or another cleaner method?
>>>
>>> This doesn't work because the source file gets changed, and the 2nd
>>> build run will fail because of this.
>>
>> Yes, and they are designed to be customised when the right thing doesn't
>> happen by default. This problem can be solved with the addition of
>> three lines to debian/rules. Are you familiar with the principles
>> behind this document, and can you see how they apply to this package?
>>
>> https://wiki.debian.org/Autoreconf
>>
>>> 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.
>
>>>> Thank you for your attention to detail. We're just about done!
>>>
>>> Thanks for the comments! As there are several new things I'm not sure
>>> about,
>>
>> It's ok to not be sure, and I hope you're enjoying this mentorship
>> interaction. 'hope I addressed all relevant issues and didn't introduce
>> anything to grumble about!
>>
>
> Not at all! Thanks for your patience :)
>
>>> I'll wait for your comments before regenerating and uploading to
>>> mentors.
>>
>> :)
>>
>> Best,
>> Nicholas
>>
>
>
> [1] https://keys.openpgp.org/about/usage#gnupg-upload
> [2] https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?h=externals/muse&id=c76016220551b31df8148b2078d5adb688921694
> [3] https://salsa.debian.org/emacsen-team/muse-el/-/commit/e545d9767172567bb730993fa418e8dd98ed715a
> [4] https://salsa.debian.org/emacsen-team/muse-el/-/commit/559b7ee305ca56b8055b348265247a9bf17088e1
Friendly ping :)
--
Manphiz
Reply to: