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: >>> >>> 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
