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
Re: Verify the library transition
> > I'm currently helping with the library transition for libgit2-dev. > Then I would expect you to ask the maintainers for coordination and/or > help. The maintainer normally actively participates in the discussion here, and gives people help, but he is super busy at the moment, so I just want to go as furthest as possible without waiting on him. Moreover, the discussions so far are only on the library transition building general information, and has not much to do with his specific package. I.e., the discussions will be helpful to the next library transition building volunteers. > > > But I'd only been using sbuild to build sid packages previously, where > > > can I find the doc on how to add an experimental build-dep to sbuild's > > > build process? > > https://wiki.debian.org/sbuild#Enabling_experimental > > Greate. Thanks for all your helps! 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 and when I check my results, I got: $ dpkg-deb -f libgnuastro11_0.13-1_amd64.deb Depends libc6 (>= 2.29), libcfitsio9 (>= 3.480~), libgit2-28 (>= 0.26.0), libgsl25 (>= 2.6), libjpeg62-turbo (>= 1.3.1), libtiff5 (>= 4.0.3), libwcs7 (>= 5.0) Although the build passed, I'm still not sure if it passed for the new libgit2-glib-1.0-0, or if it passed for the old libgit2-28 (>= 0.28.1). Looks to me it is the latter. So now I have to come back to the old question > > - 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. > You don't need to "control" it. The build process uses the files from the > -dev package and usually there is only on version of that installed. So I'm not controlling it and let the build process choose on its own. Now, with the above result, can I safely say that libgnuastro11_0.13-1_amd64.deb is safe to build with the new libgit2? PS, the whole build log is at https://pastebin.com/YM9jV7g5 thanks
Bug#962294: marked as done (RFS: btrfs-progs/5.7-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities)
"Debian Bug Tracking System" writes: > Your message dated Wed, 21 Oct 2020 14:20:47 +0200 > with message-id <4ce39769-f1c3-68ad-3965-688d1f6c0...@debian.org> > and subject line Re: Bug#962294: RFS: btrfs-progs/5.7-1~bpo10+1 -- > Checksumming Copy on Write Filesystem utilities > has caused the Debian Bug report #962294, > regarding RFS: btrfs-progs/5.7-1~bpo10+1 -- Checksumming Copy on Write > Filesystem utilities > to be marked as done. > Thank you Gianfranco, much appreciated! A number of our users on upstream linux-btrfs have been recommended Fedora live media as the easiest way to get a recent version of 'btrfs check' (fsck equivalent for fs structures and metadata), so it's good to have an in-house solution again. Best, Nicholas signature.asc Description: PGP signature
request for upload of new version of library following soname change
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: https://www.dsscaw.com/repos/apt/debian/pool/main/n/notcurses/notcurses_2.0.2+dfsg.1-1.dsc The packaging is in Salsa, and was just now successfully rebuilt without any lintian exceptions: https://salsa.debian.org/debian/notcurses/-/pipelines/191174 There were no major changes in terms of content between the current packaged version (1.7.6) and this one (2.0.2). All code changes were made by one of three people, all of whom are listed in debian/copyright. My apologies if this mail is at all contrary to best practice. I just hope to bring Debian up-to-date wrt this package, and to unblock https://mentors.debian.net/package/growlight/. --nick reprepro: [vps](0) $ reprepro -b /opt/dsscaw/repos/apt/debian/ listmatched unstable \*notcurses\* unstable|main|amd64: libnotcurses++-dev 2.0.2+dfsg.1-1 unstable|main|amd64: libnotcurses++2 2.0.2+dfsg.1-1 unstable|main|amd64: libnotcurses++2-dbgsym 2.0.2+dfsg.1-1 unstable|main|amd64: libnotcurses-dev 2.0.2+dfsg.1-1 unstable|main|amd64: libnotcurses2 2.0.2+dfsg.1-1 unstable|main|amd64: libnotcurses2-dbgsym 2.0.2+dfsg.1-1 unstable|main|amd64: notcurses-bin 2.0.2+dfsg.1-1 unstable|main|amd64: notcurses-bin-dbgsym 2.0.2+dfsg.1-1 unstable|main|amd64: notcurses-data 2.0.2+dfsg.1-1 unstable|main|amd64: python3-notcurses 2.0.2+dfsg.1-1 unstable|main|amd64: python3-notcurses-dbgsym 2.0.2+dfsg.1-1 unstable|main|source: notcurses 2.0.2+dfsg.1-1 [vps](0) $ -- 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
Re: Salsa upstream update
Hello list, halfdog writes: > ... > Could someone please give me a hint how to update a Salsa project > to current upstream? > > I try to follow > > https://wiki.debian.org/Diaspora/Packaging/UpdateUpstream > > but it seems, that there is no upstream branch for "gbp > import-orig". Therfore I believe I should follow > > https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.convert.html > > which recommends > > git branch upstream $(git log --format='%H' | tail -1) > > when the first Salsa commit is identical to the upstream commit > (it is and has ID 40ec386c55a619f401ba92f592f78b65d009d7e1). > > Still import-orig is unhappy afterwards. > > Is there something obvious wrong or is the github upstream > in an invalid state so that importing cannot work? > > > Commands used: > > gbp clone --pristine-tar --debian-branch=debian/sid > https://salsa.debian.org/halfdog-guest/guerillabackup.git cd > guerillabackup git branch upstream > 40ec386c55a619f401ba92f592f78b65d009d7e1 git branch --all gbp > import-orig --pristine-tar --uscan --verbose > > gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', > 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', > '--git-dir'] gbp:debug: ['git', 'for-each-ref', > '--format=%(refname:short)', 'refs/heads/'] gbp:debug: ['git', > 'show-ref', '--verify', 'refs/heads/upstream'] gbp:debug: ['git', > 'status', '--porcelain'] gbp:info: Launching uscan... gbp:error: > Uscan failed - debug by running 'uscan --verbose' > > > > Also trying something like this does not help: > > git remote add upstream > https://github.com/halfdog/guerillabackup.git git fetch upstream > gbp import-orig --pristine-tar --upstream-branch upstream/master > --uscan ... > > > Any ideas? I think I found the solution by myself, at least it makes "gbp buildpackage" build the package. Could anybody please confirm that those steps are the Debian way to do it? The commands should run on any machine without the need to have any access credentials, ... gbp clone --pristine-tar --debian-branch=debian/sid https://salsa.debian.org/halfdog-guest/guerillabackup.git cd guerillabackup git config user.email "[your-mail]" git config user.name "[your-name]" git branch upstream 40ec386c55a619f401ba92f592f78b65d009d7e1 git remote add --fetch -t master upstream https://github.com/halfdog/guerillabackup.git git merge --strategy=recursive --strategy-option=theirs v0.0.2 After this automatic merge/merge-commit, some manual changes have to be done to follow upstream: * Fix merge error in "src/TransferService" line 89, delete 5 duplicated lines due to unexpected git-merge result from above. * Edit "debian/changelog" and bump version to "v0.0.2-1". * Copy "data/debian.template/guerillabackup.install" to "debian/guerillabackup.install" to account for deleted "Changelog.txt" * Edit "debian/patches/01-systemd-documentation" and remove patch for "guerillabackup-transfer.service" (already done upstream). * Edit "debian/upstream/metadata" to have new "Changelog:" reference "https://raw.githubusercontent.com/halfdog/guerillabackup/master/data/debian.template/changelog"; instead. After that the changes can be commited to the Salsa repository, package being built: git commit . --message="V0.0.2-1 merged with upstream" git tag "v0.0.2-1" gbp buildpackage I uploaded the package to "https://mentors.debian.net/package/guerillabackup"; and it seems to be OK except for some lintian warnings, which seem easy to fix. Should I push the changes from above to the Salsa repository as a prerequisite for starting the sponsor search? hd
