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: >>> >> >> Should have removed the redundant signatures and reuploaded to >> https://keys.openpgp.org, though I don't think I had 5 signatures on the >> same IDs? Anyway, PTAL. > > Web interface: > keys.openpgp.org > Error: No key found for email address manp...@gmail.com > > $ gpg --search-keys manp...@gmail.com > gpg: data source: https://keys.openpgp.org:443 > gpg: key "manp...@gmail.com" not found on keyserver > gpg: keyserver search failed: Not found
Hmm, indeed I also cannot search it through my email. However, directly search the fingerprint works: ,---- | $ gpg --search-key 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 > N `---- I wonder what I could have done wrong that it doesn't index my email address? > > Strictly speaking, you don't need to worry about your key until you > start wanting to make uploads (mentors, Debian Maintainer per-package > upload privileges, Debian Developer uploading), so we can defer this. Sounds good. > >>> What is your intention here? Are you rebasing our package onto this >>> fork, or are you using the fork as a code dump, or something else? >>> >> >> Well to be honest I didn't realize the github one was a fork as the >> d/watch file had been pointing there. > > "git blame debian/watch" to see who is to blame, and fix fdde4981, which > introduced this problem. > > This is a blocker to uploading the package. Fixed d/watch track the savannah git repo instead[1]. 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). 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). 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. 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 > >> Also from your other mail: > > Thank you for merging these emails. > >>> I found that this UTF8 issue was already fixed upstream: >>> >>> @@ -412,11 +433,11 @@ >>> >>> https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?h=externals/muse&id=be347db7f1ad56f0384f76011bfd148ff3352610 >>> >>> and note that it's now an official GNU project (via copyright assignment) >>> >>> Copyright (C) 2004-2020 Free Software Foundation, Inc. >> >> So it should be clear that the Savannah one should be considered the >> canonical upstream. I'll update my question on github to ask for >> whether Alex want to forward the patches in his repo to Savannah as >> well. > > Thanks. > >> Also as a result, I've marked the patch as "Forwarded: not-needed". > > Thank you. Alternatively you can either cherry pick the upstream commit > (and export as quilt patch) and drop mine, or package a new upstream > snapshot from the savannah source, since that's what we're tracking. As discussed above, would like to postpone the sync later and actually decide what to do. > >>> Oh, there's one more thing that needs to be fixed before we upload: >>> Bug #1048114 >> >> Attempted to fix it in [2] where I just regenerated the changing file in >> sbuild. >> >> [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. > Have you checked Savannah for a fix? The Savannah repo doesn't even work as the Makefile is broken. > 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. > > 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. 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. > > > 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, I'll wait for your comments before regenerating and uploading to mentors. Thanks! > Regards, > Nicholas > [1] https://salsa.debian.org/emacsen-team/muse-el/-/commit/897af6d17a87f9c4e11af2d4c3460c3b1f45808b [2] https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages#n459 [3] https://salsa.debian.org/emacsen-team/muse-el/-/commit/3a963d96fa01084f11ab8c2d5eed77d5b4afeccd [4] https://salsa.debian.org/emacsen-team/muse-el/-/blob/master/lisp/Makefile#L21-23 -- Manphiz
signature.asc
Description: PGP signature
