Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
dec. 1., P, 18:47):
>
> Hi Balint,
>
>
> On 16/11/2023 18:55, Bálint Réczey wrote:
> > Hi Colin,
> >
> > Colin King (gmail)  ezt írta (időpont: 2023.
> > nov. 16., Cs, 17:46):
> >>
> >> Hi Balint,
> >>>
> >>> Since libtypec installs include files and libs to the standard
> >>> locations actually there is no need to set those paths.
> >>> I think I would use the following patch:
> >>>
> >>> --- a/libtypec.pc.in
> >>> +++ b/libtypec.pc.in
> >>> @@ -1,12 +1,9 @@
> >>>prefix=/usr
> >>>exec_prefix=/usr
> >>> -libdir=${exec_prefix}/lib/x86_64-linux-gnu
> >>> -includedir=${prefix}/
> >>>
> >>>Name: libtypec
> >>>Description: USB-Type C and USB Power Delivery class devices
> >>>Version: 0.4.0
> >>>
> >>>Requires:
> >>> -Libs: -L${libdir} -llibtypec
> >>> -Cflags: -I${includedir}
> >>> +Libs: -llibtypec
> >>>
> >
> > I think this patch application did not work out as intended, please
> > check the patched file.
> >
> > The symbols file's first line is also still off and now the symbos
> > have debian package revisions.
> >
> > Those are issues automatically detected by Lintian. I suggest running
> > lintian on the built binary packages' .changes file or populating the
> > packaging repository on Salsa where CI runs include lintian and many
> > other checks.
>
> I ran lintian but I didn't see the errors, I used:
>
> lintian --profile=debian --pedantic libtypec_0.4-3_source.changes
>
> perhaps there are some extra lintian flags or config settings that I'm
> missing. Any suggestions?

Yes, please run Lintian on the _binary_ packages. You ran
dpkg-buildpackage with -S, that generated a source only build.
This can be seen from the *_source.changes name.
If you don't pass -S to dpkg it will build the binaries as well, with
the *_amd64.changes file (assuming you build on amd64)

Cheers,
Balint


>
> Colin
>
>
>
> >
> > Cheers,
> > Balint
> >
> >> Ah, good idea. I've refreshed package with this change. Also updated the
> >> .symbols file and uploaded a -4 to mentors.
> >>
> >> Colin
>
>
>

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi Balint,


On 16/11/2023 18:55, Bálint Réczey wrote:

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 17:46):


Hi Balint,


Since libtypec installs include files and libs to the standard
locations actually there is no need to set those paths.
I think I would use the following patch:

--- a/libtypec.pc.in
+++ b/libtypec.pc.in
@@ -1,12 +1,9 @@
   prefix=/usr
   exec_prefix=/usr
-libdir=${exec_prefix}/lib/x86_64-linux-gnu
-includedir=${prefix}/

   Name: libtypec
   Description: USB-Type C and USB Power Delivery class devices
   Version: 0.4.0

   Requires:
-Libs: -L${libdir} -llibtypec
-Cflags: -I${includedir}
+Libs: -llibtypec



I think this patch application did not work out as intended, please
check the patched file.

The symbols file's first line is also still off and now the symbos
have debian package revisions.

Those are issues automatically detected by Lintian. I suggest running
lintian on the built binary packages' .changes file or populating the
packaging repository on Salsa where CI runs include lintian and many
other checks.


I ran lintian but I didn't see the errors, I used:

lintian --profile=debian --pedantic libtypec_0.4-3_source.changes

perhaps there are some extra lintian flags or config settings that I'm 
missing. Any suggestions?


Colin





Cheers,
Balint


Ah, good idea. I've refreshed package with this change. Also updated the
.symbols file and uploaded a -4 to mentors.

Colin

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 17:46):
>
> Hi Balint,
> >
> > Since libtypec installs include files and libs to the standard
> > locations actually there is no need to set those paths.
> > I think I would use the following patch:
> >
> > --- a/libtypec.pc.in
> > +++ b/libtypec.pc.in
> > @@ -1,12 +1,9 @@
> >   prefix=/usr
> >   exec_prefix=/usr
> > -libdir=${exec_prefix}/lib/x86_64-linux-gnu
> > -includedir=${prefix}/
> >
> >   Name: libtypec
> >   Description: USB-Type C and USB Power Delivery class devices
> >   Version: 0.4.0
> >
> >   Requires:
> > -Libs: -L${libdir} -llibtypec
> > -Cflags: -I${includedir}
> > +Libs: -llibtypec
> >

I think this patch application did not work out as intended, please
check the patched file.

The symbols file's first line is also still off and now the symbos
have debian package revisions.

Those are issues automatically detected by Lintian. I suggest running
lintian on the built binary packages' .changes file or populating the
packaging repository on Salsa where CI runs include lintian and many
other checks.

Cheers,
Balint

> Ah, good idea. I've refreshed package with this change. Also updated the
> .symbols file and uploaded a -4 to mentors.
>
> Colin

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi Balint,


Since libtypec installs include files and libs to the standard
locations actually there is no need to set those paths.
I think I would use the following patch:

