Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1223420 > unrolled thread

Bug#1089625: RFS: dap-mode/0.8-1 -- DAP UI controls implemented using treemacs

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1089625: RFS: dap-mode/0.8-1 -- DAP UI controls implemented using treemacs Xiyue Deng <manphiz@gmail.com> - 2024-12-10 06:40 +0100
    Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-10 11:30 +0100
      Bug#1089625: dap-mode 0.8-1 upload Xiyue Deng <manphiz@gmail.com> - 2024-12-10 19:50 +0100
        Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-11 03:20 +0100
          Bug#1089625: dap-mode 0.8-1 upload Xiyue Deng <manphiz@gmail.com> - 2024-12-11 07:40 +0100
            Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-12 04:00 +0100
              Bug#1089625: dap-mode 0.8-1 upload Nicholas D Steeves <nsteeves@gmail.com> - 2024-12-12 04:10 +0100
    Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-12 12:10 +0100
    Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-13 12:30 +0100
    Re: Bug#1089625: dap-mode 0.8-1 upload Soren Stoutner <soren@debian.org> - 2024-12-14 21:00 +0100
      Re: Bug#1089625: dap-mode 0.8-1 upload Xiyue Deng <manphiz@gmail.com> - 2024-12-15 10:20 +0100
        Re: Bug#1089625: dap-mode 0.8-1 upload Soren Stoutner <soren@debian.org> - 2024-12-16 22:00 +0100
    Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-15 03:40 +0100
    Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-15 12:00 +0100
      Re: Bug#1089625: dap-mode 0.8-1 upload Soren Stoutner <soren@debian.org> - 2024-12-16 22:20 +0100
        Re: Bug#1089625: dap-mode 0.8-1 upload Xiyue Deng <manphiz@gmail.com> - 2024-12-19 03:50 +0100
    Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-17 03:10 +0100
    Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-18 02:50 +0100
    Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-18 08:40 +0100
    Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-18 13:10 +0100
    Bug#1089625: dap-mode 0.8-1 upload Sean Whitton <spwhitton@spwhitton.name> - 2024-12-19 02:50 +0100

Page 1 of 2  [1] 2  Next page →

#1223420 — Bug#1089625: RFS: dap-mode/0.8-1 -- DAP UI controls implemented using treemacs

[Multipart message — attachments visible in raw view] — view raw

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name     : dap-mode
   Version          : 0.8-1
   Upstream contact : Jen-Chieh Shen <jcs090218@gmail.com>
 * URL              : https://github.com/emacs-lsp/dap-mode
 * License          : GPL-3+
 * Vcs              : https://salsa.debian.org/emacsen-team/dap-mode
   Section          : editors

The source builds the following binary packages:

  elpa-dap-mode - DAP UI controls implemented using treemacs

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/d/dap-mode/dap-mode_0.8-1.dsc

