Bug#976113: Bug#954823: Sponsorship of hydrogen
Hi Ross, Ross Gammon writes: > I have spent some time going through the commit messages. There has > been a lot of work done! Yes :-) If I remember correctly, cdbs -> dh, and upstream churn between prereleases was the worst of it. >> Will you be sponsoring from git or mentors? How would you like me to >> work during the WIP cycles of the review? The git history will look a >> bit silly and confusing with too many "refinalise for release to >> unstable" commits ;-) > > I can do either. But I think in this case, I would prefer to work from > mentors (mainly because I have problems with my gbp setup on this > computer). But please also keep the git repository in sync (even if it > is on a different branch that we can merge later). > Will do! The WIP branch is called "rfs-976113-rebase" and I pushed it just now; it doesn't contain much yet. I will update mentors as soon as we have an upload candidate (still too many outstanding big issues at this time). > Actually, I would like to compliment you on your commit messages. It was > pleasing to see a verbose reason for the change, instead of some short > cryptic message that just generates more questions. > Thank you you, I appreciate that you noticed! It really helps with making sense of work from months ago that I've now forgotten the details and reasoning. And for other team members, of course. 'wish all new contributors were mentored to value this ;-) (I was) >> On #debian-multimedia, Sebastinas did a preliminary review, and two big >> issues were: >> >> 1. override_dh_auto_build had a typo! "override_override_dh_auto_build" >>* I've fixed this locally >> 2. I was missing an override_dh_auto_configure to make use of >>$DEB_CMAKE_EXTRA_FLAGS >>* I believe that is why the extra lib and dev packages became >> necessary. Now that I know what was causing the problem I can >> restore something closer to the old packaging. >>* Changing this in the future will require another trip through NEW, >> so what do you think the correct split of the package is? > > I was wondering why the library packages suddenly appeared. I think if > it is possible, it is best to stick to the old packages. What > applications would want to use hydrogen as a library? > Hypothetical 3rd party plugins, I think? Unfortunately even with -DWANT_SHARED=OFF we still end up with libhydrogen-core-1.0.1.a, which appears to have not been installed in the 0.9.7 series of Debian packages. I can whitelist and ignore it, but for comparison to other distributions, OpenSUSE chose to ship the lib: https://software.opensuse.org/package/libhydrogen-core0 (for 0.9.7) https://software.opensuse.org/package/libhydrogen-core1 (for 1.0.1) Also, I'm also not sure if there is any practical benefit to hydrogen-dev (hypothetical plugin development), so I'm wondering if the headers should not be installed; they weren't installed in the last release (0.9.7-6). Hydrogen-dev_1.0.1-1_all.deb is only 84KB, so could be merged into libhydrogen-core-1.0.1. Sebastinas says the -dev package is arch-specific, and if that's the case it seems like merging the -dev package into bin:libhydrogen-core-1.0.1 would be reasonable. There is something to be said the principle of least surprise when moving between distributions, but I don't have a position on way or the other. At this time we can also reassess the hydrogen and hydrogen-data split. If I was packaging Hydrogen from scratch I'm not sure that I would split them... Finally, if we maintain the split, what is your position on .desktop and appdata files? Should they go in bin:hydrogen-data, or in bin:hydrogen? >> I have not yet reopened any bugs. The list of -rm bugs is: >> 945042 642014 629105 870395 794042 586087 874907 347279 945042 >> [snip] > > I think the best thing is to reopen the bug and then close them in the > changelog once it is confirmed that they are closed. That way they are > closed with the right version information. The most important thing is > to ensure that bugs that are not fixed in the new version remain open. > I've reopened this list of bugs. > Let me know when the new version is available on mentors. > Will do! I'd just want to take care of the major design decisions first. Cheers, Nicholas signature.asc Description: PGP signature
Bug#978540: RFS: ancient/1.0-1 [ITP] -- decompression routines for ancient formats
On Mon, Dec 28, 2020 at 01:56:23PM +0100, Gürkan Myczko wrote: > * Package name: ancient >Version : 1.0-1 > * URL : https://github.com/temisu/ancient > ancient (1.0-1) unstable; urgency=medium > . >* Initial release. (Closes: #978090) The copyright file lacks at least bzip2 license for src/BZIP2Table.hpp For a command-line program, I'd say a man page is a must. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#976113: Bug#954823: Sponsorship of hydrogen
Hi Nicholas, I have spent some time going through the commit messages. There has been a lot of work done! On 29/12/2020 17:29, Nicholas D Steeves wrote: > Hi Ross! > > Ross Gammon writes: > >> owner 954823 rossgam...@debian.org >> thanks >> >> Hi Nicholas, >> >> I am happy to take a look at hydrogen, and sponsor it. I have some spare >> time over the next few days. >> > Thank you, I really appreciate this! :-D Here are some notes and > questions: > > Will you be sponsoring from git or mentors? How would you like me to > work during the WIP cycles of the review? The git history will look a > bit silly and confusing with too many "refinalise for release to > unstable" commits ;-) I can do either. But I think in this case, I would prefer to work from mentors (mainly because I have problems with my gbp setup on this computer). But please also keep the git repository in sync (even if it is on a different branch that we can merge later). Actually, I would like to compliment you on your commit messages. It was pleasing to see a verbose reason for the change, instead of some short cryptic message that just generates more questions. I think it is best to keep a record of the review in the RFS bug. So I have cc'd the RFS bug (sorry - I did not spot it when I started), and we can continue the discussion there. > > On #debian-multimedia, Sebastinas did a preliminary review, and two big > issues were: > > 1. override_dh_auto_build had a typo! "override_override_dh_auto_build" >* I've fixed this locally > 2. I was missing an override_dh_auto_configure to make use of >$DEB_CMAKE_EXTRA_FLAGS >* I believe that is why the extra lib and dev packages became > necessary. Now that I know what was causing the problem I can > restore something closer to the old packaging. >* Changing this in the future will require another trip through NEW, > so what do you think the correct split of the package is? I was wondering why the library packages suddenly appeared. I think if it is possible, it is best to stick to the old packages. What applications would want to use hydrogen as a library? > 3. override_dh_auto_clean failed to run "dh_auto_clean". Oops :-/ This might explain why I found that the package failed to build twice in a row for me. > I've already make local fixes for these and other issues, but will delay > pushing until I receive your preference regarding the shared lib and dev > packages. I'm of course open to fixing other issues and removing > anything you consider vestigial to the old cdbs packaging (I chose the > more labour-intensive approach rather than clean packaging)! > >> Have you reopened any bugs that were closed when the package was removed? >> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-packages >> > I have not yet reopened any bugs. The list of -rm bugs is: > 945042 642014 629105 870395 794042 586087 874907 347279 945042 > > There seem to be differences in perspective about when/if these bugs > should be reopened. My preference is to maintain a strong link between > the changelog and BTS, for future reference, and for future > maintainers. Given "changelog closes bugs in wrong way", I feel like > reopening the bugs that will be closed by the yet-to-be-uploaded > changelog entry is the correct approach, because it creates a strong > link between the changelog and BTS. I think the best thing is to reopen the bug and then close them in the changelog once it is confirmed that they are closed. That way they are closed with the right version information. The most important thing is to ensure that bugs that are not fixed in the new version remain open. Let me know when the new version is available on mentors. Ross signature.asc Description: OpenPGP digital signature
Bug#978638: RFS: dh-runit/2.10.3 -- debhelper add-on to handle runit runscripts
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: plore...@disroot.org Dear mentors, I am looking for a sponsor for my package "dh-runit": * Package name: dh-runit Version : 2.10.3 Upstream Author : [fill in name and email of upstream] * URL : https://salsa.debian.org/debian/dh-runit * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/dh-runit Section : admin It builds those binary packages: runit-helper - dh-runit implementation detail dh-runit - debhelper add-on to handle runit runscripts To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dh-runit/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_2.10.3.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/dh-runit/-/tree/2.10.3-release Changes since the last upload: dh-runit (2.10.3) unstable; urgency=medium . * Always create supervise link for log service (Closes: #977925) * Add 2 testcase for supervise links * Bump out version to 2.10.3 * Bump Stadards-Version to 4.5.1 Regards, -- Lorenzo Puliti
Bug#978641: RFS: nsd/4.3.4-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.4-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.4-1.dsc Changes since the last upload: nsd (4.3.4-1) unstable; urgency=medium . * New upstream version 4.3.4 * Fixes CVE-2020-28935 (chown of pidfile) on systems with sysvinit Regards, Markus
Bug#978615: RFS: mugshot/0.4.3-1.1 [NMU] [RC] -- lightweight user-configuration application
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "mugshot": * Package name: mugshot Version : 0.4.3-1.1 Upstream Author : [fill in name and email of upstream] * URL : https://github.com/bluesabre/mugshot * License : CC0-1.0, GPL-3.0+ * Vcs : https://salsa.debian.org/python-team/packages/mugshot Section : utils It builds those binary packages: mugshot - lightweight user-configuration application To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mugshot/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mugshot/mugshot_0.4.3-1.1.dsc Changes since the last upload: mugshot (0.4.3-1.1) unstable; urgency=high . [ Leandro Cunha ] * Non-maintainer upload. * New upstream release. * Fix Mugshot fails with AttributeError: 'ElementTree' object has no attribute 'getiterator' in console. (Closes: #976245) * debian/control: - Bump debhelper from old 12 to 13. - Bump Standards-Version: 4.5.1. - Remove python-dbus of build depends, ported python3-dbus usage to GDBus, following upstream changelog. . [ Ondřej Nový ] * Bump Standards-Version to 4.4.1. * d/control: Update Maintainer field with new Debian Python Team contact address. * d/control: Update Vcs-* fields with new Debian Python Team Salsa layout. . [ Debian Janitor ] * Bump debhelper from old 11 to 12. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse. * Update standards version to 4.5.0, no changes needed. Regards, -- Leandro Cunha
Bug#978535: RFS: wxmaxima/20.12.0-1 -- GUI for the computer algebra system Maxima
On 28.12.20 22:01, Adam Borowski wrote: > On Mon, Dec 28, 2020 at 07:06:36PM +0100, Gunter Königsmann wrote: >> Re-uploading a corrected version of the package. > Still fails due to missing B-Dep on xauth. Wow... ...might that be a missing runtime dependency in the xvfb-run package? Included it in the build description, now. > After adding that, it builds correctly and I see no problems save for: > E: wxmaxima: privacy-breach-uses-embedded-file > usr/share/doc/wxmaxima/wxmaxima.ca.html You may use the node-html5shiv > package (virtual package). > (//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js) > E: wxmaxima: privacy-breach-uses-embedded-file > usr/share/doc/wxmaxima/wxmaxima.cs.html You may use the node-html5shiv > package (virtual package). > (//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js) > E: wxmaxima: privacy-breach-uses-embedded-file > usr/share/doc/wxmaxima/wxmaxima.da.html You may use the node-html5shiv > package (virtual package). > (//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js) > E: wxmaxima: privacy-breach-uses-embedded-file ... use --no-tag-display-limit > to see all (or pipe to a file/program) > > This is easy to fix: just depend on node-html5shiv and patch or sed the > reference to use the local copy. Sorry that this fix needed more time: I have decided that a privacy issue justifies a new upstream release => updated wxMaxima 20.12.1-1 to debian mentors and deleted wxMaxima 20.12.0-1. Do I now need to modify this bug somehow to reflect the change? Thanks a lot in advance, and kind regards, Gunter.