--- a/libtypec.pc.in
+++ b/libtypec.pc.in
@@ -1,12 +1,9 @@
  prefix=/usr
  exec_prefix=/usr
-libdir=${exec_prefix}/lib/x86_64-linux-gnu
-includedir=${prefix}/

  Name: libtypec
  Description: USB-Type C and USB Power Delivery class devices
  Version: 0.4.0

  Requires:
-Libs: -L${libdir} -llibtypec
-Cflags: -I${includedir}
+Libs: -llibtypec



Ah, good idea. I've refreshed package with this change. Also updated the 
.symbols file and uploaded a -4 to mentors.


Colin

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 14:00):
>
> Hi again Balint,
>
> On 16/11/2023 11:35, Bálint Réczey wrote:
> > Hi Colin,
> >
> > Thanks for the quick response.
> > Please check my other observations, too, in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041327#58
>
> You mentioned:
>
> "The .pc file is now at the right location, but contains multiarch
> strings which will differ across architectures.
> I suggest hardcoding the paths in the patch."
>
> I'm not quite sure what is incorrect here, this file is patched already
> via debian/patches/0001-fix-libtypec-libdir.patch
>
> For an i386 build, the .pc file in usr/share/pkgconfig contains:
>
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib/i386-linux-gnu
> includedir=${prefix}/include/i386-linux-gnu
> ..
>
> For a x86-64 build, the .pc file in usr/share/pkgconfig contains:
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib/x86_64-linux-gnu
> includedir=${prefix}/include/x86_64-linux-gnu
> ..
>
> For an arm64 build, the .pc file in usr/share/pkgconfig contains:
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib/aarch64-linux-gnu
> includedir=${prefix}/include/aarch64-linux-gnu
> ..
>
> ..so I'm a bit confused. Do you mind clarifying for me.

I'm sorry, my comment was a bit vague, indeed.
So the problem is having the multiarch string in the .pc file, while
the file is not in a multiarch location.
Lintian throws an error about it, that would cause an auto-reject when
uploading the package:

E: libtypec-dev: pkg-config-multi-arch-wrong-dir full text contains
architecture specific dir x86_64-linux-gnu
[usr/share/pkgconfig/libtypec.pc]
N:
N:   The arch all pkg-config file contains a reference to a multi-arch path

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi again Balint,

On 16/11/2023 11:35, Bálint Réczey wrote:

Hi Colin,

Thanks for the quick response.
Please check my other observations, too, in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041327#58


You mentioned:

"The .pc file is now at the right location, but contains multiarch
strings which will differ across architectures.
I suggest hardcoding the paths in the patch."

I'm not quite sure what is incorrect here, this file is patched already 
via debian/patches/0001-fix-libtypec-libdir.patch


For an i386 build, the .pc file in usr/share/pkgconfig contains:

prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/i386-linux-gnu
includedir=${prefix}/include/i386-linux-gnu
..

For a x86-64 build, the .pc file in usr/share/pkgconfig contains:
prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include/x86_64-linux-gnu
..

For an arm64 build, the .pc file in usr/share/pkgconfig contains:
prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/aarch64-linux-gnu
includedir=${prefix}/include/aarch64-linux-gnu
..

..so I'm a bit confused. Do you mind clarifying for me.

Colin

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Thanks for the quick response.
Please check my other observations, too, in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041327#58