Changes since the last upload:

 dap-mode (0.8-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Remove constraints unnecessary since buster (oldstable):
     + elpa-dap-mode: Drop versioned constraint on emacs (>= 46.0) in
       Recommends.
 .
   [ Xiyue Deng ]
   * New upstream release
   * Revert "remove unneeded stuff from upstream with unclear license"
     - It looks like the reverted files are either covered by the current
       license or derived from external repositories that are under a
       different DFSG-compatible license.
       + See discussion at
         https://lists.debian.org/debian-legal/2024/11/msg00002.html
     - Restored the files to avoid potential future packaging issues.
   * Set upstream metadata fields: Bug-Database, Bug-Submit,
     Repository-Browse.
   * Set upstream metadata fields: Repository.
   * Update Build-Depends list based on source file requirements
   * Update Standards-Version to 4.7.0; no change needed
   * Fix short description not to end with a period in d/control
     - Also update long description to the current upstream text
   * Update Section from lisp to editors
   * Add lintian-overrides for changelog in org-mode
   * Update d/gbp.conf to match current practice
   * Enable elpa autopkgtest in d/control
   * Update Uploaders list (Closes: #1019020)
     - Thomas has become MIA.  Thanks Thomas for working on packaging
       dap-mode!
     - Add myself to Uploaders.
   * Add Upstream-Contact and Source in d/copyright

-- 
Regards,
Xiyue Deng

[toc] | [next] | [standalone]

#1223449 — Bug#1089625: dap-mode 0.8-1 upload

Hello Xiyue,

Thanks for adopting the package.

You've added a wrong-name-for-upstream-changelog override.  What name
does the file get installed as?  The .org extension shouldn't be present
in the filesystem under /usr/share/doc, if that is what it is.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1223500 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hi Sean,

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello Xiyue,
>
> Thanks for adopting the package.
>
> You've added a wrong-name-for-upstream-changelog override.  What name
> does the file get installed as?  The .org extension shouldn't be present
> in the filesystem under /usr/share/doc, if that is what it is.
>

I didn't know of such restriction.  I was looking at the Debian policy
12.3[1] which suggests "Additional documentation included in the package
should be installed under /usr/share/doc/package" so I thought it was OK
to ship org documentation under /usr/share/doc/dap-mode/.  What would be
the recommended practice to ship the org documentation?

> -- 
> Sean Whitton

[1] https://www.debian.org/doc/debian-policy/ch-docs.html#additional-documentation

-- 
Regards,
Xiyue Deng

[toc] | [prev] | [next] | [standalone]

#1223534 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Tue 10 Dec 2024 at 10:45am -08, Xiyue Deng wrote:

> Hi Sean,
>
> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Hello Xiyue,
>>
>> Thanks for adopting the package.
>>
>> You've added a wrong-name-for-upstream-changelog override.  What name
>> does the file get installed as?  The .org extension shouldn't be present
>> in the filesystem under /usr/share/doc, if that is what it is.
>>
>
> I didn't know of such restriction.  I was looking at the Debian policy
> 12.3[1] which suggests "Additional documentation included in the package
> should be installed under /usr/share/doc/package" so I thought it was OK
> to ship org documentation under /usr/share/doc/dap-mode/.  What would be
> the recommended practice to ship the org documentation?

Specifically, README should always be README, just like how
README.Debian should always be README.Debian.  I'm not sure this is a
Policy requirement, just a good idea.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1223547 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Tue 10 Dec 2024 at 10:45am -08, Xiyue Deng wrote:
>
>> Hi Sean,
>>
>> Sean Whitton <spwhitton@spwhitton.name> writes:
>>
>>> Hello Xiyue,
>>>
>>> Thanks for adopting the package.
>>>
>>> You've added a wrong-name-for-upstream-changelog override.  What name
>>> does the file get installed as?  The .org extension shouldn't be present
>>> in the filesystem under /usr/share/doc, if that is what it is.
>>>
>>
>> I didn't know of such restriction.  I was looking at the Debian policy
>> 12.3[1] which suggests "Additional documentation included in the package
>> should be installed under /usr/share/doc/package" so I thought it was OK
>> to ship org documentation under /usr/share/doc/dap-mode/.  What would be
>> the recommended practice to ship the org documentation?
>
> Specifically, README should always be README, just like how
> README.Debian should always be README.Debian.  I'm not sure this is a
> Policy requirement, just a good idea.
>

I see.  I checked Policy 12.7[1] and it does suggest providing an
upstream in plain text format and should be named `changelog', though
as I understand it, the footnote suggests that the purpose is more about
make it easy to be found instead of requiring the format.

Meanwhile, there are packages with README or CHANGELOG in markdown
format, and shipping those are also common practice.  I think org files
can be considered as similar.  As markdown is somehow in between a
human-readable and machine-readable format, the boundary is kind of
blurred, though I would like to think that they are essentially text
format.

That said, even though I would prefer to ship CHANGELOG.org under
/usr/share/doc/dap-mode as-is, I would not insist.  Do you think it is
OK to just skip/not-shipping it? (Or convert it to plain text which
would need other dependencies that would be better to avoid :P)

> -- 
> Sean Whitton

[1] https://www.debian.org/doc/debian-policy/ch-docs.html#changelog-files-and-release-notes

-- 
Regards,
Xiyue Deng

[toc] | [prev] | [next] | [standalone]

#1223679 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Tue 10 Dec 2024 at 10:32pm -08, Xiyue Deng wrote:

> I see.  I checked Policy 12.7[1] and it does suggest providing an
> upstream in plain text format and should be named `changelog', though
> as I understand it, the footnote suggests that the purpose is more about
> make it easy to be found instead of requiring the format.

Yes, exactly.  It's fine to install an Org-mode README.org as just
/usr/share/doc/package/README(.gz).

> Meanwhile, there are packages with README or CHANGELOG in markdown
> format, and shipping those are also common practice.  I think org files
> can be considered as similar.  As markdown is somehow in between a
> human-readable and machine-readable format, the boundary is kind of
> blurred, though I would like to think that they are essentially text
> format.
>
> That said, even though I would prefer to ship CHANGELOG.org under
> /usr/share/doc/dap-mode as-is, I would not insist.  Do you think it is
> OK to just skip/not-shipping it? (Or convert it to plain text which
> would need other dependencies that would be better to avoid :P)

I think you are stuck on file extensions.  They're not that important :)
Just ship it as is, under the name README.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1223680 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

On Wed, 11 Dec 2024, 21:57 Sean Whitton, <spwhitton@spwhitton.name> wrote:

> Hello,
>
> On Tue 10 Dec 2024 at 10:32pm -08, Xiyue Deng wrote:
>
> > That said, even though I would prefer to ship CHANGELOG.org under
> > /usr/share/doc/dap-mode as-is, I would not insist.  Do you think it is
> > OK to just skip/not-shipping it? (Or convert it to plain text which
> > would need other dependencies that would be better to avoid :P)
>
> I think you are stuck on file extensions.  They're not that important :)
> Just ship it as is, under the name README.
>

+1, this isn't Windows 😉.  Also, you can still get Emacs to activate
org-mode for arbitrarily named files, even on Windows.

Sorry for the html copy; I'm on my phone.
Regards,
--N

>

[toc] | [prev] | [next] | [standalone]

#1223710 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Wed 11 Dec 2024 at 10:44pm -08, Xiyue Deng wrote:

> Thank you both for clarifying!  I was trying one last attempt by
> providing changelog as a symlink to the CHANGELOG.org in hope that Emacs
> could recognize the org format through the symlink, but apparently that
> didn't work and it was still opened as plain text.  Not worth the
> trouble.

You can patch in

    # -*- mode: org -*_

as the first line of the file, if you like.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1223842 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hello Xiyue,

Alright, looking at commit 8e06c63:

- Renaming the file from CHANGELOG.org to changelog in a build target
  dirties the tree, and could mean the package will fail to build twice.

  You could rename it back in the clean target, but I think it would be
  more maintainable to install CHANGELOG.org as changelog -- the
  equivalent of doing 'cp ./CHANGELOG.org /usr/share/doc/foo/changelog'.

  I can't remember whether you can make dh_installdocs do this or
  whether you have to do it with dh_install; please take a look.
  Whatever you do, you'll need to ensure you avoid interfering with the
  automatic .gz compression of files under /usr/share/doc.

- d/copyright needs a lot of work.  Given the addition of all the new
  files, this is almost like an ITP.  Please go through it again and
  ensure it accurately reflects the source.
  For example, CODE_OF_CONDUCT.md has its own license and copyright.
  icons/vscode/ might indeed be DFSG-compatible, but why would the
  emacs-lsp maintainers hold copyright?
  Surely it is Microsoft or something?
  I'm afraid you need to track these facts down, or the files have to be
  excluded again.  Please use Comment: fields in d/copyright to explain
  your sources, so it's easier to verify.

By the way, you can combine all the stanza for files under the same
license like this:

Files: dap-edge.el
 dap-node.el
 dap-pwsh.el
 dap-utils.el
 dap-go.el
 dap-launch.el
Copyright: (C) 2019 Kien Nguyen
 (C) 2018 Aya Igarashi
 (C) 2020 Nikita Bloshchanevich
License: GPL-3+

etc.

Be sure you're familiar with the copyright format spec.; there are more
shortcuts allowed than most people seem to realise.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1224016 — Re: Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Xiyue,

On Saturday, December 14, 2024 12:36:43 AM MST Xiyue Deng wrote:
> I took a look at the machine-readable copyright format document[1],
> specifically the example given in the copyright section 6.8, and I
> think it meant that if a group of file shares any copyright holder(s),
> those files can be grouped in the same stanza - in the example, Angela
> Watts appeared in both source files so those files can share the same
> stanza.  I think in the case for dap-mode, each file has only a single
> copyright holder so may be this simplification doesn't apply, so I opt
> to provide separate stanza for all files.  I surely hope I can list
> everyone under "Files: *" so that things can be simpler, but keeping it
> as-is just in case.

Every file in a given stanza must have the exact same license.  But they don’t 
need to have the same copyright information.  Meaning that if file A is 
copyright 2020 Alice and file B is copyright 2021 Bob, they can be grouped as:

Files: fileA
          fileB
Copyright: 2020 Alice
                    2021 Bob
License: Some-License

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field

The reason why it is structured this way is that it easily tells people which 
files they can use under which license.  The purpose of this design is not to 
list the individual copyright of each file (that would make debian/copyright 
enormously large for big projects).  Rather, it says, "You can use all of the 
files in this stanza under this license.  If, for some reason, you need to 
relicense all of these files under a different license, you would need to 
contact all of the copyright holders listed here to get permission to 
relicense.  If you only need to relicense some of the files in this stanza, 
debian/copyright does not provide detailed information about which of the files 
are under each copyright, but you are free to check the individual files to sus 
out that information.”

As an example, check out the following debian/copyright:

https://salsa.debian.org/soren/feather-wallet/-/blob/main/debian/copyright?
ref_type=heads#L29-46

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#1224067 — Re: Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hi Soren

Soren Stoutner <soren@debian.org> writes:

> Xiyue,
>
> On Saturday, December 14, 2024 12:36:43 AM MST Xiyue Deng wrote:
>> I took a look at the machine-readable copyright format document[1],
>> specifically the example given in the copyright section 6.8, and I
>> think it meant that if a group of file shares any copyright holder(s),
>> those files can be grouped in the same stanza - in the example, Angela
>> Watts appeared in both source files so those files can share the same
>> stanza.  I think in the case for dap-mode, each file has only a single
>> copyright holder so may be this simplification doesn't apply, so I opt
>> to provide separate stanza for all files.  I surely hope I can list
>> everyone under "Files: *" so that things can be simpler, but keeping it
>> as-is just in case.
>
> Every file in a given stanza must have the exact same license.  But they don’t 
> need to have the same copyright information.  Meaning that if file A is 
> copyright 2020 Alice and file B is copyright 2021 Bob, they can be grouped as:
>
> Files: fileA
>           fileB
> Copyright: 2020 Alice
>                     2021 Bob
> License: Some-License
>
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field
>
> The reason why it is structured this way is that it easily tells people which 
> files they can use under which license.  The purpose of this design is not to 
> list the individual copyright of each file (that would make debian/copyright 
> enormously large for big projects).  Rather, it says, "You can use all of the 
> files in this stanza under this license.  If, for some reason, you need to 
> relicense all of these files under a different license, you would need to 
> contact all of the copyright holders listed here to get permission to 
> relicense.  If you only need to relicense some of the files in this stanza, 
> debian/copyright does not provide detailed information about which of the files 
> are under each copyright, but you are free to check the individual files to sus 
> out that information.”
>

Thanks for the detailed explanation!  AIUI, as long as the files are
using the same license, their copyright holders can be grouped by one
stanza, regardless of individual file copyright holder differences.  Is
my understanding correct?

> As an example, check out the following debian/copyright:
>
> https://salsa.debian.org/soren/feather-wallet/-/blob/main/debian/copyright?
> ref_type=heads#L29-46
>

I was initially confused by multiple "BSD-3-clause" stanzas, but later
realized that there was another license stanza for the upper directory
(very subtle).

> -- 
> Soren Stoutner
> soren@debian.org

-- 
Regards,
Xiyue Deng

[toc] | [prev] | [next] | [standalone]

#1224350 — Re: Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

On Sunday, December 15, 2024 2:18:53 AM MST Xiyue Deng wrote:
> Thanks for the detailed explanation!  AIUI, as long as the files are
> using the same license, their copyright holders can be grouped by one
> stanza, regardless of individual file copyright holder differences.  Is
> my understanding correct?

Yes, that is correct.
 
> > As an example, check out the following debian/copyright:
> > 
> > https://salsa.debian.org/soren/feather-wallet/-/blob/main/debian/
copyright?
> > ref_type=heads#L29-46
> 
> I was initially confused by multiple "BSD-3-clause" stanzas, but later
> realized that there was another license stanza for the upper directory
> (very subtle).

Feather-wallet has a surprisingly complex debian/copyright file given the small 
size of the codebase.  That is why I choose to link to it, because it covers a 
large number of corner cases, and so is good for explanation purposes.  I can 
tell you that writing it wasn’t exactly my idea of a fun time.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#1224049 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Fri 13 Dec 2024 at 11:36pm -08, Xiyue Deng wrote:

> I also tried d/install, but it cannot rename files.

You could try dh_exec.

> In fact, all Debian control files supporting the "source destination"
> format seem to treat destination as a directory only and are created
> on demand, which I think makes sense.  I think manually using
> install/rename the file in override_dh_installdocs will interfere with
> the automatic handling of dh_* tools anyway and I'd like to avoid
> that.

I don't think it will interfere with anything.  Just

    override_dh_installdocs:
        install ...
        dh_installdocs

should be fine.

> So instead, I opt for one of the previous ideas: install changelog as a
> symlink of CHANGELOG.org in d/links, which should take care of all the
> unnecessary renaming dance.  However, it triggers another lintian
> warning "debian-changelog-file-is-a-symlink", which it should not as the
> document says if the file is under /usr/share/doc/*pkg* it should be
> fine, which CHANGELOG.org is.  Anyway, I added a lintian override for
> that for now and will file a follow up bug to track this false positive
> case on lintian.

I think Lintian is correct, tbh.

> I took a look at the machine-readable copyright format document[1],
> specifically the example given in the copyright section 6.8, and I
> think it meant that if a group of file shares any copyright holder(s),
> those files can be grouped in the same stanza - in the example, Angela
> Watts appeared in both source files so those files can share the same
> stanza.  I think in the case for dap-mode, each file has only a single
> copyright holder so may be this simplification doesn't apply, so I opt
> to provide separate stanza for all files.  I surely hope I can list
> everyone under "Files: *" so that things can be simpler, but keeping it
> as-is just in case.

They can definitely be grouped in the way I suggested.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1224075 — Bug#1089625: dap-mode 0.8-1 upload

Hello,

On Sun 15 Dec 2024 at 01:19am -08, Xiyue Deng wrote:

>> I think Lintian is correct, tbh.
>
> Can you expand a little on this?  The lintian warning text does say:
> ,----
> | (Symlinks to another file in /usr/share/doc/pkg or a subdirectory
> | thereof are fine and should not trigger this warning.)
> `----
> which I believe CHANGELOG.org satisfies.

I should have been more explicit.  I think that Lintian is right that
this file should not be a symlink; I did not mean to comment on whether
or not there is a bug in the check.

When Policy calls for a file to be installed at /a/b/c and upstream ship
that file under the name foo-1.0/d/e.f, we install it directly as
/a/b/c.

Doing anything else would need a good justification -- for example, that
overall the d/rules is simpler.  (Suppose upstream's build system
already installed the changelog under /usr/share/doc, well, then we
might make our changelog file a symlink to it.)

This is not the case here, so far as I can see.

It's important to remember that upstream's context is different to ours.
This is Free Software; we should patch things and move them around as
appropriate to our context.

> As Soren explained in details, I think a single "Files: *" stanza
> should be OK, right?

I haven't read Soren's mail.  If you mean that a single "Files: *" for
all the GPL-3+ licensed files, then yes, that should be fine.

I saw that you reformatted copyright claims to drop the (C) and to add
commas.  Generally licenses require us to reproduce copyright notices
verbatim.  IANAL, but reformatting is probably not justified.

You'll need a copy of the entire EPL-2.0, per Policy 12.5.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1224356 — Re: Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

On Sunday, December 15, 2024 3:55:44 AM MST Sean Whitton wrote:
> I saw that you reformatted copyright claims to drop the (C) and to add
> commas.  Generally licenses require us to reproduce copyright notices
> verbatim.  IANAL, but reformatting is probably not justified.

Generally, both licenses and copyright information must be reproduced 
verbatim.  However, the *definition* of verbatim is different than how some 
people understand the word.  Specifically, verbatim in licensing and copyright 
means the the *information* must not be changed, but the *formatting* may be 
changed.

For example:

1. “years of publication for one copyright holder may be gathered together”

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field

2. Indented periods replace empty lines in licenses in debian/copyright.

Other examples involve switching the formatting of the file, like switching 
between HTML and ASCII, or switching the encoding, like switching between 
UTF-16 and UTF-8 (debian/copyright must be UTF-8).

None of these are verbatim in the sense of a diff comparison, but they are all 
verbatim in the sense of all the original information being preserved.

Similarly, using (C) or commas is a formatting decision, not an aspect of the 
verbatim meaning of the original text.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#1224805 — Re: Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hi Soren,

Soren Stoutner <soren@debian.org> writes:

> On Sunday, December 15, 2024 3:55:44 AM MST Sean Whitton wrote:
>> I saw that you reformatted copyright claims to drop the (C) and to add
>> commas.  Generally licenses require us to reproduce copyright notices
>> verbatim.  IANAL, but reformatting is probably not justified.
>
> Generally, both licenses and copyright information must be reproduced 
> verbatim.  However, the *definition* of verbatim is different than how some 
> people understand the word.  Specifically, verbatim in licensing and copyright 
> means the the *information* must not be changed, but the *formatting* may be 
> changed.
>
> For example:
>
> 1. “years of publication for one copyright holder may be gathered together”
>
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field
>
> 2. Indented periods replace empty lines in licenses in debian/copyright.
>
> Other examples involve switching the formatting of the file, like switching 
> between HTML and ASCII, or switching the encoding, like switching between 
> UTF-16 and UTF-8 (debian/copyright must be UTF-8).
>
> None of these are verbatim in the sense of a diff comparison, but they are all 
> verbatim in the sense of all the original information being preserved.
>
> Similarly, using (C) or commas is a formatting decision, not an aspect of the 
> verbatim meaning of the original text.
>

Thanks for the insightful explanation. I hope I have the confidence to
understand "verbatim" as you explained it, and it would save reviewers'
time on this matter of course.  Still, I would have to admit that as a
non-native speaker I would be a bit hesitant :P

> -- 
> Soren Stoutner
> soren@debian.org

-- 
Regards,
Xiyue Deng

[toc] | [prev] | [next] | [standalone]

#1224397 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Sun 15 Dec 2024 at 10:52pm -08, Xiyue Deng wrote:

> To look at it from complexity point of view, installing CHANGELOG.org as
> changelog requires the following minimum change:
>  1) Not included CHANGELOG.org in d/docs (which now only includes
>  NEWS.org),
>  2) Override dh_installdocs to install CHANGELOG.org as changelog,
> while using a symlink from changelog to CHANGELOG.org requires:
>  1) Include CHANGELOG.org in d/docs,
>  2) Add linking to changelog in d/links,
>  3) Compress CHANGELOG.org by overriding dh_installdocs as it's not
>  compressed by default and it's required for changelog.gz,
>  4) Add a lintian override for that what-I-think-is-a-false-positive
>  tag.
> So the former wins here, and I have implemented it now in Salsa.

Hmm, commit a2c1074 on salsa is otherwise okay but still does the
symlinking, did you forget to push?

> [ On the other hand, I think using CHANGELOG.org is becoming a common
>   practice in many ELPA packages and it should be considered a supported
>   format for changelog.  I'll probably follow-up on this in another bug
>   to see if this would be acceptable, so that step 2-4 of the latter
>   won't be required.  What would be a good place to file such a wishlist
>   bug? ]

Again, file extensions don't matter.
Writing CHANGELOG in Org format is indeed common; there is nothing wrong
with installing it without its file extension.  So, I don't think there
is anywhere that has a bug.

> Ack.  It looks like policy 12.5 does say copyright information should be
> verbatim, however as we can group the copyright holder spanning multiple
> years, it becomes "not-verbatim" then.  Oh well, guess nothing is
> perfect.

Yes, good point.

>> You'll need a copy of the entire EPL-2.0, per Policy 12.5.
>>
>
> Lintian warns about not including CC-BY-SA-4.0 full text but doesn't
> warn about EPL-2.0.  Anyway, I think including the full text is the safe
> bet and this has been done.
>
> PTAL.

Rather than relying on Lintian, just take a look under
/usr/share/common-licenses and see what's there :)

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1224693 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Tue 17 Dec 2024 at 02:08am -08, Xiyue Deng wrote:

> The symlink should have been removed at 927b478, and my local built
> package does not seem to have any symlink to CHANGELOG.org anymore.  Can
> you pull and retry?

Hmm, sorry.

But your install(1) invocation doesn't work, I think?  It doesn't get
installed to the /usr/share/doc.  I think you need to be copying into
debian/tmp/usr/share/doc/dap-mode/.

> IMHO treating Org mode documents as plain text is losing formatting
> information.

But we're not doing that :)  The lack of a file extension does not imply
there is no particular format.

> Similarly for markdown, Org mode files are plain text but not quite,
> as there are formatting information that are used to add more visual
> effect compared to plain text, and preserving them is good.  The
> policy supports NEWS.html and changelog.html.  Why not also treat
> CHANGELOG.{org,md} as a supported changelog format directly?  This
> saves maintainer time as well as preserve formatting information: if
> one installs CHANGELOG.org as changelog and would like to preserve
> formatting information, one may have to patch the file with `-*- mode:
> org -*-' cookie for Emacs, or maybe other treatments for other
> readers/editors, while CHANGELOG.org works OOTB and I doubt upstream
> would accept patches adding the cookies because CHANGELOG.org is
> working fine and changing the file name is the decision made by the
> Debian maintainer.  This puts Debian maintainer in a lose-lose
> position: having to do extra work, and changes may not be accepted
> upstream.

Maybe, but that's an issue to raise on Debian Policy mailing list or
bugtracker, not here.

> I found /usr/share/common-licenses contains a very limited list of
> DFSG-compatible licenses.  Is there any proposal to extend the list so
> that we don't have to include the full text for DFSG-compatible licenses
> anymore?

Yeah, It's been discussed numerous times.  Look in the debian-policy
list archives.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1224705 — Bug#1089625: dap-mode 0.8-1 upload

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Tue 17 Dec 2024 at 06:57pm -08, Xiyue Deng wrote:

> Hi Sean,
>
> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Hello,
>>
>> On Tue 17 Dec 2024 at 02:08am -08, Xiyue Deng wrote:
>>
>>> The symlink should have been removed at 927b478, and my local built
>>> package does not seem to have any symlink to CHANGELOG.org anymore.  Can
>>> you pull and retry?
>>
>> Hmm, sorry.
>>
>> But your install(1) invocation doesn't work, I think?  It doesn't get
>> installed to the /usr/share/doc.  I think you need to be copying into
>> debian/tmp/usr/share/doc/dap-mode/.
>>
>
> Looks like I confused changelog.Debian and changelog.  Should be fixed
> now.

You've added a line 'debian/tmp/usr/share/doc/elpa-dap-mode/changelog'
to debian/docs.  That doesn't make any sense.

When building a Debian package where the source builds a single Debian
package, debian/tmp/ is like the root of the target filesystem.  That's
why I suggested you copy the file into there.

(It would be worth spending time building a dummy package without
debhelper to understand more about what's going on.)

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1224730 — Bug#1089625: dap-mode 0.8-1 upload

Hello,

On Wed 18 Dec 2024 at 12:07am -08, Xiyue Deng wrote:

> AIUI technically both work: in install files like
> d/{docs,install,links}, etc., the file path starts from source
> directory, and dh_install will fallback to search under debian/tmp if
> the file is not found under source directory[1].

Sure, but installing from debian/tmp/usr/share/doc/ with dh_installdocs
could never make sense.  The line you've added is effectively a no-op.

Given that you are installing the file in d/rules already, the line in
d/docs should be removed.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web