Re: Bug#989068: ITP: object-cloner -- Java Object cloning library with extensible strategies

[James Valleroy]

On 5/25/21 7:53 PM, Guillem Jover wrote:
> On Mon, 2021-05-24 at 20:08:57 -0400, James Valleroy wrote:
>>
>> * Package name: object-cloner
> 
> The source package seems overly generic, could you namespace it
> please? Say name it to what I assume might end up being the binary
> name «libobject-cloner-java»?
> 

Yes, the binary package name is libobject-cloner-java. I will use that for the 
source package name also.

Thanks for pointing this out.

-- 
James



OpenPGP_signature
Description: OpenPGP digital signature

Re: Planning for libidn shared library version transition

[Simon Josefsson]

Andreas Metzler  writes:

> On 2021-05-24 Simon Josefsson  wrote:
>> Hi!  This is for post-bullseye, but I appreciate guidance if anyone has
>> time.  Shared library version transitions trigger uncertainty in me.
>
>> I want to upload a new upstream libidn release into Debian, but upstream
>> has done a shared library transition.
>
> Hello Simon,
>
> I will assume that "shared library transition" means that that libidn
> 1.34 will have a soname bump (libidn12.so) but that the new release is
> API compatible. The following assumes this is true ...

Hi.  Thanks for review!

For all practical matters, yes, it is completely API compatible, the
only thing that changed was this struct (that should never have been in
the public .h anyway) that changed from:

  struct Stringprep_table
  {
Stringprep_profile_steps operation;
Stringprep_profile_flags flags;
const Stringprep_table_element *table;
  };
  typedef struct Stringprep_table Stringprep_profile;

into:

  struct Stringprep_table
  {
Stringprep_profile_steps operation;
Stringprep_profile_flags flags;
const Stringprep_table_element *table;
size_t table_size;
  };
  typedef struct Stringprep_table Stringprep_profile;

Arguably, doing a soname bump for this minor change could probably have
been avoided, but this was back in 2018 and other distributions have
upgraded to newer libidn.  If we revert the soname upstream now, it will
cause a lot of problems for others, so I don't think that is a good
idea.

We could patch upstream in Debian to avoid the soname bump, but that is
rather confusing.  It is good timing now to fix this once bullseye is
released, so I think we should just do that.

>> Bullseye will ship with
>> libidn11-dev instead of libidn-dev too.  Is the first step on the
>> transition to provide a libidn-dev package experimental (and after the
>> release, unstable) and make all reverse build-dependencies use it?
>
> That would delay the whole thing unnecessarily, you would not want to
> artificially make changing all rdeps a pre-dependency of your work
>
> First off if the new version of libidn is API compatible with 1.33 there
> will be no hard /requirement/ for renaming libidn11-dev to libidn12-dev.
> You could have libidn11-dev as a dev-package for libidn12. It is not
> aesthetically pleasing and confusing but would continue to work and has
> the least potential for error. OTOH a soname bump is good time for
> renaming the development package since you will have a new binary
> package (libidn12) and will need to go through NEW processing anyway.
> However you should do soname bump and  dev-package rename in one upload
> (to experimental) instead of beforehand. This ways ftp-master will only
> need to check it once. So you would use this timelime:
>
> 1. Prepare packages of the new upstream targeted for experimental
> (libidn12, libidn-dev, libidn11-dev transition package). Test.
> 2. Upload to experimental.
> 3. Wait for NEW processing
> 4. Do some more tests, once you thinks all rdeps could be built against
> libidn12 you request a transition slot. Please note that at this point
> no source changes to rdeps related to packaging changes needed to happen,
> they can (and should) continue to b-d on libidn11-dev which pulls in the
> libidn-dev.
> 5. debian-release gives you the GO for uploading the package to testing.
> 6. You do this and debian-release triggers rebuilds of all rdeps.
> 7. All rebuilt rdeps and libidn12/libidn-dev/libidn11-dev propagate to
> testing together 10 days later.
> 8. Now you can start submitting bug-reports against rdeps asking for a
> change of the b-d.

That (and your suggestions below) seems good.  I like it better than my
approach.  I'll start to implement this and post a debdiff for review
before actually making the upload into experimental.

/Simon