Cheers,
Balint

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 11:22):
>
> On 15/11/2023 13:47, Bálint Réczey wrote:
> > Hi Colin,
> >
> > There are a few upstream source files licensed under GPL.
> > Please update debian/copyright to cover all the used licenses.
>
> Updated and uploaded -3 to mentors
>
> Thanks for the prompt review feedback. Much appreciated.
>
> Colin
>
> >
> > You can run 'cme update dpkg-copyright' in the source directory or any
> > other tool from https://wiki.debian.org/CopyrightReviewTools
> >  to help with the manual
> > labor.
> >
> > Cheers,
> > Balint
> >
> > On 2023. Nov 15., Wed at 10:27, Bálint Réczey  > > wrote:
> >
> > Hi Colin,
> >
> > Colin King (gmail)  > > ezt írta (időpont: 2023.
> > nov. 14., K, 17:58):
> >  >
> >  > Hi Balint,
> >  >
> >  > I've uploaded 0.4.0-2 with the suggested fixes.
> >  >
> >  > reply inlined below:
> >  >
> >  > On 09/11/2023 16:23, Bálint Réczey wrote:
> >  > > Hi Colin,
> >  > >
> >  > > Colin King (gmail)  > > ezt írta (időpont: 2023.
> >  > > nov. 7., K, 15:18):
> >  > >>
> >  > >> Hi Balint,
> >  > >>
> >  > >> Thanks for responding with the review. I was waiting for the
> > upstream
> >  > >> project to release a 0.4 with some minor fixes before
> > re-uploading to
> >  > >> mentors.
> >  > >>
> >  > >> I've addressed the issues you found as below:
> >  > >
> >  > > Please see my observations below.
> >  > >
> >  > >> On 22/10/2023 22:38, Bálint Réczey wrote:
> >  > >>> Hi Colin,
> >  > >>>
> >  > >>> I've checked the second upload at [1].
> >  > >>> As you can see in the Lintian warnings there is a .git
> > directory which
> >  > >>> is not ideal for a source package.
> >  > >>> I suggest using the most widely used git-buildpackage based
> > workflow
> >  > >>> where the gbp command takes care of exporting the source package
> >  > >>> without the .git dir from the packaging repository.
> >  > >>> I'd be happy to set up a packaging repo for you at
> >  > >>> https://salsa.debian.org/debian/libtypec
> >  and add you as a maintainer
> >  > >>> as described in [2]
> >  > >
> >  > > I still hold up my offer about setting up a git repo for
> > packaging on
> >  > > Salsa. That comes with the benefit of automated fixes from Debian
> >  > > Janitor and I could also comment on changes right where they
> > happened.
> >  >
> >  > Thank you for your kind offer; I definitely think this is a good
> > idea,
> >  > please can you set this up for me. Much appreciated!
> >
> > I've created the repo at https://salsa.debian.org/debian/libtypec
> >  and
> > added you as a maintainer.
> > I've also set up CI, thus when you push your branches the pipelines
> > will start.
> >
> > You may already be familiar with
> > https://dep-team.pages.debian.net/deps/dep14/
> >  , but if not, please
> > check it before pushing your packaging repository.
> >
> > ...
> >
> >  > > I think my comment here was misleading, sorry for that.
> >  > > Shipping *.pc is desired, shipping it in the .../libtypec.pc/
> > dir as a
> >  > > result of specifying .../libtypec.pc as the target dir in the
> > .install
> >  > > file was not desired. It was even patched to have the right
> > content.
> >  > > Please ship the .pc file in the -dev package.
> >  >
> >  > Fixed.
> >
> > The .pc file is now at the right location, but contains multiarch
> > strings which will differ across architectures.
> > I suggest hardcoding the paths in the patch.
> >
> > ...
> >
> >  > > * As you switched back to use upstream's 0.4.0 SO version the
> > .symbols
> >  > > file became wrong  not matching the shipped SO version. Please fix
> >  > > that and also switch to the libtypec0 package name since it
> > needs to
> >  > > match upstream's major SO version
> >  >
> >  > Fixed.
> >
> > The .symbols file's first line should be:
> >   libtypec.so.0 libtypec0 #MINVER#
> >
> > See deb-symbols(5) for more details.
> >
> >  > .
> >  > >
> >  > > * I'd recommend asking upstream to switch to semantic SO versioning
> >  > > instead of using the project's version and switching to major
> > version
> >  > > 1 when the API stabilized.
> >  >
> >  > Good idea. Will do when API changes and stabilizes.
> >
> > 

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

On 15/11/2023 13:47, Bálint Réczey wrote:

Hi Colin,

There are a few upstream source files licensed under GPL.
Please update debian/copyright to cover all the used licenses.


Updated and uploaded -3 to mentors

Thanks for the prompt review feedback. Much appreciated.

Colin



You can run 'cme update dpkg-copyright' in the source directory or any 
other tool from https://wiki.debian.org/CopyrightReviewTools 
 to help with the manual 
labor.


Cheers,
Balint

On 2023. Nov 15., Wed at 10:27, Bálint Réczey > wrote:


Hi Colin,

Colin King (gmail) mailto:colin.i.k...@gmail.com>> ezt írta (időpont: 2023.
nov. 14., K, 17:58):
 >
 > Hi Balint,
 >
 > I've uploaded 0.4.0-2 with the suggested fixes.
 >
 > reply inlined below:
 >
 > On 09/11/2023 16:23, Bálint Réczey wrote:
 > > Hi Colin,
 > >
 > > Colin King (gmail) mailto:colin.i.k...@gmail.com>> ezt írta (időpont: 2023.
 > > nov. 7., K, 15:18):
 > >>
 > >> Hi Balint,
 > >>
 > >> Thanks for responding with the review. I was waiting for the
upstream
 > >> project to release a 0.4 with some minor fixes before
re-uploading to
 > >> mentors.
 > >>
 > >> I've addressed the issues you found as below:
 > >
 > > Please see my observations below.
 > >
 > >> On 22/10/2023 22:38, Bálint Réczey wrote:
 > >>> Hi Colin,
 > >>>
 > >>> I've checked the second upload at [1].
 > >>> As you can see in the Lintian warnings there is a .git
directory which
 > >>> is not ideal for a source package.
 > >>> I suggest using the most widely used git-buildpackage based
workflow
 > >>> where the gbp command takes care of exporting the source package
 > >>> without the .git dir from the packaging repository.
 > >>> I'd be happy to set up a packaging repo for you at
 > >>> https://salsa.debian.org/debian/libtypec
 and add you as a maintainer
 > >>> as described in [2]
 > >
 > > I still hold up my offer about setting up a git repo for
