Bug#961996: RFS: uriparser/0.9.4+dfsg-1 -- URI parsing library compliant with RFC 3986
Control: tags -1 moreinfo On Mon, Jun 01, 2020 at 08:29:42PM +0200, Jörg Frings-Fürst wrote: >... > Changes since the last upload: >... > - New debian/not-installed: >+ Add all files of dh_missing errors. This would be followed by RFS: uriparser/0.9.4+dfsg-2 [RC] * Fix ftbfs with dh_missing >... > - Add +dsfg staff. stuff >... > CU > Jörg Frings-Fürst cu Adrian
Bug#961991: marked as done (RFS: libunistring/0.9.10-4 [RC] -- Unicode string library for C)
Your message dated Tue, 2 Jun 2020 07:47:18 +0300 with message-id <20200602044718.GA7231@localhost> and subject line Re: Bug#961991: RFS: libunistring/0.9.10-4 [RC] -- Unicode string library for C has caused the Debian Bug report #961991, regarding RFS: libunistring/0.9.10-4 [RC] -- Unicode string library for C to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 961991: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961991 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "libunistring" Package name: libunistring Version : 0.9.10-4 Upstream Author : Bruno Haible URL : https://www.gnu.org/software/libunistring/ License : LGPL-3+ or GPL-2+ Vcs : https://jff.email/cgit/libunistring.git Section : libs It builds those binary packages: libunistring-dev - Unicode string library for C - development files libunistring2 - Unicode string library for C To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libunistring Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libu/libunistring/libunistring_0.9.10-4.dsc or from git: https://jff.email/cgit/libunistring.git/?h=release%2Fdebian%2F0.9.10-4 Changes since the last upload: * Fix ftbfs with dh_missing (Closes: #961960). * debian/changelog: - Fix removed tag at 0.9.10-2. CU Jörg Frings-Fürst -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part --- End Message --- --- Begin Message --- On Mon, Jun 01, 2020 at 06:02:39PM +0200, Jörg Frings-Fürst wrote: >... > Changes since the last upload: > >* Fix ftbfs with dh_missing (Closes: #961960). >* debian/changelog: > - Fix removed tag at 0.9.10-2. Thanks, uploaded. > CU > Jörg Frings-Fürst cu Adrian--- End Message ---
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
Bug#962010: RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "ca-certificates" * Package name: ca-certificates Version : 20200601~deb9u1 * License : Mozilla Public License Version 2.0 * Vcs : https://salsa.debian.org/debian/ca-certificates Section : misc It builds those binary packages: ca-certificates - Common CA certificates ca-certificates-udeb - Common CA certificates - udeb To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ca-certificates Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200601~deb9u1.dsc Changes since the last upload: * Rebuild for stretch-security. * Merge changes from 20200601 - d/control * This security release updates the Mozilla CA bundle and blacklists distrusted Symantec roots and the expired AddTrust External Root. Regards, Michael Shuler
Bug#962009: RFS: ca-certificates/20200601~deb10u1 [RC] -- Common CA certificates
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "ca-certificates" * Package name: ca-certificates Version : 20200601~deb10u1 * License : Mozilla Public License Version 2.0 * Vcs : https://salsa.debian.org/debian/ca-certificates Section : misc It builds those binary packages: ca-certificates - Common CA certificates ca-certificates-udeb - Common CA certificates - udeb To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ca-certificates Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200601~deb10u1.dsc Changes since the last upload: * Rebuild for buster-security. * Merge changes from 20200601 - d/control; set d/gbp.conf branch to debian-buster * This security release updates the Mozilla CA bundle and blacklists distrusted Symantec roots and the expired AddTrust External Root. Regards, Michael Shuler
Bug#962008: RFS: ca-certificates/20200601 [RC] -- Common CA certificates
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "ca-certificates"
* Package name: ca-certificates
Version : 20200601
* License : Mozilla Public License Version 2.0
* Vcs : https://salsa.debian.org/debian/ca-certificates
Section : misc
It builds those binary packages:
ca-certificates - Common CA certificates
ca-certificates-udeb - Common CA certificates - udeb
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/ca-certificates
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200601.dsc
Changes since the last upload:
* debian/control:
Set Standards-Version: 4.5.0.2
Set Build-Depends: debhelper-compat (= 13)
* debian/copyright:
Replace tabs in license text
* mozilla/{certdata.txt,nssckbi.h}:
Update Mozilla certificate authority bundle to version 2.40.
Closes: #956411, #955038
* mozilla/blacklist.txt
Add distrusted Symantec CA list to blacklist for explicit removal.
Closes: #911289
Blacklist expired root certificate, "AddTrust External Root"
Closes: #961907
The following certificate authorities were added (+):
+ "Certigna Root CA"
+ "emSign ECC Root CA - C3"
+ "emSign ECC Root CA - G3"
+ "emSign Root CA - C1"
+ "emSign Root CA - G1"
+ "Entrust Root Certification Authority - G4"
+ "GTS Root R1"
+ "GTS Root R2"
+ "GTS Root R3"
+ "GTS Root R4"
+ "Hongkong Post Root CA 3"
+ "UCA Extended Validation Root"
+ "UCA Global G2 Root"
The following certificate authorities were removed (-):
- "AddTrust External Root"
- "Certinomis - Root CA"
- "Certplus Class 2 Primary CA"
- "Deutsche Telekom Root CA 2"
- "GeoTrust Global CA"
- "GeoTrust Primary Certification Authority"
- "GeoTrust Primary Certification Authority - G2"
- "GeoTrust Primary Certification Authority - G3"
- "GeoTrust Universal CA"
- "thawte Primary Root CA"
- "thawte Primary Root CA - G2"
- "thawte Primary Root CA - G3"
- "VeriSign Class 3 Public Primary Certification Authority - G4"
- "VeriSign Class 3 Public Primary Certification Authority - G5"
- "VeriSign Universal Root Certification Authority"
Regards,
Michael Shuler
Bug#961996: RFS: uriparser/0.9.4+dfsg-1 -- URI parsing library compliant with RFC 3986
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "uriparser" Package name: uriparser Version : 0.9.4+dfsg-1 Upstream Author : Sebastian Pipping URL : http://uriparser.sourceforge.net License : BSD-3-clause Vcs : https://jff.email/cgit/uriparser.git Section : libs It builds those binary packages: liburiparser1 - URI parsing library compliant with RFC 3986 liburiparser-dev - development files for uriparser liburiparser-doc - documentation files for uriparser To access further information about this package, please visit the following URL: https://mentors.debian.net/package/uriparser Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/uriparser/uriparser_0.9.4+dfsg-1.dsc or from git: https://jff.email/cgit/uriparser.git/?h=release%2Fdebian%2F0.9.4%2Bdfsg-1 Changes since the last upload: * New upstream release. - Refresh patch. - Refresh symbols file. * Declare compliance with Debian Policy 4.5.0 (No changes needed). * Migrate to debhelper-compat 13: - Remove debian/compat. - Bump minimum debhelper-compat version in debian/control to = 13. - New debian/not-installed: + Add all files of dh_missing errors. * Add suffix +dfsg to changelog version number to make lintian happy. * debian/watch: - Add +dsfg staff. * debian/control: - Add Rules-Requires-Root: no. * debian/copyright: - Add year 2020 to myself. CU Jörg Frings-Fürst -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/31/20 9:19 AM, Tobias Frost wrote: > On Sat, May 30, 2020 at 06:55:42PM +0200, Roland Plüss wrote: >> On 5/30/20 4:45 PM, Tobias Frost wrote: >>> I see those options: >>> - talk to the fox-1.6 maintainer about updating the package to 1.7. >>> (though I see that they generally stick to released versions and 1.7.* >>> seems >>> to be only development snapshots; a question to ask: is the 1.7 ABI >>> stable already?) >>> - make the features optional that requires 1.7 >>> - use only 1.6 features (listed for completeness, as you said you can't) > There is another option I've forgot to mention: > - Talk to the maintainers of 1.6 and work together with them to package > 1.7. Maybe Florian is happy to get you as (co-)maintainer the 1.7 > package, so you could offer that. > > It seems at first glance possible that both versions can be in Debian, > however, the release/security team will not be happy to have both of > them in a stable release, IOW, having two versions can only be a > intermediate solution until all reverse dependencies of 1.6* have been > updated (by patching the respective Debian packages.) More about such > library transision: > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > If you want to follow this route, your next step would be now to contact > the fox1.6 maintainer by filing a wishlist bug against src:fox1.6, asking > to package the version you need, explaining the situation and maybe (== > if you want) tell them that you would commit helping to offset the extra > work caused by maintaining the development snapshot. > > * dak spits out those r-deps: > ace: libfox-1.6-dev > gogglesmm: libfox-1.6-dev > libgwenhywfar: libfox-1.6-dev > pcsc-cyberjack: libfox-1.6-dev > sumo: libfox-1.6-dev > xfe: libfox-1.6-dev (>= 1.6.45) > FOX-1.7 and FOX-1.6 are not compatible (well, mostly yes but in important things not). That said they are different libraries with separate include and library names (/usr/include/fox-1.6 vs /usr/include/fox-1.7 and the same for libraries). So technically applications linking against FOX-1.6 do not have to be change if FOX-1.7 is added on the same system (the two can coexist). But it depends if two library versions of the same library are accepted even if they are disjoint. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961897: RFS: wifi-qr/0.1-1 [ITP] -- WiFi Share and Connect with QR
Thank you for the clarification. now finished. i also update with Rules-Requires-Root: no could you please check for me ? with regards On Mon, Jun 1, 2020 at 5:43 PM Kyle Robbertze wrote: > Control: tags -1 moreinfo > > Hi, > > On 2020/05/31 03:56, Ko Ko Ye` wrote: > > Package: sponsorship-requests > > Severity: wishlist > > > > Dear mentors, > > > > I am looking for a sponsor for my package "wifi-qr" > > I have reviewed the package. The upstream repo doesn't contain a top > level licence (only what is in debian/copyright). Also the changelog > closes this RFS and not an ITP bug. If you opened an ITP bug, then that > should be closed, otherwise the (Closes: #n) part should be removed. > > Cheers > Kyle > > -- > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze > ⢿⡄⠘⠷⠚⠋⠀ Debian Developer > ⠈⠳⣄ https://wiki.debian.org/KyleRobbertze > -- with regards *Ko Ko Ye`* +95 97989 22022 +95 94500 22022 +95 9731 47907 kokoye2...@gmail.com kokoye2...@ubuntu.com skype: kokoye2007 jitsi: kokoye2007 http://ubuntu-mm.net http://wiki.ubuntu.com/kokoye2007 http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
Bug#961991: RFS: libunistring/0.9.10-4 [RC] -- Unicode string library for C
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "libunistring" Package name: libunistring Version : 0.9.10-4 Upstream Author : Bruno Haible URL : https://www.gnu.org/software/libunistring/ License : LGPL-3+ or GPL-2+ Vcs : https://jff.email/cgit/libunistring.git Section : libs It builds those binary packages: libunistring-dev - Unicode string library for C - development files libunistring2 - Unicode string library for C To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libunistring Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libu/libunistring/libunistring_0.9.10-4.dsc or from git: https://jff.email/cgit/libunistring.git/?h=release%2Fdebian%2F0.9.10-4 Changes since the last upload: * Fix ftbfs with dh_missing (Closes: #961960). * debian/changelog: - Fix removed tag at 0.9.10-2. CU Jörg Frings-Fürst -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
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#961919: RFS: shairplay/1.0-1 [ITP] -- AirPort Express server emulator.
Hi Mattia! >* d/control: > + vcs is set to your private space, but the package is team maintained Fixed to myself as maintainer, same as other package. > + why did you decide to use "shairplay-bin" instead of just > "shairplay"? I thought source and binary packages of the same name would confuse ftp archive. So I followed the "kodi-bin" path first. Seems I was wrong in my doubts as mentors queue chewed the fixed release just fine! > + drop the full stops from the synopsis (lintian flags this, didn't you > see it?) Done. >* d/changelog: > + it's not closing an ITP Done. >* d/libshairplay-dev.install: > + same as the other pacakge regarding the .a file. Keeping the .a files as explained in the other package ;) >* d/shairplay-bin.install: > + imho, you could just reduce the line length with "usr/bin" and > "usr/share/man" without specifying the single files, since there is > no risk here to pick up stuff from other binary packages accidentally Yes, makes sense. Fixed. (doing same with libs screwed up installer, so as a rule of thumb I'll try being verbose where needed) >* d/rules: > + beware of what that dh_installdocs call you did actually do. I > believe you don't want that. hint: check the package contents. Removed that as now we have manpage. > + you are -X'ing the .la file in dh_install? is that really needed? > + same as the other package regarding dh_missing. Fixed by putting .la into d/not-installed. >* d/patches: > + did you forward them? if you did please add some headers following > DEP-3. The upstream is not maintained + basically the patches fix Debian build. I set them to "not-needed". >* d/watch: > + since now uscan supports scanning bare git repositories, I think you > should add a watchfile novertheless Best catch for today! :) Especially after I crafted the config which can repack stuff from the git HEAD :) >Incidentally, the git repository and what you uploaded to mentors are >slightly different: > >|--- shairplay-0.9.0+git20180824/debian/control 2020-05-31 02:00:00.0 >+0200 >|+++ shairplay-0.9.0+git20180824/debian/control 2020-05-31 02:00:00.0 >+0200 >|@@ -34,7 +34,7 @@ >| . >| Currently only AirPort Express emulation is supported. >| . >|- This package installs the shairplay server executable >|+ This package installs the shairplay server executable. >| >| Package: libshairplay-dev >| Architecture: any > I re-created the repo again to match the uscan-retrieved and repacked tars and pushed the new iteration of pacjage to mentors queue. > > >NOTE: I haven't reviewd the copyright yet. > I revised it and removed parts we don't use (AirTV-Qt). There was both licensing mess and Qt incompatibilities so I just added that folder to Files-Excluded section in d/copyright and re-uscan-ed the source :) I also added files not covered by narrower scopes (*, like .gitignore, makefile.am, configure.ac) as LGPL-2.1+ same as Debian patch. Hope it is corect approach given the LICENSE file of upstream does never mention these files. -- Vasyl Gello
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#961905: RFS: sane-backends/1.0.30-1~experimental2 -- API library for scanners -- utilities
Hello Adam, Am Montag, den 01.06.2020, 00:50 +0200 schrieb Adam Borowski: > On Sun, May 31, 2020 at 09:48:19AM +0200, Jörg Frings-Fürst wrote: > >Package name: sane-backends > >Version : 1.0.30-1~experimental2 > > Changes since the last upload: > > > >* debian/not-installed: > > - Add usr/share/doc/libsane/backend-writing.txt. > >* debian/libsane1.symbols: > > - Add (arch=!hurd-i386) to cmsg@Base. > > Hi! > Since it's experimental, I've uploaded as-is, but moving the .so links from > libsane1 to libsane-dev means both of us will need to check how upgrades > from stable/unstable to the version in experimental go. > Many thanks for your review und upload my packages. As I read your comment about the .so links I first asked myself what mistake I made again. But the .so links are installed into libsane-dev since version 1.0.22-7 (My first version of which I still have the debian/ archive). The I take a look into [1]. "the libgdbm-dev package should include a symlink from /usr/lib/libgdbm.so to libgdbm.so.3.0.0.". So I think thats the libsane-dev package is the right place for the *.so symlinks. Or has something changed? > (The package libsane1 doesn't exist outside experimental.) > That's why I requested a transition[2]. But then the security update to version 1.0.30 came at short notice. I considered this as so important that I took it over before. > > Meow! CU Jörg [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#development-files [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960046 -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#961897: RFS: wifi-qr/0.1-1 [ITP] -- WiFi Share and Connect with QR
Control: tags -1 moreinfo Hi, On 2020/05/31 03:56, Ko Ko Ye` wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "wifi-qr" I have reviewed the package. The upstream repo doesn't contain a top level licence (only what is in debian/copyright). Also the changelog closes this RFS and not an ITP bug. If you opened an ITP bug, then that should be closed, otherwise the (Closes: #n) part should be removed. Cheers Kyle -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄ https://wiki.debian.org/KyleRobbertze
Bug#961919: RFS: shairplay/1.0-1 [ITP] -- AirPort Express server emulator.
Control: owner -1 ! Control: tag -1 moreinfo On Sun, May 31, 2020 at 02:33:33PM +, Vasyl Gello wrote: > dget -x > https://mentors.debian.net/debian/pool/main/s/shairplay/shairplay_0.9.0+git20180824-1.dsc * d/control: + vcs is set to your private space, but the package is team maintained + why did you decide to use "shairplay-bin" instead of just "shairplay"? + drop the full stops from the synopsis (lintian flags this, didn't you see it?) * d/changelog: + it's not closing an ITP * d/libshairplay-dev.install: + same as the other pacakge regarding the .a file. * d/shairplay-bin.install: + imho, you could just reduce the line length with "usr/bin" and "usr/share/man" without specifying the single files, since there is no risk here to pick up stuff from other binary packages accidentally * d/rules: + beware of what that dh_installdocs call you did actually do. I believe you don't want that. hint: check the package contents. + you are -X'ing the .la file in dh_install? is that really needed? + same as the other package regarding dh_missing. * d/patches: + did you forward them? if you did please add some headers following DEP-3. * d/watch: + since now uscan supports scanning bare git repositories, I think you should add a watchfile novertheless Incidentally, the git repository and what you uploaded to mentors are slightly different: |--- shairplay-0.9.0+git20180824/debian/control 2020-05-31 02:00:00.0 +0200 |+++ shairplay-0.9.0+git20180824/debian/control 2020-05-31 02:00:00.0 +0200 |@@ -34,7 +34,7 @@ | . | Currently only AirPort Express emulation is supported. | . |- This package installs the shairplay server executable |+ This package installs the shairplay server executable. | | Package: libshairplay-dev | Architecture: any :P NOTE: I haven't reviewd the copyright yet. -- 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
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
