Re: request for upload of new version of library following soname change
On Wed, Oct 28, 2020 at 07:39:31PM -0400, Nick Black wrote: > Andrey Rahmatullin left as an exercise for the reader: > > On Tue, Oct 27, 2020 at 04:38:35PM -0400, Nick Black wrote: > > > I maintain the notcurses package, which is already in the > > > archive. Recently, the soname changed, necessitating a new > > > package name (libnotcurses1 -> libnotcurses2). I understand this > > > needs go through NEW, but alas, I've been unable to reach my > > > previous uploader for over a week (please don't interpret this > > > as a knock on their volunteer efforts, which are very much > > > appreciated). I'd appreciate some DD taking mercy and uploading > > > to NEW for FTPMaster review. > > If this package has reverse dependencies, you shouldn't just directly > > upload it to unstable, you need to make a transition. > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > it does not, Well, dak tellms me, it _has_ a reverse dependency: Checking reverse dependencies... # Broken Depends: snd: snd-nox # Broken Build-Depends: snd: libnotcurses-dev Even if it is only one package, its still a transition. I anyway recommend _always_ going throug experimental, as this is the safe way. And it won't save you an upload: It has to go through NEW and therefore you need an binary upload. To be able that it will got to testing later, you need to do an addtional source-only upload. This fixes also corner cases where you are unaware of an R-Depends, because of race conditions etc. (new packages, new upstream versions starting to use it…) > save the package currently up on mentors (and not > being uploaded until this transition is complete, as it depends > on behavior following the abi bump). As you've declared the B-D on the new version, the builldds wont build it until the new version is in the archives, so there shouldnt be a problem. (I think you talk about growlight) > -- > nick black -=- https://www.nick-black.com > to make an apple pie from scratch, > you need first invent a universe.
Re: lintian question - no-debian-changes
On Wed, Oct 28, 2020 at 11:30 PM Lajos Veres wrote: > Do I understand well that practically the debian folder should have to > disappear from the orig.tar.gz? > Is this what the check verifies? Correct. > I am wondering to move the debian folder to a dedicated github > repository to have it version tracked. Or is there any more Debian > friendly place for these debian packaging repositories? If you prefer the current situation, feel free to use a native package or keep the package as-is, lintian is a provider of friendly packaging advice rather than something that must be followed. If you decide to split the debian/ dir, you could also keep it on github but not in the orig.tar.gz, either by filtering the tarball created by github using the Files-Excluded feature of uscan/mk-origtargz, or by storing the debian/ dir on a separate branch or separate repo. Otherwise, Salsa is a popular place for storing Debian package git repos: https://wiki.debian.org/Salsa -- bye, pabs https://wiki.debian.org/PaulWise
Re: request for upload of new version of library following soname change
Andrey Rahmatullin left as an exercise for the reader: > On Tue, Oct 27, 2020 at 04:38:35PM -0400, Nick Black wrote: > > I maintain the notcurses package, which is already in the > > archive. Recently, the soname changed, necessitating a new > > package name (libnotcurses1 -> libnotcurses2). I understand this > > needs go through NEW, but alas, I've been unable to reach my > > previous uploader for over a week (please don't interpret this > > as a knock on their volunteer efforts, which are very much > > appreciated). I'd appreciate some DD taking mercy and uploading > > to NEW for FTPMaster review. > If this package has reverse dependencies, you shouldn't just directly > upload it to unstable, you need to make a transition. > https://wiki.debian.org/Teams/ReleaseTeam/Transitions it does not, save the package currently up on mentors (and not being uploaded until this transition is complete, as it depends on behavior following the abi bump). -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
lintian question - no-debian-changes
Hi, I am planning to clean my package's lintian records, but I am not too sure how to tackle this one: https://lintian.debian.org/tags/no-debian-changes.html > Debian packaging is sometimes maintained as part of upstream, but that is > not recommended as best practice. Please make this package native, if the > software is only for Debian. Otherwise, please remove the debian directory > from upstream releases and add it in the Debian packaging. The package is quite simple and its debian packaging is maintained with the upstream source to keep everything simple. But I guess this has to change and since the package is not Debian only, the second option looks like the only real one. https://packages.debian.org/sid/main/misspell-fixer Do I understand well that practically the debian folder should have to disappear from the orig.tar.gz? Is this what the check verifies? I am wondering to move the debian folder to a dedicated github repository to have it version tracked. Or is there any more Debian friendly place for these debian packaging repositories? Thank you! Best regards. Lajos -- Lajos Veres vlajos+deb...@gmail.com
Re: Copyright review for salsa project debian/gensio
Marc Haber left as an exercise for the reader: > I don't have an overview about the tooling that is currently available > to check the licenses of code in a source package. I would appreciate > any pointers to tools that could help double-check debian/copyright to > avoid wasting ftpmaster's time a second time and to get embarrassed a > second time. I somebody wants to manually check, I would appreciate that > as well. I believe "licensecheck" to be the canonical tool for this kind of thing. LICENSECHECK(1p) User Contributed Perl Documentation NAME licensecheck - simple license checker for source files -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Copyright review for salsa project debian/gensio
Hi, I have just finished rewriting a nearly 300 lines long debian/copyright file after an embarrassing ftpmaster-reject for a package that I thought was simple. The salsa project is https://salsa.debian.org/debian/gensio I don't want to call it a license mess, but I have counted six different licenses, GPL-2, GPL-2+, GPL-2 with OpenSSL Exception, Apache you name it, and a bunch of dedicated stanzas in debian/copyright because of year differences in the copyright statements in the respective files. I don't have an overview about the tooling that is currently available to check the licenses of code in a source package. I would appreciate any pointers to tools that could help double-check debian/copyright to avoid wasting ftpmaster's time a second time and to get embarrassed a second time. I somebody wants to manually check, I would appreciate that as well. Thanks in advance for helping. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#973320: RFS: lilo/1:24.2-5.1 [NMU] [RC] -- LInux LOader - the classic OS boot loader
Package: sponsorship-requests Severity: important Dear mentors, [RFS: This NMU fixes a GCC-10 ftbfs (#957490) which has kept lilo out of testing since August.] I am looking for a sponsor for my package "lilo": * Package name: lilo Version : 1:24.2-5.1 Upstream Author : Joachim Wiedorn * URL : http://lilo.joonet.de/ * License : BSD-3-clause, GPL-2+ * Vcs : https://salsa.debian.org/joowie-guest/maintain_lilo.git Section : admin It builds those binary packages: lilo-doc - LInux LOader - Documentation for the classic OS boot loader lilo - LInux LOader - the classic OS boot loader To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lilo/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lilo/lilo_24.2-5.1.dsc Changes since the last upload: lilo (1:24.2-5.1) unstable; urgency=medium . * Non-maintainer upload. * Fix ftbfs with GCC-10. (Closes: #957490) Regards, -- Ryan Finnie signature.asc Description: OpenPGP digital signature
Bug#973319: RFS: puzzle-jigsaw/1.0.2+git20201007.527c529+dfsg-2 -- tile puzzle game
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "puzzle-jigsaw": * Package name: puzzle-jigsaw Version : 1.0.2+git20201007.527c529+dfsg-2 Upstream Author : https://bitbucket.org/admsasha/puzzle-jigsaw/issues/new * URL : https://bitbucket.org/admsasha/puzzle-jigsaw * License : CC0-1.0, MIT, GPL-3+ * Vcs : https://salsa.debian.org/debian/puzzle-jigsaw Section : games It builds those binary packages: puzzle-jigsaw - tile puzzle game To access further information about this package, please visit the following URL: https://mentors.debian.net/package/puzzle-jigsaw/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/puzzle-jigsaw/puzzle-jigsaw_1.0.2+git20201007.527c529+dfsg-2.dsc Changes since the last upload: puzzle-jigsaw (1.0.2+git20201007.527c529+dfsg-2) unstable; urgency=medium . * Upload to unstable. Regards, -- ⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich ⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683 ⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E ⠈⠳⣄ GPG:rsa4096/7EF63B2E signature.asc Description: OpenPGP digital signature
Re: Verify the library transition
On Wed, Oct 28, 2020 at 3:47 AM Andrey Rahmatullin wrote: > On Sat, Oct 17, 2020 at 3:27 PM Tong Sun > wrote: > > ... looking further into all those libgit2 related > > packages that I've already built, I saw mixed results: > > > > - > > $ dpkg-deb -f gir1.2-ggit-1.0_0.28.0.1-2_amd64.deb Depends > > gir1.2-glib-2.0, libgit2-glib-1.0-0 (>= 0.28.0.1) > > > > $ dpkg-deb -f golang-gopkg-libgit2-git2go.v28-dev_0.28.5-1_all.deb Depends > > pkg-config, libgit2-dev (>> 0.28~) > > > > $ dpkg-deb -f libgit2-glib-1.0-0-dbgsym_0.28.0.1-2_amd64.deb Depends > > libgit2-glib-1.0-0 (= 0.28.0.1-2) > > > > $ dpkg-deb -f libgit2-glib-1.0-0_0.28.0.1-2_amd64.deb Depends > > libc6 (>= 2.14), libgit2-28 (>= 0.28.1), libglib2.0-0 (>= 2.44.0) > > > > $ dpkg-deb -f libgit2-glib-1.0-dev_0.28.0.1-2_amd64.deb Depends > > gir1.2-ggit-1.0 (= 0.28.0.1-2), libgit2-glib-1.0-0 (= 0.28.0.1-2), > > libgit2-dev (>= 0.26.0), libglib2.0-dev (>= 2.44.0) > > > > $ dpkg-deb -f librust-libgit2-sys+https-dev_0.10.0-1_amd64.deb Depends > > librust-libgit2-sys-dev (= 0.10.0-1), librust-openssl-sys-0.9+default-dev > > > > $ dpkg-deb -f librust-libgit2-sys+libssh2-sys-dev_0.10.0-1_amd64.deb Depends > > librust-libgit2-sys-dev (= 0.10.0-1), > > librust-libssh2-sys-0.2+default-dev (>= 0.2.11-~~) > > > > $ dpkg-deb -f librust-libgit2-sys-dev_0.10.0-1_amd64.deb Depends > > librust-cc-1+default-dev (>= 1.0.42-~~), librust-cc-1+parallel-dev (>= > > 1.0.42-~~), librust-libc-0.2+default-dev, > > librust-libz-sys-1+default-dev (>= 1.0.22-~~), > > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~), libgit2-dev > > - > > > > I.e., > > > > - some of them about built with libgit2-glib-1.0-0 > > - but some others are built with libgit2-28 (>= 0.28.1) > > - and some I just literally don't know, e.g., libgit2-dev (>> 0.28~) > > > > I.e., I still haven't figured out how to control the lib a package > > should links to. > (it installed the -dev package from sid because you didn't add a version > constraint to require the version from experimental) Ok, to add a version constraint, is it OK that I use the following to replace all libgit2 dependents from above, to make sure they require the version from experimental (v1.0.0)? libgit2-dev (>> 0.99) > > PS, here are all libgit2 related packages installed in my system, and > > their versions: > > > > libgit2-1.0:amd64_1.0.0+dfsg.1-1 > > libgit2-28:amd64_0.28.5+dfsg.1-1 > > libgit2-build-deps_1.0.0+dfsg.1-1 > > libgit2-dev:amd64_0.28.5+dfsg.1-1 > > libgit2-glib-1.0-0:amd64_0.28.0.1-2 > > libgit2-glib-1.0-dev:amd64_0.28.0.1-2 Moverover, give my specific case, - single lib upgrade, and - I've already installed the latest libgit2-1.0 into my sid would it matter any more if I build in my sid host? I know building with sbuild + experimental build-dep is ideal, but I can't think of any reason why I can't do build in my sid host now, if I am to update the dependent version constraints to all that package I'm building. thanks
Bug#973314: RFS: hydrapaper/2.0.2-1 -- Utility that sets background independently for each monitor
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "hydrapaper": * Package name: hydrapaper Version : 2.0.2-1 Upstream Author : Gabriele Musco * URL : https://gitlab.com/gabmus/HydraPaper * License : GPL-3+ * Vcs : https://salsa.debian.org/fmneto-guest/hydrapaper Section : graphics It builds those binary packages: hydrapaper - Utility that sets background independently for each monitor To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hydrapaper/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hydrapaper/hydrapaper_2.0.2-1.dsc Changes since the last upload: hydrapaper (2.0.2-1) unstable; urgency=medium . * New upstream version. * debian/clean: created file to force manpage cleanup. Regards, -- []'s, Francisco M Neto www.fmneto.com 3E58 1655 9A3D 5D78 9F90 CFF1 D30B 1694 D692 FBF0 0xD30B1694D692FBF0.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Bug#973307: RFS: nsd/4.3.3-1 -- authoritative domain name server
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "nsd": * Package name: nsd Version : 4.3.3-1 Upstream Author : nsd-us...@nlnetlabs.nl * URL : https://www.nlnetlabs.nl/projects/nsd/about/ * License : NSD-BSD-like, public-domain, MIT, BSD-2-clause * Vcs : https://salsa.debian.org/dns-team/nsd Section : net It builds those binary packages: nsd - authoritative domain name server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/nsd/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/nsd/nsd_4.3.3-1.dsc Changes since the last upload: nsd (4.3.3-1) unstable; urgency=medium . * New upstream version 4.3.3 * Run systemd service without creating pidfile Regards, Markus
Re: Verify the library transition
On Tue, Oct 27, 2020 at 11:21:57PM -0400, Tong Sun wrote: > So I build with experimental build-dep via: > > sbuild -s -v -A --no-clean-source -d unstable --extra-repository='deb > http://deb.debian.org/debian experimental main' > --build-dep-resolver=aspcud gnuastro (it installed the -dev package from sid because you didn't add a version constraint to require the version from experimental) -- WBR, wRAR signature.asc Description: PGP signature
Re: request for upload of new version of library following soname change
On Tue, Oct 27, 2020 at 04:38:35PM -0400, Nick Black wrote: > I maintain the notcurses package, which is already in the > archive. Recently, the soname changed, necessitating a new > package name (libnotcurses1 -> libnotcurses2). I understand this > needs go through NEW, but alas, I've been unable to reach my > previous uploader for over a week (please don't interpret this > as a knock on their volunteer efforts, which are very much > appreciated). I'd appreciate some DD taking mercy and uploading > to NEW for FTPMaster review. If this package has reverse dependencies, you shouldn't just directly upload it to unstable, you need to make a transition. https://wiki.debian.org/Teams/ReleaseTeam/Transitions -- WBR, wRAR signature.asc Description: PGP signature
Re: request for upload of new version of library following soname change
Hi Nick, On Tue, Oct 27, 2020 at 04:38:35PM -0400, Nick Black wrote: > Hey there. > > I maintain the notcurses package, which is already in the > archive. Recently, the soname changed, necessitating a new > package name (libnotcurses1 -> libnotcurses2). I understand this > needs go through NEW, but alas, I've been unable to reach my > previous uploader for over a week (please don't interpret this > as a knock on their volunteer efforts, which are very much > appreciated). I'd appreciate some DD taking mercy and uploading > to NEW for FTPMaster review. > > I haven't uploaded to mentors, but I certainly can if that's > desirable. Source, architecture-all, and amd64 packages are > available from https://www.dsscaw.com/repos/apt/debian/pool/main/n/notcurses/. > See postscript for reprepro output. > > The source package link is: IMHO, probably best would be to put it on mentors (as a bonus mentors does already a few checks which are useful for the reviewer) and open up an RFS bug for better visibility. (e.g it's my policy only to sponsor from there, as I believe other people will also learn/benefit from the process) > https://www.dsscaw.com/repos/apt/debian/pool/main/n/notcurses/notcurses_2.0.2+dfsg.1-1.dsc I did a short look at your package, so this is not a complete review: I notices those two problems by diffing with what is in the archives - It seems you did not include the changelog for (1.7.6+dfsg.1-2) - For A library transition upload you must target experimental in the first upload. Please read this link carefully for the procedure: https://wiki.debian.org/Teams/ReleaseTeam/Transitions -- Cheers, tobi