packaging on
 > > Salsa. That comes with the benefit of automated fixes from Debian
 > > Janitor and I could also comment on changes right where they
happened.
 >
 > Thank you for your kind offer; I definitely think this is a good
idea,
 > please can you set this up for me. Much appreciated!

I've created the repo at https://salsa.debian.org/debian/libtypec
 and
added you as a maintainer.
I've also set up CI, thus when you push your branches the pipelines
will start.

You may already be familiar with
https://dep-team.pages.debian.net/deps/dep14/
 , but if not, please
check it before pushing your packaging repository.

...

 > > I think my comment here was misleading, sorry for that.
 > > Shipping *.pc is desired, shipping it in the .../libtypec.pc/
dir as a
 > > result of specifying .../libtypec.pc as the target dir in the
.install
 > > file was not desired. It was even patched to have the right
content.
 > > Please ship the .pc file in the -dev package.
 >
 > Fixed.

The .pc file is now at the right location, but contains multiarch
strings which will differ across architectures.
I suggest hardcoding the paths in the patch.

...

 > > * As you switched back to use upstream's 0.4.0 SO version the
.symbols
 > > file became wrong  not matching the shipped SO version. Please fix
 > > that and also switch to the libtypec0 package name since it
needs to
 > > match upstream's major SO version
 >
 > Fixed.

The .symbols file's first line should be:
  libtypec.so.0 libtypec0 #MINVER#

See deb-symbols(5) for more details.

 > .
 > >
 > > * I'd recommend asking upstream to switch to semantic SO versioning
 > > instead of using the project's version and switching to major
version
 > > 1 when the API stabilized.
 >
 > Good idea. Will do when API changes and stabilizes.

Great!

Cheers,
Balint

 > Colin
 >
 > >
 > > Cheers,
 > > Balint
 > >
 > >> Kind regards,
 > >>
 > >> Colin
 > >>
 > >>
 > >>> Cheers,
 > >>> Balint
 > >>>
 > >>> [1] https://mentors.debian.net/package/libtypec/

 > >>> [2]
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group 

 > >>>
 > >>> On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
 > >>> mailto:colin.i.k...@gmail.com>> wrote:
 >  Hi,
 > 
 >  I've uploaded a fixed package that addresses these 

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

There are a few upstream source files licensed under GPL.
Please update debian/copyright to cover all the used licenses.

You can run 'cme update dpkg-copyright' in the source directory or any
other tool from https://wiki.debian.org/CopyrightReviewTools to help with
the manual labor.

Cheers,
Balint

On 2023. Nov 15., Wed at 10:27, Bálint Réczey 
wrote:

> Hi Colin,
>
> Colin King (gmail)  ezt írta (időpont: 2023.
> nov. 14., K, 17:58):
> >
> > Hi Balint,
> >
> > I've uploaded 0.4.0-2 with the suggested fixes.
> >
> > reply inlined below:
> >
> > On 09/11/2023 16:23, Bálint Réczey wrote:
> > > Hi Colin,
> > >
> > > Colin King (gmail)  ezt írta (időpont: 2023.
> > > nov. 7., K, 15:18):
> > >>
> > >> Hi Balint,
> > >>
> > >> Thanks for responding with the review. I was waiting for the upstream
> > >> project to release a 0.4 with some minor fixes before re-uploading to
> > >> mentors.
> > >>
> > >> I've addressed the issues you found as below:
> > >
> > > Please see my observations below.
> > >
> > >> On 22/10/2023 22:38, Bálint Réczey wrote:
> > >>> Hi Colin,
> > >>>
> > >>> I've checked the second upload at [1].
> > >>> As you can see in the Lintian warnings there is a .git directory
> which
> > >>> is not ideal for a source package.
> > >>> I suggest using the most widely used git-buildpackage based workflow
> > >>> where the gbp command takes care of exporting the source package
> > >>> without the .git dir from the packaging repository.
> > >>> I'd be happy to set up a packaging repo for you at
> > >>> https://salsa.debian.org/debian/libtypec and add you as a maintainer
> > >>> as described in [2]
> > >
> > > I still hold up my offer about setting up a git repo for packaging on
> > > Salsa. That comes with the benefit of automated fixes from Debian
> > > Janitor and I could also comment on changes right where they happened

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 14., K, 17:58):
>
> Hi Balint,
>
> I've uploaded 0.4.0-2 with the suggested fixes.
>
> reply inlined below:
>
> On 09/11/2023 16:23, Bálint Réczey wrote:
> > Hi Colin,
> >
> > Colin King (gmail)  ezt írta (időpont: 2023.
> > nov. 7., K, 15:18):
> >>
> >> Hi Balint,
> >>
> >> Thanks for responding with the review. I was waiting for the upstream
> >> project to release a 0.4 with some minor fixes before re-uploading to
> >> mentors.
> >>
> >> I've addressed the issues you found as below:
> >
> > Please see my observations below.
> >
> >> On 22/10/2023 22:38, Bálint Réczey wrote:
> >>> Hi Colin,
> >>>
> >>> I've checked the second upload at [1].
> >>> As you can see in the Lintian warnings there is a .git directory which
> >>> is not ideal for a source package.
> >>> I suggest using the most widely used git-buildpackage based workflow
> >>> where the gbp command takes care of exporting the source package
> >>> without the .git dir from the packaging repository.
> >>> I'd be happy to set up a packaging repo for you at
> >>> https://salsa.debian.org/debian/libtypec and add you as a maintainer
> >>> as described in [2]
> >
> > I still hold up my offer about setting up a git repo for packaging on
> > Salsa. That comes with the benefit of automated fixes from Debian
> > Janitor and I could also comment on changes right where they happened.
>
> Thank you for your kind offer; I definitely think this is a good idea,
> please can you set this up for me. Much appreciated!