> [...]
>> A 'git diff' between the version in bullseye and what I want to upload
>> to experimental is shown below, together with debdiff-output between the
>> built packages.
>
>> Generally, does things looks okay?  Specifically, what about the
>> Breaks/Replaces/Conflicts?  The d/changelog entry?  Will the confusing
>> 'Replaces: libidn11-dev' for the libidn11 (!) package in bullseye cause
>> any problem?  Am I right to drop it here?
>
>>  Package: libidn11-dev
>> +Section: oldlibs
>> +Architecture: any
>> +Depends: libidn-dev, ${misc:Depends}
>
> I would use (= ${binary:Version}) for the depends to make sure that
> libidn11-dev 1.38 together with libidn-dev 1.34 do not fullfill a
> dependency on libidn11-dev (>= 1.35)
>
>> +Package: libidn-dev
>>  Section: libdevel
>>  Architecture: any
>>  Depends: libidn11 (= ${binary:Version}), pkg-config, ${misc:Depends}
>> -Conflicts: libidn9-dev
>> +Breaks: libidn11-dev (<< 1.33-4)
>> +Replaces: libidn11-dev (<< 1.33-4)
>> +Provides: libidn11-dev
>>  Multi-Arch: same
>>  Description: Development files for GNU Libidn, an IDN library
>
> You should drop the Provides - It is superfluous since you have got 

Re: Bug#989068: ITP: object-cloner -- Java Object cloning library with extensible strategies

[Guillem Jover]

Hi!

On Mon, 2021-05-24 at 20:08:57 -0400, James Valleroy wrote:
> Package: wnpp
> Severity: wishlist
> Owner: James Valleroy 
> X-Debbugs-Cc: debian-devel@lists.debian.org, jvalle...@mailbox.org
> 
> * Package name: object-cloner
>   Version : 0.2
>   Upstream Author : Kamran Zafar 
> * URL : https://github.com/kamranzafar/object-cloner
> * License : Apache-2.0
>   Programming Lang: Java
>   Description : Java Object cloning library with extensible strategies
> 
> Java Object cloning library. Supports extensible shallow and deep object 
> cloning strategies.
> 
> This is a dependency of jcl-core, which is needed for jitsi-videobridge 
> (#757769).

The source package seems overly generic, could you namespace it
please? Say name it to what I assume might end up being the binary
name «libobject-cloner-java»?

Thanks,
Guillem

Re: Planning for libidn shared library version transition

[Guillem Jover]

On Tue, 2021-05-25 at 19:43:21 +0200, Andreas Metzler wrote:
> On 2021-05-24 Simon Josefsson  wrote:
> > Generally, does things looks okay?  Specifically, what about the
> > Breaks/Replaces/Conflicts?  The d/changelog entry?  Will the confusing
> > 'Replaces: libidn11-dev' for the libidn11 (!) package in bullseye cause
> > any problem?  Am I right to drop it here?
> 
> >  Package: libidn11-dev
> > +Section: oldlibs
> > +Architecture: any
> > +Depends: libidn-dev, ${misc:Depends}
> 
> I would use (= ${binary:Version}) for the depends to make sure that
> libidn11-dev 1.38 together with libidn-dev 1.34 do not fullfill a
> dependency on libidn11-dev (>= 1.35)
> 
> > +Package: libidn-dev
> >  Section: libdevel
> >  Architecture: any
> >  Depends: libidn11 (= ${binary:Version}), pkg-config, ${misc:Depends}
> > -Conflicts: libidn9-dev
> > +Breaks: libidn11-dev (<< 1.33-4)
> > +Replaces: libidn11-dev (<< 1.33-4)
> > +Provides: libidn11-dev
> >  Multi-Arch: same
> >  Description: Development files for GNU Libidn, an IDN library
> 
> You should drop the Provides - It is superfluous since you have got a
> libidn11-dev transition package.

I'd probably instead make this a versioned Provides, so that the
transitional package can be removed right away from systems, it does
not interfere with the transition, and people can switch to the new
package in parallel w/o disruption.

Thanks,
Guillem

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

Bug#989101: ITP: libliftoff -- lightweight hardware composer library for libdrm

[Stephan Lachnit]

Package: wnpp
Severity: wishlist
Owner: Stephan Lachnit 
X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org

* Package name: libliftoff
  Version : 0.0.0~git20210430.799
  Upstream Author : Simon Ser <~emersion/public-in...@lists.sr.ht>
* URL : https://github.com/emersion/libliftoff
* License : MIT)
  Programming Lang: C
  Description : lightweight hardware composer library for libdrm

Dependency for gamescope. Not sure where to maintain, will probably talk to the
X Strike Force team.

Description:
libliftoff eases the use of KMS planes from userspace without standing in your
way. Users create "virtual planes" called layers, set KMS properties on them,
and libliftoff will pick planes for these layers if possible.

Longer explaination: https://emersion.fr/blog/2019/xdc2019-wrap-up/#libliftoff

- Stephan

Re: Planning for libidn shared library version transition

[Andreas Metzler]

On 2021-05-24 Simon Josefsson  wrote:
> Hi!  This is for post-bullseye, but I appreciate guidance if anyone has
> time.  Shared library version transitions trigger uncertainty in me.

> I want to upload a new upstream libidn release into Debian, but upstream
> has done a shared library transition.

