1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Adding epoch to kworkflow package to correct a wrong upstream version

    From Rodrigo Siqueira@21:1/5 to All on Sun Mar 12 02:40:01 2023
    Hi,

    While working on a new version of the kworkflow package (https://tracker.debian.org/pkg/kworkflow), we noticed that the current
    version is 20191112-1.2, and the latest upstream version is 0.6.2.
    Version 20191112-1.2 was created because the upstream had no official
    release at that time; for this reason, the 20191112-1.2 was created and
    named based on a date.

    This package did not get any update in a long time, and now the upstream release frequent versions. The latest version is 0.6.2 (https://github.com/kworkflow/kworkflow/tags), and I'm trying to release
    a new version of this package (https://salsa.debian.org/siqueira/kworkflow/-/tree/master/debian). So,
    to do a clean update, we should add 1:0.6.2-1 as an epoch to fix the
    problem generated by the first version of this package.

    Is that ok?

    Thanks
    --
    Rodrigo Siqueira
    https://siqueira.tech

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

    iQGzBAABCAAdFiEEStbuwDr3IktKEet28VVYdyLWkBAFAmQNLE4ACgkQ8VVYdyLW kBA7yQv/V5bo0OtHlp32NKwzYCWxlaozKE7moYdyp99LlQvbEa0LENNAEzaYSbgK YjrZPzjTQqQOFJfHYVV3hQo+QX2PkAbB3jm72xC08qh/8GlrAnTY3SWQSzwRfpbZ i6Cd7PT9/okjR8GHEhWCEwltDcmtGkDhJcR1I/I/q70OOY95SXwPj+2z/KLahiR8 +4kG+A58z6cYZ7jBcThTETWW9cEsz0+Pl918leOM4Fb9yy6rAlooqiEZXTHdlYwr ND33DnnWLMv25IH2rn0yyy7fqJi1cg99RXaw+UoMP3O6p6uzIuG5m1w1w0pZxXle QSLgnoEeq8hfGdChLhDQ4iQcnt/6XRIWvt3knPqLbUx+1BSs3WMVwEL9DmgePB/f LOCuacmSWGhoj/5ge8gPQjUxpXzEP1cpIibQ3rsl2AM9l6s0s52q9Np1LFJoqL8y TMnUDByEED1yhsz3ZiMo4Ioj2kHfZgAfz1rLZyn3tbaKLVm4GQaVKQPjXhmbiLLG
    QGiwF55H
    =EevZ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tobias Frost@21:1/5 to Rodrigo Siqueira on Sun Mar 12 09:20:02 2023
    On Sat, Mar 11, 2023 at 06:35:39PM -0700, Rodrigo Siqueira wrote:
    Hi,

    While working on a new version of the kworkflow package (https://tracker.debian.org/pkg/kworkflow), we noticed that the current version is 20191112-1.2, and the latest upstream version is 0.6.2.
    Version 20191112-1.2 was created because the upstream had no official
    release at that time; for this reason, the 20191112-1.2 was created and
    named based on a date.

    This package did not get any update in a long time, and now the upstream release frequent versions. The latest version is 0.6.2 (https://github.com/kworkflow/kworkflow/tags), and I'm trying to release
    a new version of this package (https://salsa.debian.org/siqueira/kworkflow/-/tree/master/debian). So,
    to do a clean update, we should add 1:0.6.2-1 as an epoch to fix the
    problem generated by the first version of this package.

    Is that ok?

    I've got recently a very similiar situtation with gnome-shell-extension-autohidetopbar, as there it was considered ok to use an epoch. [1]


    [1] https://lists.debian.org/debian-devel/2022/03/msg00424.html

    --
    tobi


    Thanks
    --
    Rodrigo Siqueira
    https://siqueira.tech



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

    iQIzBAABCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAmQNihgACgkQkWT6HRe9 XTYREBAA3M2UBla82+BsQXoObSbWS8BUWdwZnzoO2e73eYILMisjdOkJiTRHqL1T P7qApoIuTjrKV20AvDsV3BZ7752gMfNRxGAKn20t7pNCmt430i8rw/P7PrOkM7Nx 7sKw3WKJa2ThPjtAyY6F6tKDe6Sc/fQ6AdM0FLOAb1wT+ZV7oRCVANUiS4T2+Wu8 cdhgRSRCRwX1QlBHdN4biTk4mhB29NCyQn3WoZN0dhPMbxtYnfMap/oJOigvJUaS L5ugcjNRuHc+n2Xq1HVT1n2TRy86WEk8Y3J4b1XZTjVymc7g+a3q8rqUuO/v9Xeh Kfc+SwWZ6wFSCTCUGbNV7dbr3guDWrm7c+/DHXec7IBBQKsZJGzDGxvjO8k3iesJ 0BUhHIKbdPeH16ZFIYGm5Bbec9aBioXL8IW0tueohoEQgxyoG7jhpFTJCcxs8m5f WcShSNv6eUBd0AropX2au/VRJSHPlzAtc910DBF21Ic4HSNKmb79lzAWUlYO+UTW Y2EM7zmVsFl4VQcbhcCwUnDlXsbWs0aXxJXbDj/xZGIZuMDK7cUzzwelCY0wAD7E cO0qQpK1F/2zIDuCpkfEfjDazA7qoI2LR2bMTi9o0cPoRfI9IQPHhj8FY/6n/Qqd jeKuc/d3grTrbsg6bUlLIbGm/zO9Q/J5shl9L6/n/6npvhgA0ZM=
    =gZFW
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to Tobias Frost on Sun Mar 12 16:00:01 2023
    On Sun, 12 Mar 2023 at 09:15:35 +0100, Tobias Frost wrote:
    On Sat, Mar 11, 2023 at 06:35:39PM -0700, Rodrigo Siqueira wrote:
    While working on a new version of the kworkflow package (https://tracker.debian.org/pkg/kworkflow), we noticed that the current version is 20191112-1.2, and the latest upstream version is 0.6.2.

    I've got recently a very similiar situtation with gnome-shell-extension-autohidetopbar, as there it was considered ok to use an epoch.

    Yes, this sort of situation is what epochs are for.

    Version 20191112-1.2 was created because the upstream had no official release at that time; for this reason, the 20191112-1.2 was created and named based on a date.

    In future, please use a lower version number when packaging unreleased software. A version starting with an 8-digit date is almost guaranteed
    to compare greater than whatever upstream eventually chooses, and
    therefore require the use of an epoch.

    I generally represent date-only versions (like src:darkplaces) or
    snapshots of software with no releases (like src:openjk) as 0~YYYYMMDD, sometimes adding a suffix with the truncated git sha1 (for example see darkplaces_0~20180908~beta1-5 and openjk_0~20230306.ab77102+dfsg-1).
    That means if upstream decide to go from datestamped snapshots to any reasonable "semantic" version number (even 0.0.1), I won't need an epoch.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?ISO-8859-1?Q?IOhannes_m_zm=F6lnig@21:1/5 to All on Sun Mar 12 19:10:01 2023
    Am 12. März 2023 15:58:00 MEZ schrieb Simon McVittie <smcv@debian.org>:
    On Sun, 12 Mar 2023 at 09:15:35 +0100, Tobias Frost wrote:

    Version 20191112-1.2 was created because the upstream had no official
    release at that time; for this reason, the 20191112-1.2 was created and
    named based on a date.

    In future, please use a lower version number when packaging unreleased >software. A version starting with an 8-digit date is almost guaranteed
    to compare greater than whatever upstream eventually chooses,


    Could lintian warn when a date based version is used?
    (I haven't checked how many upstreams use date-based versions intentionally and fully aware of the consequences, but I think the problem appears mostly if upstream does not do any formal releases at all, so the package maintainer concocts some arbitrary
    version number on their own)


    mfh.her.fsr
    IOhannes

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Wienemann@21:1/5 to All on Sun Mar 12 19:20:02 2023
    Dear IOhannes,

    On 12.03.23 18:48, IOhannes m zmölnig wrote:
    Could lintian warn when a date based version is used?

    Lintian already does this - see [0].

    Best regards,

    Peter

    [0] https://salsa.debian.org/lintian/lintian/-/blob/f03fc15a45df4965e374b1e3a40c51cf6fe545ed/tags/n/new-package-uses-date-based-version-number.tag

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alexandre Detiste@21:1/5 to All on Sun Mar 12 19:20:02 2023
    Lintian already does some special handling for the initial release
    (like checking the closure of an ITP bug), this check could happen there.

    Greets

    Le dim. 12 mars 2023 à 19:06, IOhannes m zmölnig <umlaeute@debian.org> a écrit :
    In future, please use a lower version number when packaging unreleased >software. A version starting with an 8-digit date is almost guaranteed
    to compare greater than whatever upstream eventually chooses,


    Could lintian warn when a date based version is used?
    (I haven't checked how many upstreams use date-based versions intentionally and fully aware of the consequences, but I think the problem appears mostly if upstream does not do any formal releases at all, so the package maintainer concocts some
    arbitrary version number on their own)


    mfh.her.fsr
    IOhannes


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?ISO-8859-1?Q?IOhannes_m_zm=F6lnig@21:1/5 to All on Sun Mar 12 22:20:01 2023
    Am 12. März 2023 19:13:46 MEZ schrieb Peter Wienemann <fossdev@posteo.de>: >Dear IOhannes,

    On 12.03.23 18:48, IOhannes m zmölnig wrote:
    Could lintian warn when a date based version is used?

    Lintian already does this - see [0].


    Ah. Thx.

    Praise to the lintian maintainers then, and sorry for not doing all the background research myself (but I'm currently afk)


    mfh.her.fsr
    IOhannes

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gioele Barabucci@21:1/5 to Peter Wienemann on Mon Mar 13 07:40:01 2023
    On 12/03/23 19:13, Peter Wienemann wrote:
    On 12.03.23 18:48, IOhannes m zmölnig wrote:
    Could lintian warn when a date based version is used?

    Lintian already does this - see [0].

    [0] https://salsa.debian.org/lintian/lintian/-/blob/f03fc15a45df4965e374b1e3a40c51cf6fe545ed/tags/n/new-package-uses-date-based-version-number.tag


    Given than epochs are kind of a big deal, maybe that warning could be
    raised to the level of error (or added to ftp-master's autoreject tags),
    so that a package will be accepted only if that tag is explicitly
    overridden.

    Regards,

    --
    Gioele Barabucci

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rodrigo Siqueira@21:1/5 to Tobias Frost on Sat Mar 18 18:30:01 2023
    On 03/12, Tobias Frost wrote:
    On Sat, Mar 11, 2023 at 06:35:39PM -0700, Rodrigo Siqueira wrote:
    Hi,

    While working on a new version of the kworkflow package (https://tracker.debian.org/pkg/kworkflow), we noticed that the current version is 20191112-1.2, and the latest upstream version is 0.6.2.
    Version 20191112-1.2 was created because the upstream had no official release at that time; for this reason, the 20191112-1.2 was created and named based on a date.

    This package did not get any update in a long time, and now the upstream release frequent versions. The latest version is 0.6.2 (https://github.com/kworkflow/kworkflow/tags), and I'm trying to release
    a new version of this package (https://salsa.debian.org/siqueira/kworkflow/-/tree/master/debian). So,
    to do a clean update, we should add 1:0.6.2-1 as an epoch to fix the problem generated by the first version of this package.

    Is that ok?

    I've got recently a very similiar situtation with gnome-shell-extension-autohidetopbar, as there it was considered ok to use an epoch. [1]

    Thanks all for the help with this topic.


    [1] https://lists.debian.org/debian-devel/2022/03/msg00424.html

    --
    tobi


    Thanks
    --
    Rodrigo Siqueira
    https://siqueira.tech





    --
    Rodrigo Siqueira
    https://siqueira.tech

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

    iQGzBAABCAAdFiEEStbuwDr3IktKEet28VVYdyLWkBAFAmQV818ACgkQ8VVYdyLW kBBSewwAuBYJ8QV+WqtFNE2x6R0OC0hWaACJwRXqndefMhz6623ZrA9Brc3rAsUD paAyc2AuIlWxZVEMe3+bfy7/U9l94SM7S/nN83NO71XnTQd0KitYvtpJGMoSJXJf X8QFWJCRBacVGebJlCODAHBivmcfzWS4DVa/Hp5ArUpHzxHq+grklxhnxHFRv35Z o8mZCyR9iUxaRBQbtfDntzSw8MTI6YVtlVOwUMkON8iQpjKbaWYU/KirwBNAnFQV NPiuqPTkCTfpQL3mUexX4ASMtPnL9ZJqTmTXW9VNcEVpGAS2LBetWpYfDr+zFD9U cxnrq5kQ+QOevNwvjTnhQnkK2ZX5PrevTgOUEz+Ck54ZP8o4sMtdxJwMvEYA5AaJ /lZrHQq9zjWslS7EENHIMpAOQq/HrvGKIuooA0gABjTlUEHbHMeS3jjOWbUbgBl0 1szc7WOkhKGzYWbpE+nQ4hiNk6mizVSCsLVQk9KEt0IKLMQs1WPNH7nKxy9LXogY
    aeU/u7tB
    =H9os
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)