I've created the repo at https://salsa.debian.org/debian/libtypec and
added you as a maintainer.
I've also set up CI, thus when you push your branches the pipelines will start.

You may already be familiar with
https://dep-team.pages.debian.net/deps/dep14/ , but if not, please
check it before pushing your packaging repository.

...

> > I think my comment here was misleading, sorry for that.
> > Shipping *.pc is desired, shipping it in the .../libtypec.pc/ dir as a
> > result of specifying .../libtypec.pc as the target dir in the .install
> > file was not desired. It was even patched to have the right content.
> > Please ship the .pc file in the -dev package.
>
> Fixed.

The .pc file is now at the right location, but contains multiarch
strings which will differ across architectures.
I suggest hardcoding the paths in the patch.

...

> > * As you switched back to use upstream's 0.4.0 SO version the .symbols
> > file became wrong  not matching the shipped SO version. Please fix
> > that and also switch to the libtypec0 package name since it needs to
> > match upstream's major SO version
>
> Fixed.

The .symbols file's first line should be:
 libtypec.so.0 libtypec0 #MINVER#

See deb-symbols(5) for more details.

> .
> >
> > * I'd recommend asking upstream to switch to semantic SO versioning
> > instead of using the project's version and switching to major version
> > 1 when the API stabilized.
>
> Good idea. Will do when API changes and stabilizes.

Great!

Cheers,
Balint

