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 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 > 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. > 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. At some point it might also be nice to see DEP12 implemented in this package: https://dep-team.pages.debian.net/deps/dep12/ > 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). >>> [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. >> 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! > I'll wait for your comments before regenerating and uploading to > mentors. :) Best, Nicholas
signature.asc
Description: PGP signature
