Re: Epoch bump for kernelshark

[Sudip Mukherjee]

On Wed, May 26, 2021 at 12:10 AM David Bremner  wrote:
>
> Mattia Rizzolo  writes:
>
> > On Sun, May 23, 2021 at 03:17:10PM -0500, Richard Laager wrote:
> >> On 5/23/21 8:34 AM, Sudip Mukherjee wrote:
> >> > And, as a result, upstream kernelshark is now at v2.0 but the Debian
> >> > packaged version is at v2.9.1 and I will need to add an epoch to the
> >> > version to package it directly from its new upstream repo.
> >> >
> >> > Current version: 2.9.1-1
> >> > Proposed version: 1:2.0-1
> >>
> >> How close is upstream to 3.0? If not close, are they willing to bump to 3.0
> >> anyway to avoid this versioning issue?
> >
> > And in the meantime, I recommend you use 2.0-1 as source version, and
> > make the binary 2.9.1+really$(DEB_VERSION) (DEB_VERSION coming from
> > /usr/share/dpkg/pkg-info.mk)
> >
>
> _If_ upstream is willing to do that, then great. Otherwise I don't see
> the problem with an epoch in this kind of situation. It's exactly the
> kind of change of versioning they were designed for.

I have asked upstream but Steve (upstream) is on holiday till 28th so
I dont expect an answer before that. But I am pretty sure he will not
be willing to change the version as the upstream versions had been
consistent all along.


-- 
Regards
Sudip

Re: Epoch bump for kernelshark

[Sudip Mukherjee]

On Tue, May 25, 2021 at 4:18 PM Mattia Rizzolo  wrote:
>
> On Sun, May 23, 2021 at 03:17:10PM -0500, Richard Laager wrote:
> > On 5/23/21 8:34 AM, Sudip Mukherjee wrote:
> > > And, as a result, upstream kernelshark is now at v2.0 but the Debian
> > > packaged version is at v2.9.1 and I will need to add an epoch to the
> > > version to package it directly from its new upstream repo.
> > >
> > > Current version: 2.9.1-1
> > > Proposed version: 1:2.0-1
> >
> > How close is upstream to 3.0? If not close, are they willing to bump to 3.0
> > anyway to avoid this versioning issue?
>
> And in the meantime, I recommend you use 2.0-1 as source version, and
> make the binary 2.9.1+really$(DEB_VERSION) (DEB_VERSION coming from
> /usr/share/dpkg/pkg-info.mk)

Thats a cool trick. Thanks.

I should have thought of this, you have previously given me this kind
of idea. ;-)


-- 
Regards
Sudip

Re: Epoch bump for kernelshark

[Guillem Jover]

On Tue, 2021-05-25 at 20:04:04 -0300, David Bremner wrote:
> Mattia Rizzolo  writes:
> > On Sun, May 23, 2021 at 03:17:10PM -0500, Richard Laager wrote:
> >> On 5/23/21 8:34 AM, Sudip Mukherjee wrote:
> >> > And, as a result, upstream kernelshark is now at v2.0 but the Debian
> >> > packaged version is at v2.9.1 and I will need to add an epoch to the
> >> > version to package it directly from its new upstream repo.
> >> > 
> >> > Current version: 2.9.1-1
> >> > Proposed version: 1:2.0-1
> >> 
> >> How close is upstream to 3.0? If not close, are they willing to bump to 3.0
> >> anyway to avoid this versioning issue?

Not necessarily 3.0, just say 2.9.2 would be enough.

> > And in the meantime, I recommend you use 2.0-1 as source version, and
> > make the binary 2.9.1+really$(DEB_VERSION) (DEB_VERSION coming from
> > /usr/share/dpkg/pkg-info.mk)

I'd go with something like this too, given that the versioning has been
wrong all this time, so I don't see why it cannot be kept "wrong" until
the split package catches up with the old version.

> _If_ upstream is willing to do that, then great. Otherwise I don't see
> the problem with an epoch in this kind of situation. It's exactly the
> kind of change of versioning they were designed for.

Epochs are *always* problematic:

  


and I'd probably place this case it in the "acceptable with conditions",
where "conditions" would be "epoch does not seem necessary", given that
the versioning was correct upstream but was ignored all along, and the
versions are very close so it should be a reasonable matter of time to
catch up, even if upstream does not want to artificially bump it right
away.

Thanks,
Guillem

Re: Epoch bump for kernelshark

[David Bremner]

Mattia Rizzolo  writes:

> On Sun, May 23, 2021 at 03:17:10PM -0500, Richard Laager wrote:
>> On 5/23/21 8:34 AM, Sudip Mukherjee wrote:
>> > And, as a result, upstream kernelshark is now at v2.0 but the Debian
>> > packaged version is at v2.9.1 and I will need to add an epoch to the
>> > version to package it directly from its new upstream repo.
>> > 
>> > Current version: 2.9.1-1
>> > Proposed version: 1:2.0-1
>> 
>> How close is upstream to 3.0? If not close, are they willing to bump to 3.0
>> anyway to avoid this versioning issue?
>
> And in the meantime, I recommend you use 2.0-1 as source version, and
> make the binary 2.9.1+really$(DEB_VERSION) (DEB_VERSION coming from
> /usr/share/dpkg/pkg-info.mk)
>

_If_ upstream is willing to do that, then great. Otherwise I don't see
the problem with an epoch in this kind of situation. It's exactly the
kind of change of versioning they were designed for.

d

Re: Epoch bump for kernelshark

[Mattia Rizzolo]

On Sun, May 23, 2021 at 03:17:10PM -0500, Richard Laager wrote:
> On 5/23/21 8:34 AM, Sudip Mukherjee wrote:
> > And, as a result, upstream kernelshark is now at v2.0 but the Debian
> > packaged version is at v2.9.1 and I will need to add an epoch to the
> > version to package it directly from its new upstream repo.
> > 
> > Current version: 2.9.1-1
> > Proposed version: 1:2.0-1
> 
> How close is upstream to 3.0? If not close, are they willing to bump to 3.0
> anyway to avoid this versioning issue?

And in the meantime, I recommend you use 2.0-1 as source version, and
make the binary 2.9.1+really$(DEB_VERSION) (DEB_VERSION coming from
/usr/share/dpkg/pkg-info.mk)


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Epoch bump for kernelshark

[Richard Laager]

On 5/23/21 8:34 AM, Sudip Mukherjee wrote:

And, as a result, upstream kernelshark is now at v2.0 but the Debian
packaged version is at v2.9.1 and I will need to add an epoch to the
version to package it directly from its new upstream repo.

Current version: 2.9.1-1
Proposed version: 1:2.0-1


How close is upstream to 3.0? If not close, are they willing to bump to 
3.0 anyway to avoid this versioning issue?


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Epoch bump for kernelshark

[Sudip Mukherjee]

Hi All,

Kernelshark had been part of trace-cmd (till now) and when it was
packaged for Debian the binary 'kernelshark' was packaged with a
version same as 'trace-cmd' and the 'kernelshark' version was ignored
even though it had its own version. The version in Jessie was supposed
to be v0.2 instead of v2.4.0 [1]. Now the upstream developers have
decided to move kernelshark to its own repo at [2] removing it from
trace-cmd.

And, as a result, upstream kernelshark is now at v2.0 but the Debian
packaged version is at v2.9.1 and I will need to add an epoch to the
version to package it directly from its new upstream repo.

Current version: 2.9.1-1
Proposed version: 1:2.0-1

[1]. https://sources.debian.org/src/trace-cmd/2.4.0-1/Makefile/#L6
[2]. https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git/


-- 
Regards
Sudip