Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs

2024-04-19 Thread Xiyue Deng
Sean Whitton  writes:

> Hello,
>
> On Thu 18 Apr 2024 at 06:24pm -07, Xiyue Deng wrote:
>
>> Sean Whitton  writes:
>>
>>> control: tag -1 + moreinfo
>>>
>>> Hello Xiyue,
>>>
>>> Please explain the autopkgtest_keep change.  Remember that autopkgtests
>>> are to test the installed package.  If you need to keep the .el files,
>>> it must be for some reason other than because the test suite actually
>>> just tests those.
>>>
>>
>> I think this is another example of buttercup tests that requires source
>> .el files to run.  I'll probably open a bug on buttercup to see whether
>> this is required for buttercup.  Meanwhile I think it'd probably be
>> better to just disable autopkgtest as the tests are already run as part
>> of the build process.
>
> I agree.  It is important not to use autopkgtest_keep without being sure
> it's the right answer.
>

So it turns out using "disable" in d/elpa-test also disable dh_elpa_test
in d/rules so that the test is not run as part of the package building,
which would be suboptimal in that we don't run any test at all.  I'll
try to see a way to disable it only in autopkgtest in dh-elpa.

On the other hand, it looks like I misjudged the situation of the
buttercup tests that with "autopkgtest_keep = test/*" it just works,
which is much better than disabling.

>>> You've removed the Built-Using with the justification that it's an
>>> arch:all package, but that doesn't make sense; Built-Using is for
>>> licensing reasons, and may well be applicable to an arch:all package (I
>>> think this came up before with one of your uploads?).
>>
>> Ah I was following the suggestions of Lintian which said it cannot be
>> used by arch:all packages which is probably wrong.
>
> See #999785.
>

Ack.  I also checked that bug before and wondering why that lintian tag
is still enabled.  Hopefully Bug#1069256 will move things forward.

>> On the other hand, on a closer look at the policy regarding
>> Built-Using on section 7.8[1], it has the following passage:
>>
>> ,
>> | This field should be used only when there are license or DFSG
>> | requirements to retain the referenced source packages. It should not be
>> | added solely as a way to locate packages that need to be rebuilt against
>> | newer versions of their build dependencies.
>> `
>>
>> I checked that lua-mode is of GPL-2+[2], and of all its dependencies
>> lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL
>> 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using
>> requirement.  The change was introduced in [3] but it was part of the
>> modernization effort so there is no direct justification of adding the
>> field.  May be I'm missing something here?
>
> It sounds like it shouldn't have been introduced.  So you can remove it
> based on your reading of Policy, and briefly note your reasoning in
> d/changelog.

Updated d/changelog accordingly.

Also took this opportunity to add myself to uploaders.  That way we
don't have to deal with the "team upload" complications for sponsors.

Mentors and team repo are both updated.  PTAL.  Thanks!

-- 
Xiyue Deng


signature.asc
Description: PGP signature


Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs

2024-04-19 Thread Sean Whitton
Hello,

On Thu 18 Apr 2024 at 06:24pm -07, Xiyue Deng wrote:

> Sean Whitton  writes:
>
>> control: tag -1 + moreinfo
>>
>> Hello Xiyue,
>>
>> Please explain the autopkgtest_keep change.  Remember that autopkgtests
>> are to test the installed package.  If you need to keep the .el files,
>> it must be for some reason other than because the test suite actually
>> just tests those.
>>
>
> I think this is another example of buttercup tests that requires source
> .el files to run.  I'll probably open a bug on buttercup to see whether
> this is required for buttercup.  Meanwhile I think it'd probably be
> better to just disable autopkgtest as the tests are already run as part
> of the build process.

I agree.  It is important not to use autopkgtest_keep without being sure
it's the right answer.

>> You've removed the Built-Using with the justification that it's an
>> arch:all package, but that doesn't make sense; Built-Using is for
>> licensing reasons, and may well be applicable to an arch:all package (I
>> think this came up before with one of your uploads?).
>
> Ah I was following the suggestions of Lintian which said it cannot be
> used by arch:all packages which is probably wrong.

See #999785.

> On the other hand, on a closer look at the policy regarding
> Built-Using on section 7.8[1], it has the following passage:
>
> ,
> | This field should be used only when there are license or DFSG
> | requirements to retain the referenced source packages. It should not be
> | added solely as a way to locate packages that need to be rebuilt against
> | newer versions of their build dependencies.
> `
>
> I checked that lua-mode is of GPL-2+[2], and of all its dependencies
> lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL
> 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using
> requirement.  The change was introduced in [3] but it was part of the
> modernization effort so there is no direct justification of adding the
> field.  May be I'm missing something here?

