Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library

2020-06-21 Thread Vasyl Gello
Hi Mattia!

Good to know you are back! Hope you are well :)

>Mhh, would you please instead consider joining it now, rather than move
>stuff around later?  I don't think I saw your joining mail in the last
>20 days (sorry for ghosting - I had some personal matters going on).

>Then, I notice that you are bumping the version while uploading to
>mentors.  In the end we shall only upload a -1 with only one changelog
>entry to the archive, so feel free to just remove and re-upload the -1
>version to mentors (IIRC you can also just re-upload the same version
>and it would overwrite it).

I fixed the versioning and maintainership of the package and re-uploaded
it cleanly as 1.0.0-1 targeting unstable (since I know now that experimental
is basically unstable + some NEW queue with breaking changes)

I will reopen this bug now & send an 'official' team join request.

Now, after I overhauled Kodi package (including copyrights)
and made it and all deps building and running on buster-bpo,
I think I am eligible to join :)
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library

2020-06-21 Thread Mattia Rizzolo
On Mon, Jun 01, 2020 at 01:39:10PM +, Vasyl Gello wrote:
> >* d/control:
> > + Vcs-* have to point to the packaging repository, not the upstream
> >   one.  Since this is something maintained by the multimedia team
> >   (according to Maintainer) it should have a repo within the multimedia
> >   team space.
> 
> Fixed by setting Maintainer to me until I get into the team. I have not even 
> raised
> the application intent yet.

Mhh, would you please instead consider joining it now, rather than move
stuff around later?  I don't think I saw your joining mail in the last
20 days (sorry for ghosting - I had some personal matters going on).

> >* libudfread-dev.install
> > + you are installing the .a file: do you really need it?  As a personal
> >   policy I try to remove static libraries rather than adding them…
> 
> I often link software statically, especially targeting Android.
> So I guess keeping static library won't hurt as part of -dev
> package.

I see that you removed it following pabs' suggestion.  Well, just know
that whilst I generally agree with him that static libraries are usually
just an old renmant and they should be avoided, I also consider them
alright if somebody really need them (as long as they are not used to
statically link stuff within the archive).


Then, I notice that you are bumping the version while uploading to
mentors.  In the end we shall only upload a -1 with only one changelog
entry to the archive, so feel free to just remove and re-upload the -1
version to mentors (IIRC you can also just re-upload the same version
and it would overwrite it).

-- 
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


Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library

2020-06-01 Thread Paul Wise
On Mon, 2020-06-01 at 14:18 +, Vasyl Gello wrote:

> So static libs present in packages like popt are remnants of the past
> and the general practice now is to discourage shipping all kinds of 
> static libraries unless it is Go/OCaml… as mentioned in this wiki
> page?

Right.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library

2020-06-01 Thread Vasyl Gello
Hi Paul!

So static libs present in packages like popt are remnants of the past
and the general practice now is to discourage shipping all kinds of 
static libraries unless it is Go/OCaml…  as mentioned in this wiki page?

I looked at it before, but I try understanding what is considered best 
practices now.
-- 
Vasyl Gello

June 1, 2020 1:57:09 PM UTC, Paul Wise  написав(-ла):
>On Mon, Jun 1, 2020 at 1:42 PM Vasyl Gello wrote:
>
>> I often link software statically, especially targeting Android.
>> So I guess keeping static library won't hurt as part of -dev
>> package.
>
>Where dynamic libraries are available there are usually only downsides
>to static libraries, in Debian we try to not distribute static
>libraries unless there is a good reason.
>
>https://wiki.debian.org/StaticLinking
>
>-- 
>bye,
>pabs
>
>https://wiki.debian.org/PaulWise


signature.asc
Description: PGP signature


Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library

2020-06-01 Thread Paul Wise
On Mon, Jun 1, 2020 at 1:42 PM Vasyl Gello wrote:

> I often link software statically, especially targeting Android.
> So I guess keeping static library won't hurt as part of -dev
> package.

Where dynamic libraries are available there are usually only downsides
to static libraries, in Debian we try to not distribute static
libraries unless there is a good reason.

https://wiki.debian.org/StaticLinking

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library

2020-06-01 Thread Vasyl Gello
>* d/control:
> + Vcs-* have to point to the packaging repository, not the upstream
>   one.  Since this is something maintained by the multimedia team
>   (according to Maintainer) it should have a repo within the multimedia
>   team space.

Fixed by setting Maintainer to me until I get into the team. I have not even 
raised
the application intent yet.

> + Homepage points to the upstream VCS: doesn't this project have a real
>   homepage?

Well, it is, but it is sometimes not accessible. Added it anyway.