Hello Simon,

I will assume that "shared library transition" means that that libidn
1.34 will have a soname bump (libidn12.so) but that the new release is
API compatible. The following assumes this is true ...

> Bullseye will ship with
> libidn11-dev instead of libidn-dev too.  Is the first step on the
> transition to provide a libidn-dev package experimental (and after the
> release, unstable) and make all reverse build-dependencies use it?

That would delay the whole thing unnecessarily, you would not want to
artificially make changing all rdeps a pre-dependency of your work

First off if the new version of libidn is API compatible with 1.33 there
will be no hard /requirement/ for renaming libidn11-dev to libidn12-dev.
You could have libidn11-dev as a dev-package for libidn12. It is not
aesthetically pleasing and confusing but would continue to work and has
the least potential for error. OTOH a soname bump is good time for
renaming the development package since you will have a new binary
package (libidn12) and will need to go through NEW processing anyway.
However you should do soname bump and  dev-package rename in one upload
(to experimental) instead of beforehand. This ways ftp-master will only
need to check it once. So you would use this timelime:

1. Prepare packages of the new upstream targeted for experimental
(libidn12, libidn-dev, libidn11-dev transition package). Test.
2. Upload to experimental.
3. Wait for NEW processing
4. Do some more tests, once you thinks all rdeps could be built against
libidn12 you request a transition slot. Please note that at this point
no source changes to rdeps related to packaging changes needed to happen,
they can (and should) continue to b-d on libidn11-dev which pulls in the
libidn-dev.
5. debian-release gives you the GO for uploading the package to testing.
6. You do this and debian-release triggers rebuilds of all rdeps.
7. All rebuilt rdeps and libidn12/libidn-dev/libidn11-dev propagate to
testing together 10 days later.
8. Now you can start submitting bug-reports against rdeps asking for a
change of the b-d.

[...]
> A 'git diff' between the version in bullseye and what I want to upload
> to experimental is shown below, together with debdiff-output between the
> built packages.

> Generally, does things looks okay?  Specifically, what about the
> Breaks/Replaces/Conflicts?  The d/changelog entry?  Will the confusing
> 'Replaces: libidn11-dev' for the libidn11 (!) package in bullseye cause
> any problem?  Am I right to drop it here?

>  Package: libidn11-dev
> +Section: oldlibs
> +Architecture: any
> +Depends: libidn-dev, ${misc:Depends}

I would use (= ${binary:Version}) for the depends to make sure that
libidn11-dev 1.38 together with libidn-dev 1.34 do not fullfill a
dependency on libidn11-dev (>= 1.35)

> +Package: libidn-dev
>  Section: libdevel
>  Architecture: any
>  Depends: libidn11 (= ${binary:Version}), pkg-config, ${misc:Depends}
> -Conflicts: libidn9-dev
> +Breaks: libidn11-dev (<< 1.33-4)
> +Replaces: libidn11-dev (<< 1.33-4)
> +Provides: libidn11-dev
>  Multi-Arch: same
>  Description: Development files for GNU Libidn, an IDN library

You should drop the Provides - It is superfluous since you have got a
libidn11-dev transition package.

hth, cu Andreas


-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#989085: ITP: gamescope -- micro-compositor for games

[Stephan Lachnit]

Package: wnpp
Severity: wishlist
Owner: Stephan Lachnit 
X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org.com

* Package name: gamescope
  Version : 3.8.1
  Upstream Author : Pierre-Loup A. Griffais
* URL : https://github.com/Plagman/gamescope
* License : BSD-2-Clause
  Programming Lang: C
  Description : micro-compositor for games

Will maintain in Games team.

Description on GitHub:

In an embedded session usecase, gamescope does the same thing as steamcompmgr,
but with less extra copies and latency:

It's getting game frames through Wayland by way of Xwayland, so there's no
copy within X itself before it gets the frame.
It can use DRM/KMS to directly flip game frames to the screen, even when
stretching or when notifications are up, removing another copy.
When it does need to composite with the GPU, it does so with async Vulkan
compute, meaning you get to see your frame quick even if the game already has
the GPU busy with the next frame.

It also runs on top of a regular desktop, the 'nested' usecase steamcompmgr
didn't support.

Because the game is running in its own personal Xwayland sandbox desktop,
it can't interfere with your desktop and your desktop can't interfere with it.
You can spoof a virtual screen with a desired resolution and refresh rate
as the only thing the game sees, and control/resize the output as needed. This
can be useful in exotic display configurations like ultrawide or multi-monitor
setups that involve rotation.

It runs on Mesa+AMDGPU, and could be made to run on other Mesa/DRM drivers with
minimal work. Can support NVIDIA if/when they support accelerated Xwayland.


- Stephan

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