> Colin
>
> >
> > Cheers,
> > Balint
> >
> >> Kind regards,
> >>
> >> Colin
> >>
> >>
> >>> Cheers,
> >>> Balint
> >>>
> >>> [1] https://mentors.debian.net/package/libtypec/
> >>> [2] 
> >>> https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
> >>>
> >>> On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
> >>>  wrote:
>  Hi,
> 
>  I've uploaded a fixed package that addresses these issues.
> 
>  Colin
> 
>  On 18/07/2023 08:50, Adam Borowski wrote:
> > On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:
> >> * Package name : libtypec
> >>   Version  : 0.3-1
> >> * URL  : https://github.com/Rajaram-Regupathy/libtypec
> >
> >>  libtypec1 - generic interface for efficient USB-C port management
> >>  libtypec-dev - Development files for an interface for USB-C port 
> >> management
> >
> >> libtypec (0.3-1) unstable; urgency=low
> >> .
> >>   * Initial release (Closes: #1023477)
> >>   * Add patch 0001-fix-libtypec-so-version.patch to fix .so name 
> >> version
> >
> > Hi!
> > Before doing manual review, let's start with lintian:
> >
> > E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains 
> > architecture specific dir x86_64-linux-gnu 
> > [usr/share/pkgconfig/libtypec.pc]
> > W: libtypec-dev: empty-binary-package
> > W: libtypec1: lacks-unversioned-link-to-shared-library example: 
> > usr/lib/x86_64-linux-gnu/libtypec.so 
> > [usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
> > W: libtypec1: link-to-shared-library-in-wrong-package 
> > usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
> > [usr/lib/x86_64-linux-gnu/libtypec.so]
> >
> >
> > Meow!
> 
> 
> 
> >>>
> >>
> >>
>

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi Balint,

I've uploaded 0.4.0-2 with the suggested fixes.

reply inlined below:

On 09/11/2023 16:23, Bálint Réczey wrote:

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 7., K, 15:18):


Hi Balint,

Thanks for responding with the review. I was waiting for the upstream
project to release a 0.4 with some minor fixes before re-uploading to
mentors.

I've addressed the issues you found as below:


Please see my observations below.


On 22/10/2023 22:38, Bálint Réczey wrote:

Hi Colin,

I've checked the second upload at [1].
As you can see in the Lintian warnings there is a .git directory which
is not ideal for a source package.
I suggest using the most widely used git-buildpackage based workflow
where the gbp command takes care of exporting the source package
without the .git dir from the packaging repository.
I'd be happy to set up a packaging repo for you at
https://salsa.debian.org/debian/libtypec and add you as a maintainer
as described in [2]


I still hold up my offer about setting up a git repo for packaging on
Salsa. That comes with the benefit of automated fixes from Debian
Janitor and I could also comment on changes right where they happened.


Thank you for your kind offer; I definitely think this is a good idea, 
please can you set this up for me. Much appreciated!





Other observations regarding the packaging:

* There is debian/install and also there are binary package specific
*.install files which is slightly confusing.
 I suggest dropping debian/install.


Fixed


* In the debian/*.install files you need to specify only the target
dir, not the target file.


Fixed


In libtypec-dev
/usr/share/pkgconfig/${DEB_HOST_MULTIARCH}/libtypec.pc/libtypec.pc
gets shipped, which is not desired.


Fixed


I think my comment here was misleading, sorry for that.
Shipping *.pc is desired, shipping it in the .../libtypec.pc/ dir as a
result of specifying .../libtypec.pc as the target dir in the .install
file was not desired. It was even patched to have the right content.
Please ship the .pc file in the -dev package.


Fixed




* libtypec.h seems to be the same on all architectures. Does it have
to be shipped in a multiarch include location?


Fixed. Now in /usr/include and in the multiarch include location


* Binary packages in debian/control are not marked as Multi-Arch: same
* Please target experimental. The package needs to pass NEW and to
migrate to testing it will need a new source-only upload anyway.



Fixed.

Please review the 0.4 release upload and let me know if this can be
sponsored further to the changes I made.


* Both libtypec-dev.install and libtypec1.install lists
usr/lib/${DEB_HOST_MULTIARCH} and as a result both packages ship the
*.so symlink and *.so.0.4.0.
Please ship *.so.0.4.0 in the library package and the *.so symlink in
the -dev package only.


Fixed.



* As you switched back to use upstream's 0.4.0 SO version the .symbols
file became wrong  not matching the shipped SO version. Please fix
that and also switch to the libtypec0 package name since it needs to
match upstream's major SO version


Fixed.

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 7., K, 15:18):
>
> Hi Balint,
>
> Thanks for responding with the review. I was waiting for the upstream
> project to release a 0.4 with some minor fixes before re-uploading to
> mentors.
>
> I've addressed the issues you found as below:

Please see my observations below.

> On 22/10/2023 22:38, Bálint Réczey wrote:
> > Hi Colin,
> >
> > I've checked the second upload at [1].
> > As you can see in the Lintian warnings there is a .git directory which
> > is not ideal for a source package.
> > I suggest using the most widely used git-buildpackage based workflow
> > where the gbp command takes care of exporting the source package
> > without the .git dir from the packaging repository.
> > I'd be happy to set up a packaging repo for you at
> > https://salsa.debian.org/debian/libtypec and add you as a maintainer
> > as described in [2]

I still hold up my offer about setting up a git repo for packaging on
Salsa. That comes with the benefit of automated fixes from Debian
Janitor and I could also comment on changes right where they happened.

> > Other observations regarding the packaging:
> >
> > * There is debian/install and also there are binary package specific
> > *.install files which is slightly confusing.
> > I suggest dropping debian/install.
>
> Fixed
>
> > * In the debian/*.install files you need to specify only the target
> > dir, not the target file.
>
> Fixed
>
> >In libtypec-dev
> > /usr/share/pkgconfig/${DEB_HOST_MULTIARCH}/libtypec.pc/libtypec.pc
> > gets shipped, which is not desired.
>
> Fixed

I think my comment here was misleading, sorry for that.
Shipping *.pc is desired, shipping it in the .../libtypec.pc/ dir as a
result of specifying .../libtypec.pc as the target dir in the .install
file was not desired. It was even patched to have the right content.
Please ship the .pc file in the -dev package.

> > * libtypec.h seems to be the same on all architectures. Does it have
> > to be shipped in a multiarch include location?
>
> Fixed. Now in /usr/include and in the multiarch include location
>
> > * Binary packages in debian/control are not marked as Multi-Arch: same
> > * Please target experimental. The package needs to pass NEW and to
> > migrate to testing it will need a new source-only upload anyway.
> >
>
> Fixed.
>
> Please review the 0.4 release upload and let me know if this can be
> sponsored further to the changes I made.

* Both libtypec-dev.install and libtypec1.install lists
usr/lib/${DEB_HOST_MULTIARCH} and as a result both packages ship the
*.so symlink and *.so.0.4.0.
Please ship *.so.0.4.0 in the library package and the *.so symlink in
the -dev package only.

* As you switched back to use upstream's 0.4.0 SO version the .symbols
file became wrong  not matching the shipped SO version. Please fix
that and also switch to the libtypec0 package name since it needs to
match upstream's major SO version.

* I'd recommend asking upstream to switch to semantic SO versioning
instead of using the project's version and switching to major version
1 when the API stabilized.

Cheers,
Balint

> Kind regards,
>
> Colin
>
>
> > Cheers,
> > Balint
> >
> > [1] https://mentors.debian.net/package/libtypec/
> > [2] 
> > https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
> >
> > On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
> >  wrote:
> >> Hi,
> >>
> >> I've uploaded a fixed package that addresses these issues.
> >>
> >> Colin
> >>
> >> On 18/07/2023 08:50, Adam Borowski wrote:
> >>> On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:
> * Package name : libtypec
>   Version  : 0.3-1
> * URL  : https://github.com/Rajaram-Regupathy/libtypec
> >>>
>  libtypec1 - generic interface for efficient USB-C port management
>  libtypec-dev - Development files for an interface for USB-C port 
>  management
> >>>
> libtypec (0.3-1) unstable; urgency=low
> .
>   * Initial release (Closes: #1023477)
>   * Add patch 0001-fix-libtypec-so-version.patch to fix .so name 
>  version
> >>>
> >>> Hi!
> >>> Before doing manual review, let's start with lintian:
> >>>
> >>> E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains 
> >>> architecture specific dir x86_64-linux-gnu 
> >>> [usr/share/pkgconfig/libtypec.pc]
> >>> W: libtypec-dev: empty-binary-package
> >>> W: libtypec1: lacks-unversioned-link-to-shared-library example: 
> >>> usr/lib/x86_64-linux-gnu/libtypec.so 
> >>> [usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
> >>> W: libtypec1: link-to-shared-library-in-wrong-package 
> >>> usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
> >>> [usr/lib/x86_64-linux-gnu/libtypec.so]
> >>>
> >>>
> >>> Meow!
> >>
> >>
> >>
> >
>
>

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi Balint,

Thanks for responding with the review. I was waiting for the upstream 
project to release a 0.4 with some minor fixes before re-uploading to 
mentors.


I've addressed the issues you found as below:

On 22/10/2023 22:38, Bálint Réczey wrote:

Hi Colin,

I've checked the second upload at [1].
As you can see in the Lintian warnings there is a .git directory which
is not ideal for a source package.
I suggest using the most widely used git-buildpackage based workflow
where the gbp command takes care of exporting the source package
without the .git dir from the packaging repository.
I'd be happy to set up a packaging repo for you at
https://salsa.debian.org/debian/libtypec and add you as a maintainer
as described in [2]

Other observations regarding the packaging:

* There is debian/install and also there are binary package specific
*.install files which is slightly confusing.
I suggest dropping debian/install.


Fixed


* In the debian/*.install files you need to specify only the target
dir, not the target file.


Fixed


   In libtypec-dev
/usr/share/pkgconfig/${DEB_HOST_MULTIARCH}/libtypec.pc/libtypec.pc
gets shipped, which is not desired.


Fixed


* libtypec.h seems to be the same on all architectures. Does it have
to be shipped in a multiarch include location?


Fixed. Now in /usr/include and in the multiarch include location


* Binary packages in debian/control are not marked as Multi-Arch: same
* Please target experimental. The package needs to pass NEW and to
migrate to testing it will need a new source-only upload anyway.



Fixed.

Please review the 0.4 release upload and let me know if this can be 
sponsored further to the changes I made.


Kind regards,

Colin



Cheers,
Balint

[1] https://mentors.debian.net/package/libtypec/
[2] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
 wrote:

Hi,

I've uploaded a fixed package that addresses these issues.

Colin

On 18/07/2023 08:50, Adam Borowski wrote:

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:

   * Package name : libtypec
 Version  : 0.3-1
   * URL  : https://github.com/Rajaram-Regupathy/libtypec



libtypec1 - generic interface for efficient USB-C port management
libtypec-dev - Development files for an interface for USB-C port management



   libtypec (0.3-1) unstable; urgency=low
   .
 * Initial release (Closes: #1023477)
 * Add patch 0001-fix-libtypec-so-version.patch to fix .so name version


Hi!
Before doing manual review, let's start with lintian:

E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

I've checked the second upload at [1].
As you can see in the Lintian warnings there is a .git directory which
is not ideal for a source package.
I suggest using the most widely used git-buildpackage based workflow
where the gbp command takes care of exporting the source package
without the .git dir from the packaging repository.
I'd be happy to set up a packaging repo for you at
https://salsa.debian.org/debian/libtypec and add you as a maintainer
as described in [2]

Other observations regarding the packaging:

* There is debian/install and also there are binary package specific
*.install files which is slightly confusing.
   I suggest dropping debian/install.
* In the debian/*.install files you need to specify only the target
dir, not the target file.
  In libtypec-dev
/usr/share/pkgconfig/${DEB_HOST_MULTIARCH}/libtypec.pc/libtypec.pc
gets shipped, which is not desired.
* libtypec.h seems to be the same on all architectures. Does it have
to be shipped in a multiarch include location?
* Binary packages in debian/control are not marked as Multi-Arch: same
* Please target experimental. The package needs to pass NEW and to
migrate to testing it will need a new source-only upload anyway.

Cheers,
Balint

[1] https://mentors.debian.net/package/libtypec/
[2] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
 wrote:
> Hi,
>
> I've uploaded a fixed package that addresses these issues.
>
> Colin
>
> On 18/07/2023 08:50, Adam Borowski wrote:
> > On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:
> >>   * Package name : libtypec
> >> Version  : 0.3-1
> >>   * URL  : https://github.com/Rajaram-Regupathy/libtypec
> >
> >>libtypec1 - generic interface for efficient USB-C port management
> >>libtypec-dev - Development files for an interface for USB-C port 
> >> management
> >
> >>   libtypec (0.3-1) unstable; urgency=low
> >>   .
> >> * Initial release (Closes: #1023477)
> >> * Add patch 0001-fix-libtypec-so-version.patch to fix .so name version
> >
> > Hi!
> > Before doing manual review, let's start with lintian:
> >
> > E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains 
> > architecture specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
> > W: libtypec-dev: empty-binary-package
> > W: libtypec1: lacks-unversioned-link-to-shared-library example: 
> > usr/lib/x86_64-linux-gnu/libtypec.so 
> > [usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
> > W: libtypec1: link-to-shared-library-in-wrong-package 
> > usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
> > [usr/lib/x86_64-linux-gnu/libtypec.so]
> >
> >
> > Meow!
>
>
>

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi,

I've uploaded a fixed package that addresses these issues.

Colin

On 18/07/2023 08:50, Adam Borowski wrote:

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:

  * Package name : libtypec
Version  : 0.3-1
  * URL  : https://github.com/Rajaram-Regupathy/libtypec



   libtypec1 - generic interface for efficient USB-C port management
   libtypec-dev - Development files for an interface for USB-C port management



  libtypec (0.3-1) unstable; urgency=low
  .
* Initial release (Closes: #1023477)
* Add patch 0001-fix-libtypec-so-version.patch to fix .so name version


Hi!
Before doing manual review, let's start with lintian:

E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bo YU]

Hi Colin！

On Tue, Jul 18, 2023 at 5:12 PM Colin King (gmail)
 wrote:
>
> On 18/07/2023 08:50, Adam Borowski wrote:
> > On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:
> >>   * Package name : libtypec
> >> Version  : 0.3-1
> >>   * URL  : https://github.com/Rajaram-Regupathy/libtypec
> >
> >>libtypec1 - generic interface for efficient USB-C port management
> >>libtypec-dev - Development files for an interface for USB-C port 
> >> management
> >
> >>   libtypec (0.3-1) unstable; urgency=low
> >>   .
> >> * Initial release (Closes: #1023477)
> >> * Add patch 0001-fix-libtypec-so-version.patch to fix .so name version
> >
> > Hi!
> > Before doing manual review, let's start with lintian:
>
> Thanks, which lintian options did you use so I can santicy check my fixes?
>

Depends on the build tools you use. if you use sbuild, you can put
these options on ~/.sbuildrc:
```
$lintian_opts = ['-EvIL', '+pedantic'];
```
Or refer to here:
https://lintian.debian.org/manual/index.html#running-lintian

Bo
> Colin
>
> >
> > E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains 
> > architecture specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
> > W: libtypec-dev: empty-binary-package
> > W: libtypec1: lacks-unversioned-link-to-shared-library example: 
> > usr/lib/x86_64-linux-gnu/libtypec.so 
> > [usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
> > W: libtypec1: link-to-shared-library-in-wrong-package 
> > usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
> > [usr/lib/x86_64-linux-gnu/libtypec.so]
> >
> >
> > Meow!
>

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

On 18/07/2023 08:50, Adam Borowski wrote:

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:

  * Package name : libtypec
Version  : 0.3-1
  * URL  : https://github.com/Rajaram-Regupathy/libtypec



   libtypec1 - generic interface for efficient USB-C port management
   libtypec-dev - Development files for an interface for USB-C port management



  libtypec (0.3-1) unstable; urgency=low
  .
* Initial release (Closes: #1023477)
* Add patch 0001-fix-libtypec-so-version.patch to fix .so name version


Hi!
Before doing manual review, let's start with lintian:


Thanks, which lintian options did you use so I can santicy check my fixes?

Colin



E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Adam Borowski]

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:
>  * Package name : libtypec
>Version  : 0.3-1
>  * URL  : https://github.com/Rajaram-Regupathy/libtypec

>   libtypec1 - generic interface for efficient USB-C port management
>   libtypec-dev - Development files for an interface for USB-C port management

>  libtypec (0.3-1) unstable; urgency=low
>  .
>* Initial release (Closes: #1023477)
>* Add patch 0001-fix-libtypec-so-version.patch to fix .so name version

Hi!
Before doing manual review, let's start with lintian:

E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ A tit a day keeps the vet away.
⠈⠳⣄

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libtypec":

 * Package name : libtypec
   Version  : 0.3-1
   Upstream contact : Rajaram Regupathy 
 * URL  : https://github.com/Rajaram-Regupathy/libtypec
 * License  : MIT
 * Vcs  : [fill in URL of packaging vcs]
   Section  : utils

The source builds the following binary packages:

  libtypec1 - generic interface for efficient USB-C port management
  libtypec-dev - Development files for an interface for USB-C port 
management


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


  https://mentors.debian.net/package/libtypec/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libt/libtypec/libtypec_0.3-1.dsc


Changes for the initial release:

 libtypec (0.3-1) unstable; urgency=low
 .
   * Initial release (Closes: #1023477)
   * Add patch 0001-fix-libtypec-so-version.patch to fix .so name version

Regards,

Colin Ian King