Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
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
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
Re: Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
On Mon, Jun 1, 2020 at 3:04 PM The Wanderer wrote: > If I need to compile a program to run in an environment where I can't > know what libraries / library versions are going to be available, or > maybe even do know for a fact that certain ones will not be available, > the obvious solution is to link it statically Do you have any examples of environments where you would ship Debian derived static binaries? AFAICT, outside the language communities where dynamic linking is either impractical (due to ABI instability or other issues) or not available, static linking has been replaced by things like Docker/AppImage/Flatpak. Usually static linking isn't enough anyway, since there are almost always files that aren't libraries that you want to bundle with your application. Docker/AppImage/Flatpak allow this extra bundling. Also, people tend to vendor code instead of static linking distro static libs. Indeed, there is a general trend away from distros. Also, ISTR there is something about glibc nss not working in static binaries? > - but if Debian doesn't ship the static libraries > how exactly am I supposed to do that in Debian? Either rebuild or request addition of the static lib to the package(s) needed. > Can you point me to a reference for the statement that it is now general > practice to discourage shipping of static libraries (as distinct from > statically-linked executables) in Debian packages? Its more of a trend I have noticed in both discussions and packages than a specific policy. For example there are a lot more libraries that can be linked dynamically than statically: $ apt-file search -x '/usr/lib/.*\.a$' | wc -l 15655 $ apt-file search -x '/usr/lib/.*\.so$' | wc -l 43682 Some packages explicitly enable static libs but a few more explicitly disable them: https://codesearch.debian.net/search?q=path%3Adebian%2Frules+enable-static=0 https://codesearch.debian.net/search?q=path%3Adebian%2Frules+disable-static=0 Probably some of that is a 2015 change I made to dh-make that disables them by default: https://salsa.debian.org/debian/dh-make/commit/2fdc171c5b0a5eb1df33dd3c64f8be83650cadaa -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
On 2020-06-01 at 10:35, Paul Wise wrote: > 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. That seems like a questionable decision. If I need to compile a program to run in an environment where I can't know what libraries / library versions are going to be available, or maybe even do know for a fact that certain ones will not be available, the obvious solution is to link it statically - but if Debian doesn't ship the static libraries, how exactly am I supposed to do that in Debian? Not linking programs statically by default is certainly a good idea, as is not shipping statically-linked programs in Debian packages without specific cause to do so (as cited on that Wiki page) - but not shipping static libraries just means that someone who *does* have a legitimate reason to use static linking in a particular case will have to compile the entire library stack necessary by hand, which seems like a suboptimal solution at best. Fortunately, there still seem to be thousands of packages which do ship static libraries, even excluding all packages whose names reference go or ocaml: $ apt-file -x search '\.a$' | cut -d ':' -f 1 | sort -u | grep -v '\bgo\b' | grep -v ocaml | wc -l 5524 If this "discourage shipping static libraries" policy is in fact in place, it seems to either be de-facto ignored in practice, or new enough that there are still lots of packages which haven't been affected. In fact, I don't see anything in that StaticLinking Wiki page which indicates that static libraries should not be shipped, and the relevant section of Debian Policy to which it links [1] states that "the static library is usually provided in addition to the shared library". Can you point me to a reference for the statement that it is now general practice to discourage shipping of static libraries (as distinct from statically-linked executables) in Debian packages? [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
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
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
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
>* 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
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
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
