Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Hello, Would you like to fix this RC bug and adopt the package? https://bugs.debian.org/1042911 and the orphan bug is here: #1016558 Best, Nicholas signature.asc Description: PGP signature
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Hello, Manphiz writes: >> Nicholas D Steeves writes: >> > > Hi Nicholas, > > I have now prepared a merge request to migrate away from assoc.el[1] and > also forwarded the patch upstream. Also set the package as team > maintained and add myself as an upload. PTAL. Thanks! Wow, that was fast! LTGM, with one caveat: You are an Uploader for this package now, so please drop the "Team upload" line entirely. This makes you the human maintainer for the package, so I have sent you an invitation for salsa/gitlab maintainer permissions for muse-el. > [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 You will notice that there are two other MRs. Please double-check that the bot did its work correctly, and please manually go through the Debian Policy upgrade checklist, starting with the version muse-el uses, and each version up to and including the one the bot proposed. If you would like to take credit for this work, I recommend adding "and your name" to the changelog entries the bot proposes. [ The name of the bot and your name ] In other words, I would like to give you permission to write to this repo! Bots will often rebase their MRs to save you time, and I will leave the decision of what gets merged first, and what gets rebased up to you. Let me know when your done, and we can talk about the next steps. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Hi, Reply follows inline. Can we move this discussion to #1016558 to not bother Axel with our discussion? Manphiz writes: > Nicholas D Steeves writes: >>>> Nicholas D Steeves writes: >>>> > Thanks! Though I'm not really a user of muse-el, I'd like to keep it in > a good shape as an exercise as an Emacs addon maintainer. It looks like > there is not too much work thanks to Elisp being a fairly stable > language :) That's fine, thank you once again for adopting it, and yes, generally everything is ok :) >>> [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 >> > Thanks for the tips! I checked the Debian Policy Upgrading Checklist[1] > and agreed with Debian Janitor on the "no changes are needed" bit. And > to avoid having to wait for the bot to do the rebase I've manually > resolved the conflicts and rebased my MR on top of it as well. > You're welcome, and good call. >> Let me know when your done, and we can talk about the next steps. > > Now all MRs are merged. Please advise the next steps. Thanks! > Wonderful! I also see you have a GPG key now. Have you generated revocations certificates yet? https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate Next, where can I find your key? I'm assuming that you're committed to maintaining this identity for the foreseeable future, and that you'd like to build reputation for future involvement in Debian. It's not required at the stage you're at, but it's recommended. https://wiki.debian.org/Keysigning#Step_3:_Make_your_public_key_public The subkey that I was able to download didn't include any identities. Other than that, this package isn't quite ready to upload, because there are three unaddressed lintian warnings. https://wiki.debian.org/Lintian Best, Nicholas signature.asc Description: PGP signature
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: > Nicholas D Steeves writes: > > > Hi, > > > > Reply follows inline. Can we move this discussion to #1016558 to not > > bother Axel with our discussion? I guess that's a no? > > Manphiz writes: > >> Nicholas D Steeves writes: > >>>>> Nicholas D Steeves writes: > > > > Wonderful! I also see you have a GPG key now. Have you generated > > revocations certificates yet? > > > > > > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate > > Now I have one. Thanks for the tip! You're welcome :) > > Next, where can I find your key? > > I have previously uploaded my GPG key to pgp.mit.edu[1]. Ah, that's where it was. I thought everyone had switched to https://keys.openpgp.org/ these days (this is the default server on Debian) after the end of the SKS network. Thanks for the reminder to continue to check pgp.mit.edu as a fallback. > Please advise if https://keyserver.ubuntu.com is still recommended for > prospective DMs. This is the first I've heard of that recommendation. I wonder if people in #debian-mentors (OFTC) will also be surprised? I'd use keyserver.ubuntu.com if I had a Launchpad account and maintained a PPA, but honestly wouldn't bother. I started using keys.openpgp.org since that's where various people expected to find my key haha. > I have a few more commits[2] that should have fixed most of the lintian > warnings. LGTM > There is another INFO level warning: > > I: muse-el source: patch-not-forwarded-upstream > [debian/patches/0005-convert-a-muse-init.el-example-to-UTF-8.patch] > > I wonder whether you would also like to forward this patch upstream. If you really want to, go ahead, but I'm not interested in the FSF's identity verification for copyright assignment process, so this might end up as a futile effort. In light of this, a "hey, we have a UTF8 conversion patch...would you like to convert your copy to UTF8 either with or without our patch" might be smoother. If you happen to have have done FSF copyright assignment paperwork, please go ahead and claim ownership of that trivial patch. I'm happy to sponsor from git when you finalise the changelog, but if ever you want to get some hands-on experience with dput (or dput-ng), then practise uploading to https://mentors.debian.net/. Best, Nicholas On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: > > Nicholas D Steeves writes: > > > Hi, > > > > Reply follows inline. Can we move this discussion to #1016558 to not > > bother Axel with our discussion? > > > > Manphiz writes: > > > >> Nicholas D Steeves writes: > >>>>> Nicholas D Steeves writes: > >>>>> > >> Thanks! Though I'm not really a user of muse-el, I'd like to keep it in > >> a good shape as an exercise as an Emacs addon maintainer. It looks like > >> there is not too much work thanks to Elisp being a fairly stable > >> language :) > > > > That's fine, thank you once again for adopting it, and yes, generally > > everything is ok :) > > > >>>> [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 > >>> > >> Thanks for the tips! I checked the Debian Policy Upgrading Checklist[1] > >> and agreed with Debian Janitor on the "no changes are needed" bit. And > >> to avoid having to wait for the bot to do the rebase I've manually > >> resolved the conflicts and rebased my MR on top of it as well. > >> > > > > You're welcome, and good call. > > > >>> Let me know when your done, and we can talk about the next steps. > >> > >> Now all MRs are merged. Please advise the next steps. Thanks! > >> > > > > Wonderful! I also see you have a GPG key now. Have you generated > > revocations certificates yet? > > > > > > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate > > Now I have one. Thanks for the tip! > > > > > Next, where can I find your key? > > I have previously uploaded my GPG key to pgp.mit.edu[1]. > > > I'm assuming that you're committed to > > maintaining this identity for the foreseeable future, and that you'd > > like to build reputation for future involvement in Debian. It's not > > required at the stage you're at, but it's recommended. > > > > https://wiki.debian.org/Keysigning#Step_3:_Make_your_public_key_public > > Please advise if https://keyserver.ubuntu.com is still recommended for >
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Control: block -1 by 1016558 Hi, I'm just updating this bug to note the adopted muse-el package is just about ready to upload (the ITA is also a pseudo-RFS bug), and I plan to upload in the next few days. If this update isn't enough to prevent autoremoval...well, at least the package will be fixed very soon. Regards, Nicholas signature.asc Description: PGP signature
Bug#857470: [patch] Suggests: btrfs-tools to btrfs-progs
Control: severity -1 important On Tue, May 08, 2018 at 08:19:52PM -0400, Nicholas D Steeves wrote: > Hi, > > On Tue, Oct 17, 2017 at 01:01:41PM -0400, Nicholas D Steeves wrote: > > Package: schroot > > Version: 1.6.10-3+b1 > > Followup-For: Bug #857470 > > Control: tags -1 + patch > > > > The attached patch is against 1.7.2-3 of the debian/experimental branch in > > VCS. Atternatively, against git tag "debian/1.7.2-3". > > > > Btrfs-progs is present in stretch so this will not cause problems in > > stretch-backports. > > > > I am also submitting patches for: > > systemd-container > > xen-tools > > udisks2 > > snapper > > lxc > > linaro-image-tools > > libguestfs0 > > kvpm > > fsarchiver > > btrbk > > > > Cheers, > > Nicholas > > It looks like the patch didn't make it into schroot/1.6.10-4. Would > someone please apply it to preemptively avoid breakage due to the > eventual (maybe in buster?) removal of the btrfs-tools dummy package. > > Thanks, > Nicholas Btrfs-tools transitional package was dropped 08 May with btrfs-progs/4.16.1-1. Bumping severity. Cheers, Nicholas signature.asc Description: PGP signature
Bug#891717: btrfs-progs: btrfs filesystem show takes a long time
Control: tag -1 + confirmed Hi Stefan, Thank you for filing this bug, and thank you for providing the upstream URL for this issue. As this is not an RC issue I expect the resolution will be deferred until bullseye (buster+1/Debian 11). If the problem is strictly in btrfs-progs it is likely that a future buster-backport release will resolve it. Cheers, Nicholas signature.asc Description: PGP signature
Bug#916538: [btrfs-progs] btrfsck segfaults with -E and --subvol-extents
Control: tag -1 + moreinfo Hi Bruno, On Sat, Dec 15, 2018 at 05:45:24PM +0100, Bruno Kleinert wrote: > Package: btrfs-progs > Version: 4.19.1-1 > Severity: normal > > Kernel: Linux 4.18.0-3-amd64 > Please confirm if btrfs-progs/4.20.1-1 on linux/4.19.0-2-amd64 is also affected. Thanks! Nicholas signature.asc Description: PGP signature
Bug#1082447: php-elisp: FTBFS with php8.4_8.4.0~beta4-1: DEPS
Hi, Ola Lundqvist writes: > Hi > > Thank you for the report. To whoever looks at this report and try to solve > it. > An obvious solution is to remove the build dependencies. That will not work > on its own, one must also disable the tests that are executed by it. > > This functionality did not exist when I was maintainer a long time ago, and > strictly speaking it is not necessary for a working build. > Tests are of course useful, but more so before the software is released, > rather than by the package build. Thank you for the email Ola, and thank you for your work maintaining this package. During the years I maintained this package it was almost always sufficient to 's/phpX.Y/phpZ.A/'. The one time it was not sufficient was because php-elisp didn't yet support some new breaking PHP changes, and this was very quickly resolved with upstream. Thus, my experience with this package was that the autopkgtests prevent regressions in Debian. I also remember periodic interactions with upstream, and they were always positive, so it's worth noting that we (as Debian) have a good rapport with this upstream. Regards, Nicholas signature.asc Description: PGP signature
