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