It sounds like it shouldn't have been introduced.  So you can remove it
based on your reading of Policy, and briefly note your reasoning in
d/changelog.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs

2024-04-18 Thread Xiyue Deng
Sean Whitton  writes:

> control: tag -1 + moreinfo
>
> Hello Xiyue,
>
> Please explain the autopkgtest_keep change.  Remember that autopkgtests
> are to test the installed package.  If you need to keep the .el files,
> it must be for some reason other than because the test suite actually
> just tests those.
>

I think this is another example of buttercup tests that requires source
.el files to run.  I'll probably open a bug on buttercup to see whether
this is required for buttercup.  Meanwhile I think it'd probably be
better to just disable autopkgtest as the tests are already run as part
of the build process.

> You've removed the Built-Using with the justification that it's an
> arch:all package, but that doesn't make sense; Built-Using is for
> licensing reasons, and may well be applicable to an arch:all package (I
> think this came up before with one of your uploads?).

Ah I was following the suggestions of Lintian which said it cannot be
used by arch:all packages which is probably wrong.  On the other hand,
on a closer look at the policy regarding Built-Using on section 7.8[1], it
has the following passage:

,
| This field should be used only when there are license or DFSG
| requirements to retain the referenced source packages. It should not be
| added solely as a way to locate packages that need to be rebuilt against
| newer versions of their build dependencies.
`

I checked that lua-mode is of GPL-2+[2], and of all its dependencies
lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL
2+ or 3+, so I don't see a license or DFSG need to add this Built-Using
requirement.  The change was introduced in [3] but it was part of the
modernization effort so there is no direct justification of adding the
field.  May be I'm missing something here?

-- 
Xiyue Deng

[1] 
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
[2] Upstream switched to GPL-3+ in 2022 but we haven't packaged that yet.
[3] 
https://salsa.debian.org/emacsen-team/lua-mode/-/commit/2e207a6835a3899f6eba0675c4763c1757335bcc


signature.asc
Description: PGP signature


Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs

2024-04-15 Thread Xiyue Deng
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "lua-mode":

 * Package name : lua-mode
   Version  : 20210802-4
   Upstream contact : immerrr 
 * URL  : https://github.com/immerrr/lua-mode
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/emacsen-team/lua-mode
   Section  : lisp

The source builds the following binary packages:

  elpa-lua-mode - Emacs major-mode for editing Lua programs

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/lua-mode/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-mode/lua-mode_20210802-4.dsc

Changes since the last upload:

 lua-mode (20210802-4) unstable; urgency=medium
 .
   * Team upload
   * Mark lexical binding patch as Forwarded and Applied-Upstream
   * Add patch to use eval in lexical scope to fix tests (Closes: #1069073)
   * Keep source *.el in autopkgtest to make it work
   * Add Upstream-Contact in d/copyright
   * Update homepage to github page in d/control (old link no longer works)
   * Set Rules-Requires-Root to no in d/control
   * Drop Built-Using from arch:all package in d/control
   * Trim trailing whitespace in d/changelog
   * Bump debhelper from old 10 to 13
   * Set debhelper-compat version in Build-Depends
   * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
 Repository-Browse
   * Update Standards-Version to 4.7.0; no change needed
   * Modernize d/watch with substitute strings to be more robust

Regards,
-- 
Xiyue Deng