Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
Nicholas D Steeves writes: > reopen 1068605 > owner 1068605 ! > thanks > > Hi, > > Sorry I didn't ask this sooner, but would you prefer if I call you Deng, > or Xiyue, or something else? Conventions and understanding vary a lot > from place to place, after all. No worries! My first name is Xiyue, but I acknowledge that this is probably difficult to pronounce in non-Asian countries or even outside of China, so feel free to call me Deng, or even my code name "manphiz" :) > > Xiyue Deng writes: > >> Thanks for pointing out #1019031! Totally missed it. I'll opt for >> option 1 obviously. Updated team repo and mentors accordingly. > > You're welcome, and thank you. On a related note, have you read the > definitions for source and binary packages? > > #1019031 was filed against src:web-mode, so was hidden from the > bin:elpa-web-mode view. On the BTS the src:package view will display > bugs that affect each binary package as well as the src:package. §4 of > Policy has the definition, and here is another good resource: > > https://wiki.debian.org/Packaging/SourcePackage > Actually I should have noticed it through the tracker page[1], which has a panel showing all bugs reported against all source and binary packages. >> Also, accordingly to this comment from Tobias[1] it looks like there are >> opinions that prefer to reuse existing RFS bugs instead of filing new >> ones. Do you think it's OK to reopen this one? > > There are also people who maintain the opposite position, but in the > spirit of harmony I've reopened this bug. [edit: Be careful about only > waiting a day and then going ahead and doing something without having > received a reply, because when you "ask" for something, but then don't > actually wait for a reply, it can make you look disingenuous and/or > impatient and/or pushy.] > I acted fast this time as this is a RFS bug so by reopening I'm not overriding any other people's work and it gives me a higher chance to find a potential sponsor faster. But I acknowledge the concern you pointed out and will be cautious in future. (And I get you as a reviewer which is better than I expected and I'd say it "worked" in my favor :P) > Onto the review: > >* New upstream release > > Push the upstream tag to salsa, and find a way to mitigate this issue in > the future. > Thanks for pointing this out, and this is something that confuses me. According to the dgit-maint-merge(7) workflow, one should have a upstream branch tracking upstream git repo directly, so that when you merge a tagged release "git deborig" can directly use upstream tags to create the tarball. On the other hand, if we have salsa CI set up there is no upstream tag on salsa so it probably will fail at "git deborig" stage. Still, if I read the dgit-maint-merge workflow correctly (I could be wrong), it only requires a "upstream/%(version)s" tag when the upstream only releases tarballs or when we want to package a snapshot. So I'm not sure whether we always want to have "upstream/%(version)s" tags. Would like to hear your opinion on this. >* Set upstream metadata fields: Bug-Database, Bug-Submit, > Repository-Browse >* Update standards version to 4.6.2; no changes needed > > Update this, since a new Policy version was recently released. Did you > already work through the upgrade checklist stepwise, starting from > 4.3.0? > Yes, I reviewed the policy upgrading checklist[2] and there should not be any changes required (actually from 4.5.0 when Thomas last worked on it). The same applies to 4.7.0 which I've updated to in [3]. > "debian-devel-announce" is a low traffic list that will keep you > appraised of stuff like this. > Ack, and glad I've already subscribed. Just that I worked on web-mode a bit earlier than the announcement. >* Use https link of homepage in d/control >* Modernize d/watch using special substitute strings to be more >robust > > I'm happy to see this clear, concise, and useful phrasing. If you have > any pending not-yet-uploaded work that doesn't use this, please update > it. If you're interested in a nitpick, the key term is "substitution > strings" and not "[special] substitute strings" (see the manpages for > uscan and deb-substvars as well as codesearch.debian.net). > Ack. Dropping the "special" part in changelog[4]. >* Fix issues in d/copyright > - Clarify license to be GPL-3+ to be consistent with upstream > > This is unclear. Which licence was it before, and whose license are you > talking about? Web-mode is a non-native package and debian/* is > separate from the upstream source. Also, what does it mean to clarify a > license? > It used to be GPL-2, and I'm talking about the upstream license. The upstream updated it to GPL-3 in 2022, which was actually after Thomas last worked on the package. I think maybe I should change the wording to "Update license to GPL-3+ following upstream changes"[5] > -
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
On Wed, Apr 10, 2024 at 03:05:04PM -0500, Andrew Davis wrote: > is that not right? Maybe my lintian version is old, I'm on v2.114, I'll > see if updating that helps. 2.114 is older than stable, and for packages aimed at unstable you need to use tools from unstable. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
On 4/10/24 2:12 PM, Andrey Rakhmatullin wrote: On Wed, Apr 10, 2024 at 12:39:47PM -0500, Andrew Davis wrote: - debian/k3conf.1 has a *roff warning, lintian also catches it. I don't see this warning, W: k3conf: groff-message error: automatically ending diversion 'an*link-text-div' on exit [usr/share/man/man1/k3conf.1.gz:3] Are you running lintian on the binary .changes? I've run it on several of the files, including the binary .changes, # lintian -i -I --show-overrides k3conf_0.3-1_amd64.changes is that not right? Maybe my lintian version is old, I'm on v2.114, I'll see if updating that helps. it just shows "maintainer-manual-page" item. Which I know nothing about You should use lintian-explain-tags(1) to read tag descriptions. That works, thanks for hint. Also just found lintian -i flag, seems that could be a good default now given the help site for the short version is gone. Andrew
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
On Wed, Apr 10, 2024 at 12:39:47PM -0500, Andrew Davis wrote: > > - debian/k3conf.1 has a *roff warning, lintian also catches it. > > > > I don't see this warning, W: k3conf: groff-message error: automatically ending diversion 'an*link-text-div' on exit [usr/share/man/man1/k3conf.1.gz:3] Are you running lintian on the binary .changes? > it just shows "maintainer-manual-page" item. Which I know nothing about You should use lintian-explain-tags(1) to read tag descriptions. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
On 4/5/24 2:13 PM, Andrey Rakhmatullin wrote: I have several suggestions for this: - Can you provide debian/watch? It should be possible. Okay, I'll add a watch file. - debian/k3conf.1 has a *roff warning, lintian also catches it. I don't see this warning, it just shows "maintainer-manual-page" item. Which I know nothing about, the help link it generates points to a site[0] that has down for about 6 months now[1][2].. Andrew [0] https://lintian.debian.org/tags/maintainer-manual-page [1] https://lists.debian.org/debian-devel/2023/11/msg00171.html [2] https://salsa.debian.org/mentors.debian.net-team/debexpo/-/issues/160
Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
reopen 1068605 owner 1068605 ! thanks Hi, Sorry I didn't ask this sooner, but would you prefer if I call you Deng, or Xiyue, or something else? Conventions and understanding vary a lot from place to place, after all. Xiyue Deng writes: > Thanks for pointing out #1019031! Totally missed it. I'll opt for > option 1 obviously. Updated team repo and mentors accordingly. You're welcome, and thank you. On a related note, have you read the definitions for source and binary packages? #1019031 was filed against src:web-mode, so was hidden from the bin:elpa-web-mode view. On the BTS the src:package view will display bugs that affect each binary package as well as the src:package. §4 of Policy has the definition, and here is another good resource: https://wiki.debian.org/Packaging/SourcePackage > Also, accordingly to this comment from Tobias[1] it looks like there are > opinions that prefer to reuse existing RFS bugs instead of filing new > ones. Do you think it's OK to reopen this one? There are also people who maintain the opposite position, but in the spirit of harmony I've reopened this bug. [edit: Be careful about only waiting a day and then going ahead and doing something without having received a reply, because when you "ask" for something, but then don't actually wait for a reply, it can make you look disingenuous and/or impatient and/or pushy.] Onto the review: * New upstream release Push the upstream tag to salsa, and find a way to mitigate this issue in the future. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse * Update standards version to 4.6.2; no changes needed Update this, since a new Policy version was recently released. Did you already work through the upgrade checklist stepwise, starting from 4.3.0? "debian-devel-announce" is a low traffic list that will keep you appraised of stuff like this. * Use https link of homepage in d/control * Modernize d/watch using special substitute strings to be more robust I'm happy to see this clear, concise, and useful phrasing. If you have any pending not-yet-uploaded work that doesn't use this, please update it. If you're interested in a nitpick, the key term is "substitution strings" and not "[special] substitute strings" (see the manpages for uscan and deb-substvars as well as codesearch.debian.net). * Fix issues in d/copyright - Clarify license to be GPL-3+ to be consistent with upstream This is unclear. Which licence was it before, and whose license are you talking about? Web-mode is a non-native package and debian/* is separate from the upstream source. Also, what does it mean to clarify a license? - Update copyright year info for upstream - Add copyright info for debian/* You added a license grant for debian/* where there was previously none with no explanation, notes, nor justification. Are you sure you have the right to do this? Contact debian-legal and ask them for a patch review of your intended changes. - Add Upstream-Contact Thanks for this and for all the other work I didn't comment on. Here are some things you can work on while waiting for a reply from debian-legal: * lintian-explain-tags prefer-uscan-symlink: if you're changing the watch file then this should be addressed * There's also a version qualifier in d/control that can be dropped. * Finally, have you installed and tested your updated package? * Extra/bonus: Which tags from the lintian output are candidates for an override, and why? -N signature.asc Description: PGP signature
Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
Control: reopen -1 Xiyue Deng writes: > Hi Nicholas, > > Nicholas D Steeves writes: > >> Nicholas D Steeves writes: >> >>> This package cannot be uploaded without a human Uploader. See #1019031 >>> and current git history for more info. Either >>> >>> 1. Add yourself to Uploaders >> >> Yes, this requires a changelog entry too, in case that wasn't obvious. >> > > Thanks for pointing out #1019031! Totally missed it. I'll opt for > option 1 obviously. Updated team repo and mentors accordingly. > > Also, accordingly to this comment from Tobias[1] it looks like there are > opinions that prefer to reuse existing RFS bugs instead of filing new > ones. Do you think it's OK to reopen this one? I took the liberty to opt for reopening. Thanks! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1065302: Acknowledgement (RFS: elpa-rust-mode/1.0.5+git20240301.6d86af4-1 -- Major Emacs mode for editing Rust source code)
Control: retitle -1 RFS: elpa-rust-mode/1.0.5+git20240329.b2b18aa-1 -- Major Emacs mode for editing Rust source code Now synced to the latest snapshot that adds support for 29.3. Team repo[1] and mentors[2] are updated accordingly. PTAL. -- Xiyue Deng [1] https://salsa.debian.org/emacsen-team/rust-mode [2] https://mentors.debian.net/package/elpa-rust-mode/