> + Both descriptions are way way too short (1 line). please strive to
>   find at least 3 lines...
>* d/*.dirs
> + those two files are totally useless, get rid of them

Shot them dead ;)

>* libudfread-dev.install
> + you are installing the .a file: do you really need it?  As a personal
>   policy I try to remove static libraries rather than adding them…

I often link software statically, especially targeting Android.
So I guess keeping static library won't hurt as part of -dev
package.

>* d/changelog:
> + Please add the "Initial upload" words in there :)

Doen :)

>* d/rules:
> + since you are using dh compat 13, you can go and use
>   "execute_before_dh_installexamples" instead of the current override
> + you may prefer to add that .la file in d/not-installed instead of
>   overriding dh_missing that way (also relevant if you stop installing
>   the .a file).
>* d/copyright:

Good catch, thanks! Now I can keep not-installable things sane.

> + I see that debian/* has a different license than the rest of the
>   package.  Theoretically that might cause issue if for example sombody
>   writes a patch for debian, place it under the debian/* license (GPL2+
>   in this case).  That patch then it would taint the upstream license,
>   as combining code with LGPL2.1 and GPL2+ leads to something that is
>   only GPL2+, likely something that upstream wouldn't want.

> + furthermore, the project is not released under LGPL-2.1, but
>   LGPL-2.1+ ... please pay attention to these details

Yes, I double-checked their licenses and fixed d/copyright

> + in the copyright you wrote "2014-2020 VLC authors and VideoLAN", but
>   I can't find any year later than 2017.  Lastly, I see all files have
>   only one "Author:" listead in them, I'd find nice if you added at
>   least a Comment: line in that "Files: *" paragraph mentioning that
>   single author.

Done

> + you missed m4/attributes.m4 - please take note that that GPL-2+ file
>   has a special exception

Done

>* you uploaded a .asc file, but you have not provided either public
>  signing key in d/upstream/signing-key.asc nor set an appropriate pgp
>  option in d/watch.  Nor I can find any signature on the upstream
>  repository (note that I haven't tried to check the signature).  Where
>  is it coming from?

It was my signature as recommended in one of thousand Debian Wiki pages
I read. As you clarified in pr8vate, this was useless so I recreated repo and 
pushed
the fixed package to mentors queue.

Thanks for review! :)
-- 
Vasyl Gello

Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library

2020-06-01 Thread Mattia Rizzolo
Control: owner -1 !
Control: tag -1 moreinfo

On Sun, May 24, 2020 at 12:11:42PM +, Vasyl Gello wrote:
>   dget -x 
> https://mentors.debian.net/debian/pool/main/libu/libudfread/libudfread_1.0.0-1.dsc

* d/control:
 + Vcs-* have to point to the packaging repository, not the upstream
   one.  Since this is something maintained by the multimedia team
   (according to Maintainer) it should have a repo within the multimedia
   team space.
 + Homepage points to the upstream VCS: doesn't this project have a real
   homepage?
 + Both descriptions are way way too short (1 line). please strive to
   find at least 3 lines...
* d/*.dirs
 + those two files are totally useless, get rid of them
* libudfread-dev.install
 + you are installing the .a file: do you really need it?  As a personal
   policy I try to remove static libraries rather than adding them…
* d/changelog:
 + Please add the "Initial upload" words in there :)
* d/rules:
 + since you are using dh compat 13, you can go and use
   "execute_before_dh_installexamples" instead of the current override
 + you may prefer to add that .la file in d/not-installed instead of
   overriding dh_missing that way (also relevant if you stop installing
   the .a file).
* d/copyright:
 + I see that debian/* has a different license than the rest of the
   package.  Theoretically that might cause issue if for example sombody
   writes a patch for debian, place it under the debian/* license (GPL2+
   in this case).  That patch then it would taint the upstream license,
   as combining code with LGPL2.1 and GPL2+ leads to something that is
   only GPL2+, likely something that upstream wouldn't want.
 + furthermore, the project is not released under LGPL-2.1, but
   LGPL-2.1+ ... please pay attention to these details
 + in the copyright you wrote "2014-2020 VLC authors and VideoLAN", but
   I can't find any year later than 2017.  Lastly, I see all files have
   only one "Author:" listead in them, I'd find nice if you added at
   least a Comment: line in that "Files: *" paragraph mentioning that
   single author.
 + you missed m4/attributes.m4 - please take note that that GPL-2+ file
   has a special exception
* you uploaded a .asc file, but you have not provided either public
  signing key in d/upstream/signing-key.asc nor set an appropriate pgp
  option in d/watch.  Nor I can find any signature on the upstream
  repository (note that I haven't tried to check the signature).  Where
  is it coming from?


-- 
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


Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library

2020-05-24 Thread Vasyl Gello
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libudfread"

 * Package name: libudfread
   Version : 1.0.0-1
   Upstream Author : VideoLAN Project 
 * URL : https://code.videolan.org/videolan/libudfread
 * License : LGPL-2.1
 * Vcs : https://code.videolan.org/videolan/libudfread
   Section : libs

It builds those binary packages:

  libudfread0 - UDF reader library
  libudfread-dev - Development headers for UDF reader library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libu/libudfread/libudfread_1.0.0-1.dsc

Changes since the last upload:

   * Closes: 781399

Regards,
-- 
Vasyl Gello

signature.asc
Description: PGP signature