• Help needed with splitting elpa-modus-themes

    From Dhavan V@21:1/5 to All on Fri Sep 17 07:30:01 2021
    Hello!

    Debian Stable has shipped with v1.0.2 of modus-themes, which had no
    licensing conflicts with Debian.

    Since then, upstream has been included in emacs28 requiring docs license
    to change to GFDL, which is incompatible with Debian because of GFDL
    Invariant sections[1].

    Because of this, we need to either “split” the package or not ship the
    docs at all. I would like to “split” the package into free and non-free parts. However, I do not know if “splitting” is the right terminology
    here, and would like to have some help in finding documentation /
    guidance as to how I should be doing this.


    [1]: https://wiki.debian.org/qa.debian.org/gfdlinvariant


    --
    Dhavan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicholas D Steeves@21:1/5 to Dhavan V on Sun Sep 19 19:20:03 2021
    Hi Dhavan,

    Unfortunately the non-dfsg files have already been merged and pushed, so
    a team member with group-level admin access will need to do a hard reset
    of the pristine-tar, upstream, and master branches, and you'll need to
    do the same on your local copy, and reimport using 'gbp import-orig
    --uscan'. Imho this is the fastest, easiest, and most maintainable way forward. To not lose your commits, you can do something like:

    git checkout master (before the reset)
    git branch master-non-free-backup
    git reset --hard pre-upstream-import-commit

    and then either run 'git cherry-pick commit' for each commit that you
    need, or use magit to apply a series of commits in one go :-)

    Reply follows inline:

    Dhavan V <quark@codingquark.com> writes:

    Hello!

    Debian Stable has shipped with v1.0.2 of modus-themes, which had no
    licensing conflicts with Debian.

    Since then, upstream has been included in emacs28 requiring docs license
    to change to GFDL, which is incompatible with Debian because of GFDL Invariant sections[1].

    Because of this, we need to either “split” the package or not ship the docs at all. I would like to “split” the package into free and non-free parts. However, I do not know if “splitting” is the right terminology here, and would like to have some help in finding documentation /
    guidance as to how I should be doing this.


    Sorry for the delay replying to this email, I rebooted for a kernel
    upgrade and lost the WIP draft that replied to this email.

    On IRC I just mentioned how gbp import-orig --uscan leverages
    Files-Excluded (d/copyright); this method prevents the non-dfsg files
    from being merged to the salsa repo. Currently documentation of
    Files-Excluded only exists in uscan's man page, and the documentation is incomplete.

    The non-dfsg source shouldn't be maintained on Debian infrastructure.
    Yes, you're using the correct terminology, assuming the future src:modus-themes-non-dfsg-docs exclusively contains what was excluded
    from src:modus-themes. There are lots of options on how to maintain
    this second source package. One can use a d/rules Makefile-style target
    to automate the exclusion of the source that is present in
    src:modus-themes, or a custom script. Basically the solution is "tar
    cJf modus-themes-non-dfsg-docs_$version.tar.xz docs", plus a mechanism to
    get the correct $version from either the upstream tag or the current
    changelog entry.

    'hope this helps!
    Nicholas

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJHBAEBCgAxFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmFHb8MTHG5zdGVldmVz QGdtYWlsLmNvbQAKCRBaiDBHX30QYW38D/9ofCLOwN/VPEizIMxO25Qmwm96UwiD jNSM4cZrNoeCz72KSLTjftmx3gj0qyr2RDxAiwo+CFRsa79Vt1JfjAd0d2N96egl rwr8Tdng/mjKN5DUqQ+ySK8hf9wWhNNueFFfP8DMN8NLtAPQMevafuCDDVJvoLgE fCwn6VsZqjEO1jVWlsmDIGi0Rp0wirv4dODjfbVRcET0R8qWg5wEaPHHZMch19v+ Olax57XJcAqg75rh/KLN05fM/6GRwywpsbUk6lMOvAu+yfahed7Xvx67jMp+72Xj CSJ0aFL4nBjiBVRWO1G+QGD2djFcefUAuToFyHTXUj384Rdm4QceYaFuLvHZPRUz Fm0w3r1Tn1wKpZsoetFN0p9z0rZzUnP4+PGkm57uo8BP00a8lkjvjEu1WOx+b5CD 0sr8Ds3+OWY0M5mqrzvscfe+fOYi75UsMIuh+3GnUj4weHzlCujHyESi7zWI2NkL bc1RyhQprD01lRuyLkRtPnk77ePBVGE73BYuXTz3pzqwMOAYsHfIjgL5AZvie1Kt QfNHn27og3aCyFVIO+s2VS6hklTI+eSDK4AYais9LwxoIlG/1zdq8PsUTyj+p/nG J+3Fdb31/9KdkfynlHag5oq1jueWNZX+W0EjrsNBv5tW8J4rdo+Rqf1unRW9rdHg +W8pNbKqDbYAKQ==q2Cb
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicholas D Steeves@21:1/5 to All on Sun Sep 19 19:30:02 2021
    P.S. I was assuming a tarball-based workflow for the docs package. If
    you'd prefer to create modus-themes-non-dfsg-docs tags then gbp can
    leverage those in a local-only src:modus-theme-non-dfsg-docs package.
    'git deborig' can also be used to create the docs package's tarball from
    the debian packaging branch of src:modus-theme-non-dfsg-docs so long as
    you've merged the tag you created.

    It's also worth evaluating whether one feels the documentation is useful
    enough to justify the time/effort of maintaining a non-free package, or
    whether the work will demotivate you. When I initially packaged
    src:emacs-ivy, I chose--with the support of our team--to not ship the
    non-free package. There is no obligation to ship the docs, and no shame
    in not doing so :-)

    Take care,
    Nicholas

    -----BEGIN PGP SIGNATURE-----

    iQJHBAEBCgAxFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmFHcXsTHG5zdGVldmVz QGdtYWlsLmNvbQAKCRBaiDBHX30QYR4bD/0TPVjxeyO2WOMP5a75chDqiKq5tyTW f2v7jLf3Yc4YozYwjL99Q6QLoXSVvjJGt9aj25sjiordkX3aDU6vYr1Q3t/HnNYw NUxu8kkyMpKO/aP5C9VIJa1nHflnBOYLqGPaNoWKPtrKHAsXIxYUF/+FAZqmscb4 nQ+RAD0eDlvZyaNCjSzbphtA2kh1s9/v4g/QoqUmd0/VjfW65BN0ziYaOdbUm3BW IxYeTyeCqTdJIVNay0hfTC+yuZC9EGMrwDgo6X3iYWL8x07E7OplC+edEdf7TvTE yezY1+qCYHvEpbdtzYeronyIiPqTWBmuxvxzGrWB1BwDokLpOwMKeeURj/S0N3t2 QJXdMGNncnMbacCrtLiNV+n73ELO8RYrVPBi2yt1lPud6YIu8p4YFZ3UhtEWXDMJ YUWGj2SRW7niFbXAJK72zO5HOHrjiaW7Syug+yIaFEBucoDq8B0a7UpJFYdlgNXn taTiSzslHOMdMBryDOer0p2VuNSg+9uUjYJ0rXxbDIgn5x7FsScwWNjEFWsQigzk vBsvghQuVNamQjOmMFk5nmivwmnSEcOtspJ6NyHB0KN0x8cZonIqVZy9JcTpPvNG 5w2Hr6BrHE17Qx7Z3pjYhFuVecY22KikdhfgKeG7MMvfQJCayitbyDLR+ARoN07+ tLpwbcpDhX4/Gw==
    =cuxz
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sean Whitton@21:1/5 to Nicholas D Steeves on Mon Sep 20 01:00:02 2021
    Hello,

    On Sun 19 Sep 2021 at 06:51PM -04, Nicholas D Steeves wrote:

    Are you sure, and if so, when was this policy changed?

    There wasn't any change. It's never been the way you say, so far as I
    know.

    At DC17 (yes, we were still on alioth IIRC) the team was rather
    explicit in its warning to me to *not* put GDFL with invariant section
    and/or cover page on Debian infrastructure. That package was
    src:emacs-ivy. You were one of the people who insisted...

    Well, either I was wrong, or we were talking about something else -- I'm
    afraid I can't recall :)

    --
    Sean Whitton

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmFHwHcZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQA4SD/9VN+RvUsWTVaPiTM3Z5f3L dxSxN2ZrEYPOS67fJjwl1BxKOB0kV9vyWJZXuKib3wUXlwMx9hMYIwhjsIsXg2kk LrG9mtGNQT2amFo1NQM24OfM16kMM7unVjWZktWa7dPZFeFzU0SvlvcBimqFdWZ4 EEXTQHxnCkJ/M6K0CJD8uHBtzgpIGuwwMTzrPEtPeEGgrvj+WYL0Bs/ydGycMSbv Bd35tIAq2BjagLsSzP+mWp1/SqsCMxAOkxVdH7UqXyHJrQRToP5KQre4lgj80Lu9 g+mLciHYp2TeOyhwbo+iZnrq5+5KRjEac1trCo+LrFL3+mzI0Fel1frHHYzP397f ++PCtY8Hy7tTeTcBk/rmY9lRN+HydD8SUwqiHROWF1LcKAWw6KoCocCebaJsmxx4 KNorpkubYrFhPh3OKVgeur2OsTp8++WWpCKGZgZbJHzbQMj59HH4xeuxz61eyl17 YW0PW1AtZWEcvXkVyFhsL0y1nyWFPi4Hrxc+misKqbZrTshTqD60XlmUewCcGg3k hayjjx4HTtLS93AIYh3TtNz4PdgX2yCgyJLtsC/sru3SoDFStNSX5cEiwBF6KGA/ 7yYNfUSj4Lh2ajfH60tEv0xJkyYgeK5PC9rQsab/Mjk2YqPVNBK6zK0HNbmP17hu Y5G/8O/KM1KIMqbNL/72dQ==uwEY
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From Sean Whitton@21:1/5 to Nicholas D Steeves on Mon Sep 20 00:40:01 2021
    Hello,

    On Sun 19 Sep 2021 at 01:13PM -04, Nicholas D Steeves wrote:

    Hi Dhavan,

    Unfortunately the non-dfsg files have already been merged and pushed, so
    a team member with group-level admin access will need to do a hard reset
    of the pristine-tar, upstream, and master branches, and you'll need to
    do the same on your local copy, and reimport using 'gbp import-orig
    --uscan'.

    This is not the case. The history on salsa need not be rewritten for
    DFSG reasons.

    The non-dfsg source shouldn't be maintained on Debian infrastructure.

    Again, this is not so. It is no problem to maintain it on salsa.

    --
    Sean Whitton

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmFHuxUZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQOj3D/9KW8CBBNydbdlCbtTksjzx dL/Gg5ZmyyC1DnrbAA5nYxZKB6eLPpmCHzvNGv3Tv5aRjGEPw/oyZ/FjKnpkv74j X8UThm531JZf7apbEdFtuNNWlPYF/hSBx/i8e3J9XYfP/20cWiOGxbaIcE7EKtRS Yzsa0gNYdiILi0xb6OXRbxva4m4ysg/Rbsyj0Va/89t7n6Fqs/0vHeoa/EeFojg5 oEF6Ux2OHrxVGCQOGviQmTY8lgptQJ4WEujcq1Q8J7mNq2Shc+QuoNInhmjrjR0e tXc7nrTm6yOVz5QSQ8YjfNM4V14Yg6s7J+sE6YQAu9HrAVT5BYLc20EyGMFF8n5x xBV4XbFHrGnR3qSSs9ioqKDFHe391s6/3EwEHVTqMZRVew5sQ+QpZz7kLwsdSiBy GAzT+wLz0gPs9rBLwwEeVIALhRvGXb0AzPl3kqekC26/pCIc91irB30aW2G5mdTz ng2odvNS3RcpeUeJ5dFKB3+YRDl5Eizz1zbWU1HndRpgb0raBft52yezPApoIoul ekCXN/a1tCB/uKoAvMuNF8DCny71Qn7OoKc+OBCxPKxvyMHmpCRJJOPMyJdo+DXF dAcSa3Ktv+MSyh+aojbtC2QSlqG8gedCHIh1G3bMl8/+0ltcbLdqMy+gJ9UXaQDE bI5SLAIxxmofwjwruUnPnA==5zIs
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us