Bug#969446: RFS: vguitar-2.6 [ITP] -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth)
Package: sponsorship-requests Severity: wishlist Dear Mentor/Maintainer, Package name : vguitar Version : 2.6-3 Upstream Author : URL : http://nick-strauss.com License : GPL apt-key adv --keyserver keyserver.ubuntu.com --recv-keys AB406C34 add to /etc/apt/sources.list.d deb [ arch=amd64 ] http://apt.nick-strauss.com/apt/debian jessie main apt-get install vguitar add to /etc/apt/sources.list.d deb-src http://apt.nick-strauss.com/apt/debian jessie main apt-get source vguitar vguitar --help man vguitar -- System Information: Debian Release: 8.4 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.55-1-pve (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) I am unfamiliar with Debian packaging. I am requesting a sponsor for vguitar. Thanks, Nick Strauss https://www.nick-strauss.com On Sunday, September 13, 2020, 07:57:35 AM CDT, Tobias Frost wrote: On Sat, Sep 12, 2020 at 03:10:45PM +, Nick Strauss wrote: > Can I keep this same bug number 969446 or should I open a new bug report? Yes, you keep the same bug number until is has been sponsored, regardless if there are different versions. (Just update the meta information of the bug w.g with bts(1)) -- tobi
Bug#969446: RFS: vguitar-2.6 [ITP] -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth)
Package: sponsorship-requests Severity: wishlist Dear Mentor/Maintainer, Package name : vguitar Version : 2.6-3 Upstream Author : URL : http://nick-strauss.com License : GPL apt-key adv --keyserver keyserver.ubuntu.com --recv-keys AB406C34 add to /etc/apt/sources.list.d deb [ arch=amd64 ] http://apt.nick-strauss.com/apt/debian jessie main apt-get install vguitar add to /etc/apt/sources.list.d deb-src http://apt.nick-strauss.com/apt/debian jessie main apt-get source vguitar vguitar --help man vguitar -- System Information: Debian Release: 8.4 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.55-1-pve (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) I am unfamiliar with Debian packaging. I am requesting a sponsor for vguitar. Thanks, Nick Strauss https://www.nick-strauss.com On Sunday, September 13, 2020, 07:57:35 AM CDT, Tobias Frost wrote: On Sat, Sep 12, 2020 at 03:10:45PM +, Nick Strauss wrote: > Can I keep this same bug number 969446 or should I open a new bug report? Yes, you keep the same bug number until is has been sponsored, regardless if there are different versions. (Just update the meta information of the bug w.g with bts(1)) -- tobi
Bug#970260: RFS: extractpdfmark/1.1.0-1.1 [NMU] [RC] -- Extract page mode and named destinations as PDFmark from PDF
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "extractpdfmark": * Package name: extractpdfmark Version : 1.1.0-1.1 Upstream Author : [fill in name and email of upstream] * URL : https://github.com/trueroad/extractpdfmark * License : GPL-3.0+ * Vcs : https://salsa.debian.org/debian/extractpdfmark Section : tex It builds those binary packages: extractpdfmark - Extract page mode and named destinations as PDFmark from PDF To access further information about this package, please visit the following URL: https://mentors.debian.net/package/extractpdfmark/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/extractpdfmark/extractpdfmark_1.1.0-1.1.dsc Changes since the last upload: extractpdfmark (1.1.0-1.1) unstable; urgency=high . * Non-maintainer upload. * Fix FTBFS with poppler 0.85 (Closes: #968714). Regards,
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi, On Sun, 13 Sep 2020 15:27:24 +0200 Tobias Frost wrote: > On Sun, Sep 13, 2020 at 02:50:43PM +0200, Tobias Frost wrote: > > On Sun, Sep 13, 2020 at 01:23:41PM +0200, Alec Leamas wrote: > > > So far for now… > > More stuff. Lintian this time. > > - Lintian overrides > Lintian overrides should only be used if Lintian is wrong, not to silence > problems > (even if the problems are not actionable right now, like patches not yet > forwarded) > So time to clean those up… What does "being wrong" mean in this context? Just false positives? Or also situations like the get-orig-source or "there is no checksums"? > As a bonus, after cleaning those will be fixed: > E: opencpn source: malformed-override Unknown tag > testsuite-autopkgtest-missing in line 2 I have been a too lazy human being and not not updated my sid host. After doing so I see the same messages as you. This helps, but see my question above. Cheers! --alec
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi, On Sun, 13 Sep 2020 15:27:24 +0200 Tobias Frost wrote: > On Sun, Sep 13, 2020 at 02:50:43PM +0200, Tobias Frost wrote: > > On Sun, Sep 13, 2020 at 01:23:41PM +0200, Alec Leamas wrote: > > Ah, regarding my remark for NSIS.template.in: > After thinking about it: This is probably an upstream bug… CMake does > out-of-tree builds > and therefore one should not have the need to modify a file in-tree. (Ok for > this RFS, Indeed. Filed upstream bug https://github.com/OpenCPN/OpenCPN/issues/2044. Thanks! Cheers! --alec
Bug#970254: RFS: mp3report/1.0.2-5 [ITA] -- Script to create an HTML report of MP3 files in a directory
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mp3report": * Package name: mp3report Version : 1.0.2-5 Upstream Author : David Parker * URL : http://mp3report.sourceforge.net * License : GPL-2+ * Vcs : https://salsa.debian.org/mzf/mp3report Section : utils It builds those binary packages: mp3report - Script to create an HTML report of MP3 files in a directory To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mp3report/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mp3report/mp3report_1.0.2-5.dsc Changes since the last upload: mp3report (1.0.2-5) unstable; urgency=medium . * New Maintainer (Closes: #831719). * Switch to dpkg-source 3.0 (quilt) format. * Fix crash when scanning empty directory (Closes: #381212). * Generate documentation and manual page from the perl source and register documentation via doc-base. * Add watch file. * Forward patches upstream. * Update VCS to salsa. Regards,
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On 13/09/2020 14:50, Tobias Frost wrote: > On Sun, Sep 13, 2020 at 01:23:41PM +0200, Alec Leamas wrote: > > (snipping stuff that is done or settled … Its getting a long mail) > > (regarding the transitinal package and Replace/Breaks versioning) >> OK, will do (unless not done in a MR)> > MR sent. (https://gitlab.com/leamas/opencpn/-/merge_requests/2) Applied. > For the readers: > - Replace/Break on << 4.8.8~. The ~ ensures that it matches everything that > had > 4.8.8 in it. (where the change happened) > - The transistional package will no longer be built. > > Note that I did not add d/changelog entries; left to you; no need to mention > me. > >> d/rules: (...) > MR sent. (https://gitlab.com/leamas/opencpn/-/merge_requests/1) Applied, but... this was an insane can of worms. As you noted, basically everything under doc/opencpn was removed. However, this was a plain bug. I have patched the installation files to install the required stuff. > The MR tidies up d/rules (removing the need for override_dh_auto_install) by > replacing > the logic with declratavie syntax: > - installing the manpages not via dh_install but with dh_installman. > - using dh_link to build the symlinks to the GPL licenses needed by the > programm. > - be more accurate in d/*install what to install > - use the possiblity to move files around in d/*install > - specify the files not to be installed. (d/not-installed) Thanks for this crash-course in the possibilities using dh_install and friends! Much appreciated. > Regarding the licenses symlinked: Are they acutally used. grep did find > nothing for me… > In this case, the file d/opencpn.links should be removed The license files are linked for formal reasons besides license.txt which is used in runtime (the About dialog). > Please review the changes to the (not-)installed (especially > d/opencpn-dat.ionstall as > you know whether the programm expect those. (After a simply grep I assumed it > does not.) Done, see above. > Please note that there will be an build error I left intentionally: > It does not install CoC-909_2013-InlandECDIS_20170308s.pdf because this file > is a file > - without source (and so also not built from source) > - unclear license (I don't think that is under a DFSG license… Is it > distributeable?) > atm it looks like it needs to be removed via Files-Excluded. Indeed. File dropped, we have a new tag 5.2.00+dfsg1 + a new build patch. > Also no d/changelog entries; left for you to be done… (I do _not_ need credit > for those!) Well, if you don't want credits in the changelog please accept them here: thanks for some really, really useful input which I think has made me a better packager. A new version is uploaded on mentors. Cheers! --alec PS: Every time I upload a new version I get a mail from mentors with a subject line like "opencpn_5.2.0+dfsg1-1: ACCEPTED into unstable". This is definitely wrong, and should perhaps be filed somewhere (?) DS
Bug#970246: RFS: lsm/1.0.4-2 [RC] -- Link connectivity monitor tool
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "lsm": * Package name : lsm Version : 1.0.4-2 Upstream Author : [fill in name and email of upstream] * URL : http://lsm.foobar.fi/ * License : GPL-2 Section : utils It builds those binary packages: lsm - Link connectivity monitor tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lsm/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-2.dsc Changes since the last upload: lsm (1.0.4-2) unstable; urgency=medium
Re: Bug#969241: RFS: hydrapaper/1.12 [ITP]] -- sets desktop wallpaper on different monitors
Greetings! On Tue, 2020-09-08 at 22:01 +0200, Tobias Frost wrote: > Please fix those issues and then remove the moreinfo tag! > I've done all that; packaged version 2.0, fixed issues with packaging and removed the tag. Thanks. -- []'s, Francisco M Neto www.fmneto.com 3E58 1655 9A3D 5D78 9F90 CFF1 D30B 1694 D692 FBF0 signature.asc Description: This is a digitally signed message part
Re: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
On Sun, 2020-09-13 at 15:24 +0100, Simon McVittie wrote: > On Sun, 13 Sep 2020 at 10:35:48 +0100, Simon McVittie wrote: > > On Sun, 13 Sep 2020 at 04:02:56 +0100, Phil Wyett wrote: > > > Can we have this uploaded for the upcoming 10.6? Still seen no > > > love and > > > missed so many point releases now. Just need someone with > > > permissions to > > > do it and a little time. > > > > I'll put this on my queue to review and test. > > Uploaded. In future, if you have changes for a package in stable, > please try to work with the package's maintainers first, rather than > bypassing them. > > I know the GNOME team has taken too long to respond, and I'm sorry > about > that. We are responsible for a lot of packages, of which gnome-maps is > far from our highest priority. > > smcv Hi Simon, Thank you for the response, review and upload. I will try to be more in touch with the GNOME team with future work. I hope via discussion, git and MR. To go back to time and hardware. The DPL did mention spending as part of his DebConf20 talk. Maybe an application can be made for hardware for members of the GNOME team, so they might have a stable instance on hand for its related needs. GNOME is a very important part of Debian and supporting those working on it would be a good thing. Regards Phil -- *** Playing the game for the games sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Bug#968504: RFS: aqemu/0.9.2-2.4 [NMU] [RC] -- Qt5 front-end for QEMU and KVM
Hi, Thanks for your review :) Le 26/08/2020 à 12:39, Tobias Frost a écrit : > Control: tags -1 moreinfo > > Hi Alexis, > > this is an incomplete review, 'cause I ran out of time, lunch break was not > long > enough :-( > > - This should be not an NMU but an QA-Upload so you need to Set the maintainer > to the QA group, as explained here: > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning-a-package > > [...] Ok, I've put sources with imported debsnap history in https://salsa.debian.org/debian/aqemu. > > - "(For: #957003)" > Please close the bug in the changelog; it can always be reopened if it fails > again…) Ok > > - I'm not sure about dropping the Depends on qemu entirely. Does aqemu work > without qemu installed? If not, you probably need to follow the recommendation > in #966261 > and add a Depend on qemu-system-XXX | qemu-system-XXX | … (listing all archs). > I'm wondering if I should put these as a Recommends instead. I'm thinking about cases where someone would want to use a different qemu not packaged, like a custom one or a manually compiled one. But I'm not sure I should handle these cases, what do you think ? > > There were other bugs on the packages too. Did you try to triage them? > (It would be nice to at least report them to upstream, but that's not a show > stopper for the sponsoring) I'm not using aqemu myself, but some of them or probably upstream, and maybe fixed since they were reported, but newer versions (0.9.6+) are qualified as not yet stable by upstream. I will see if they were already reported or still relevant (some of them were created in 2012). > > Many thanks for contributing to Debian! > Thanks for your review :) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Re: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
On Sun, 13 Sep 2020 at 10:35:48 +0100, Simon McVittie wrote: > On Sun, 13 Sep 2020 at 04:02:56 +0100, Phil Wyett wrote: > > Can we have this uploaded for the upcoming 10.6? Still seen no love and > > missed so many point releases now. Just need someone with permissions to > > do it and a little time. > > I'll put this on my queue to review and test. Uploaded. In future, if you have changes for a package in stable, please try to work with the package's maintainers first, rather than bypassing them. I know the GNOME team has taken too long to respond, and I'm sorry about that. We are responsible for a lot of packages, of which gnome-maps is far from our highest priority. smcv
Re: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
On Sun, 13 Sep 2020 at 21:39:49 +0800, xiao sheng wen 肖盛文 wrote: > The only question is lintian check has some info Some Lintian warnings are normal for a stable update, where the changes that would prevent those warnings would break the rule of including only minimal changes. smcv
Re: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
Hi, smcv ,Phil Wyett: My notebook is 10.5.0 + debian-security buster-updates buster-backports buster-proposed-updates . I had already run: apt update;apt upgrade I run the following commands to build package: git clone https://salsa.debian.org/gnome-team/gnome-maps.git git checkout origin/debian/buster dpkg-buildpackage The package gnome-maps_3.30.3.1-0+deb10u2_amd64.deb can build OK. apt install ./gnome-maps_3.30.3.1-0+deb10u2_amd64.deb work OK. gnome-maps run OK, It's work normal. apt purge gnome-maps also run OK. The only question is lintian check has some info: lintian gnome-maps_3.30.3.1-0+deb10u2_amd64.changes E: gnome-maps source: license-problem-undefined-license lgpl-unspecified-version (line 39) E: gnome-maps source: license-problem-undefined-license lgpl-unspecified-version (line 89) W: gnome-maps: no-manual-page usr/bin/gnome-maps W: gnome-maps source: no-nmu-in-changelog W: gnome-maps source: source-nmu-has-incorrect-version-number 3.30.3.1-0+deb10u2 I: gnome-maps source: out-of-date-standards-version 4.2.1 (released 2018-08-25) (current is 4.5.0) X: gnome-maps source: debian-rules-uses-as-needed-linker-flag line 4 X: gnome-maps source: debian-watch-does-not-check-gpg-signature P: gnome-maps source: package-uses-old-debhelper-compat-version 11 P: gnome-maps source: trailing-whitespace debian/changelog (line 13) P: gnome-maps source: trailing-whitespace debian/changelog (line 14) X: gnome-maps source: upstream-metadata-file-is-missing P: gnome-maps source: uses-debhelper-compat-file N: 1 tag overridden (1 warning) The build info files, please see the attachments. I hope these can do help for your review and test. 在 2020/9/13 下午5:35, Simon McVittie 写道: > Sorry, the GNOME team has the same problem as every other major team in > Debian: too many packages and too little time. Many of us run testing > or unstable, so properly testing an upload to stable requires switching > between installations or machines, or borrowing partners'/family members' > stable installations. > > The default for stable is always to not upload, because regressions in > stable are considered worse than pre-existing bugs. > > I'll put this on my queue to review and test. > > smcv > > -- 肖盛文 xiao sheng wen Faris Xiao 微信(wechat)：atzlinux 《铜豌豆 Linux》 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com GnuPG Public Key: 0x339240CB Format: 3.0 (quilt) Source: gnome-maps Binary: gnome-maps Architecture: any Version: 3.30.3.1-0+deb10u2 Maintainer: Debian GNOME Maintainers Uploaders: Jeremy Bicha , Tim Lunn Homepage: https://wiki.gnome.org/Apps/Maps Standards-Version: 4.2.1 Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-maps Vcs-Git: https://salsa.debian.org/gnome-team/gnome-maps.git Build-Depends: debhelper (>= 11), geoclue-2.0 (>= 0.12.99), gjs (>= 1.50.0), gnome-pkg-tools, gobject-introspection (>= 0.10.1), intltool (>= 0.40), libchamplain-0.12-dev (>= 0.12.14), libfolks-dev (>= 0.10.0), libgee-0.8-dev (>= 0.16.0), libgeocode-glib-dev (>= 3.15.2), libgirepository1.0-dev (>= 0.10.1), libgjs-dev (>= 1.44.0), libglib2.0-dev (>= 2.44.0), libgtk-3-dev (>= 3.22.0), librest-dev (>= 0.7.90), libxml2-dev, meson Package-List: gnome-maps deb gnome optional arch=any Checksums-Sha1: 39ca6cb5025f2f5ed5881fe8db17fecaeb6954e9 2175840 gnome-maps_3.30.3.1.orig.tar.xz 50a1d180537dffde58aa9de0b0b65f18afd6d476 5816 gnome-maps_3.30.3.1-0+deb10u2.debian.tar.xz Checksums-Sha256: b11f6c1344c484eb4ecfd80ab4553175c30bce005c1277ab5c8803ddb21f1377 2175840 gnome-maps_3.30.3.1.orig.tar.xz 6b27ddf7741af215daa00a406399ffe331a58b38c1381b03eedc8d92e6633423 5816 gnome-maps_3.30.3.1-0+deb10u2.debian.tar.xz Files: 5278b2311d4a8c05974d6596949b1029 2175840 gnome-maps_3.30.3.1.orig.tar.xz 0433842100b9200efc98c8dbe508dc5c 5816 gnome-maps_3.30.3.1-0+deb10u2.debian.tar.xz Format: 1.0 Source: gnome-maps Binary: gnome-maps Architecture: amd64 source Version: 3.30.3.1-0+deb10u2 Checksums-Md5: 7a4c52f2f46200ac631f28017d844d25 1528 gnome-maps_3.30.3.1-0+deb10u2.dsc bc1870da7d8345fb89f1ff0778728b2e 85152 gnome-maps-dbgsym_3.30.3.1-0+deb10u2_amd64.deb 372c6922f188cb88929d0a871e3de4a8 669804 gnome-maps_3.30.3.1-0+deb10u2_amd64.deb Checksums-Sha1: 427628b0179c8bb6617fa4d532371fa5655de0eb 1528 gnome-maps_3.30.3.1-0+deb10u2.dsc 81b0adec73520551385cf01cc0711be3e8336530 85152 gnome-maps-dbgsym_3.30.3.1-0+deb10u2_amd64.deb aaca53ecebcec90414f7c69e6f7140fa365e78bf 669804 gnome-maps_3.30.3.1-0+deb10u2_amd64.deb Checksums-Sha256: d112ef951c3099318b7c478166dfac984ca9659c98932101e12368450964e908 1528 gnome-maps_3.30.3.1-0+deb10u2.dsc 7e8dacbfe3eafbf1bc3684087069ae5a303fac2c5621b213554c2db52182864c 85152 gnome-maps-dbgsym_3.30.3.1-0+deb10u2_amd64.deb 1c1d7153f51d693343d0fa9884f72ef6b8b96494528f78413043c0f2364dbf41 669804 gnome-maps_3.30.3.1-0+deb10u2_amd64.deb Build-Origin: Debian Build-Architecture: amd64 Build-Date: Sun, 13 Sep 2020 21:07:56
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Sun, Sep 13, 2020 at 02:50:43PM +0200, Tobias Frost wrote: > On Sun, Sep 13, 2020 at 01:23:41PM +0200, Alec Leamas wrote: > > (snipping stuff that is done or settled … Its getting a long mail) > > (regarding the transitinal package and Replace/Breaks versioning) > > OK, will do (unless not done in a MR) > > MR sent. (https://gitlab.com/leamas/opencpn/-/merge_requests/2) For the > readers: > - Replace/Break on << 4.8.8~. The ~ ensures that it matches everything that > had > 4.8.8 in it. (where the change happened) > - The transistional package will no longer be built. > > Note that I did not add d/changelog entries; left to you; no need to mention > me. > > > d/rules: (...) > MR sent. (https://gitlab.com/leamas/opencpn/-/merge_requests/1) > The MR tidies up d/rules (removing the need for override_dh_auto_install) by > replacing > the logic with declratavie syntax: > - installing the manpages not via dh_install but with dh_installman. > - using dh_link to build the symlinks to the GPL licenses needed by the > programm. > - be more accurate in d/*install what to install > - use the possiblity to move files around in d/*install > - specify the files not to be installed. (d/not-installed) > > Regarding the licenses symlinked: Are they acutally used. grep did find > nothing for me… > In this case, the file d/opencpn.links should be removed > > Please review the changes to the (not-)installed (especially > d/opencpn-dat.ionstall as > you know whether the programm expect those. (After a simply grep I assumed it > does not.) > > Please note that there will be an build error I left intentionally: > It does not install CoC-909_2013-InlandECDIS_20170308s.pdf because this file > is a file > - without source (and so also not built from source) > - unclear license (I don't think that is under a DFSG license… Is it > distributeable?) > atm it looks like it needs to be removed via Files-Excluded. > > Also no d/changelog entries; left for you to be done… (I do _not_ need credit > for those!) > > So far for now… More stuff. Lintian this time. - Lintian overrides Lintian overrides should only be used if Lintian is wrong, not to silence problems (even if the problems are not actionable right now, like patches not yet forwarded) So time to clean those up… As a bonus, after cleaning those will be fixed: E: opencpn source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 2 P: opencpn source: renamed-tag send-patch => patch-not-forwarded-upstream in line 14 This override should not be using a wildcard, but exactly match the false postive only. # False positive from translations. spelling-error-in-binary usr/bin/opencpn * Ah, regarding my remark for NSIS.template.in: After thinking about it: This is probably an upstream bug… CMake does out-of-tree builds and therefore one should not have the need to modify a file in-tree. (Ok for this RFS, but as you possess a upstream hat please take a look at it with that one on) So, as far I see, only copyright review is left… We are getting closer! (And I need a break before that. Don't hesitate to push stuff in the meantime around.) -- tobi
Bug#969446: RFS: vguitar-2.6 [ITP] -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth)
On Sat, Sep 12, 2020 at 03:10:45PM +, Nick Strauss wrote: > Can I keep this same bug number 969446 or should I open a new bug report? Yes, you keep the same bug number until is has been sponsored, regardless if there are different versions. (Just update the meta information of the bug w.g with bts(1)) -- tobi
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Sun, Sep 13, 2020 at 01:23:41PM +0200, Alec Leamas wrote: (snipping stuff that is done or settled … Its getting a long mail) (regarding the transitinal package and Replace/Breaks versioning) > OK, will do (unless not done in a MR) MR sent. (https://gitlab.com/leamas/opencpn/-/merge_requests/2) For the readers: - Replace/Break on << 4.8.8~. The ~ ensures that it matches everything that had 4.8.8 in it. (where the change happened) - The transistional package will no longer be built. Note that I did not add d/changelog entries; left to you; no need to mention me. > d/rules: (...) MR sent. (https://gitlab.com/leamas/opencpn/-/merge_requests/1) The MR tidies up d/rules (removing the need for override_dh_auto_install) by replacing the logic with declratavie syntax: - installing the manpages not via dh_install but with dh_installman. - using dh_link to build the symlinks to the GPL licenses needed by the programm. - be more accurate in d/*install what to install - use the possiblity to move files around in d/*install - specify the files not to be installed. (d/not-installed) Regarding the licenses symlinked: Are they acutally used. grep did find nothing for me… In this case, the file d/opencpn.links should be removed Please review the changes to the (not-)installed (especially d/opencpn-dat.ionstall as you know whether the programm expect those. (After a simply grep I assumed it does not.) Please note that there will be an build error I left intentionally: It does not install CoC-909_2013-InlandECDIS_20170308s.pdf because this file is a file - without source (and so also not built from source) - unclear license (I don't think that is under a DFSG license… Is it distributeable?) atm it looks like it needs to be removed via Files-Excluded. Also no d/changelog entries; left for you to be done… (I do _not_ need credit for those!) So far for now…
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Sun, Sep 13, 2020 at 11:00:17AM +0200, Alec Leamas wrote: > > Hi Tobias, > > Here we go: > > On 12/09/2020 16:28, Tobias Frost wrote: > > Control: owner -1 ! > > > > > Two remarks: > > - d/changelog You could bumpt the timestamp on the changelog from time to > > time, though > > ;-): dch -r "" is a nice trick ;-) > > Indeed, thanks! Tried now, will need to to it again. > > > - (nitpick) d/changelog Please be consitent on the Closes: Stancas > > - Line 2 says Closes: 948702, line 3 says Closes #962213. Please use > > either with '#' or without '#' … just for my eyes to relief… > > Fixed > > > d/control: > > - you can drop opencpn-plugins; I guess this is for people who > > installed before Debian had the package. > > Not really. It's about an old version which seemingly has existed in > Debian about 2015 (I find the traces in the salsa git log for opencpn. > Still drop? (leaving for now) Checking… Reading https://salsa.debian.org/debian-gis-team/opencpn/-/blob/0b2edd7339f86a5348de47481a549600766406c4/debian/changelog (this is the last commit before you took over;) there was a release in 2011, but nothing after that. (Note the unreleased) This is confirmed by http://snapshot.debian.org/package/opencpn/ and tracker.d.o also tells me that there was nothing in debian since at least oldstable. The fact that snapshot.d.o does not know anything older than 4.8.8 makes me wonder whether the package has ever been in Debian or just prepared but never uploaded. I think the transitional package is no longer required. > > OK to keep the > > Break/Replace until opencpn has been released with a Debian stable > > release. (I cant check if the version constraint is right, because "<<" > > is strictly earlier, that means 4.8.6~20180801.8d20a06+dfsg.1 was the > > first version with an empty plugins package?; It would be safe to us << > > 4.8.8~, though. Update: #917561 seems to indicate that this change was > > actually introduced in 4.8.8+dsfg.1-1 -- so the above restriction would > > be too old…) > > Again, this is (was?) about the traces I found in the salsa log. Shall > we drop the Breaks/Replaces? Or update to the correct value << 5.0.0+dfsg? > > Certainly happy to drop, these things are messy and nice to get > rid of. Your thoughts? (leaving for now) > I'd keep them with "(<< 4.8.8~)" and drop it once the next Debian release is out. This add a saftey net when someone happens to have it still installed for whatever reason. > > - is wx3.0-i18n really required to run opencpn? Maybe Recommends is > > enough? > > > Recommends: is indeed enough. Fixed (*how* did you catch that one? > Tooling? Experience?) I just found it strange to have an i18n package as Depend… > > > - opencpn recommends binutils. Can you say why, its a bit unusual for > > non-development applications. > > It's about some built-in crash-reporting stuff which uses addr2line. ok. (it is not phoning home, right?) > > d/opencpn.install and d/rules… > > There are some issues, I'll follow up later on those, > > probably with a patch/MR (hint to update salsa, see below). > > > OK. > > > d/clean > > - NSIS.template.in is appearantly recreated during build, it should be > > deleted via d/clean. (Then debuild twice will work, too) > > > Indeed, thanks! Fixed. > > > > d/rules: > > In the override > > - instead of making the links to the licenses, you could use > > dh_links(1) > > > Problems: > > $ man dh_links > No manual entry for dh_links > $ apt-cache search dh_links > $ > > > Google doesn't give anything meaningful either. I will follow up on that later; this is in combination with the d/rules and d/*install… (Combined with a typo, I meant dh_link) Stay tuned and watch for MR against your tmp branch (I hope this is the one…) > > > multiarch: > > - the plugin *.so are not installed in an multiarch aware path. > > > This is actually on purpose. I read the multiarch docs like multiarch > paths are only applicable to libraries i. e., there are no multiarch > applications. opencpn is an application, we cannot have multiple > architectures in $PATH, and hence the plugins which are an integrated > part of the application lives in /usr/lib/opencpn rather than the > multiarch path. > > Or? Yeah, you are likely right: The plugins comes indeed with the main package and so you can only have them on the same arch. > > > nitpicks: > > - theres a trailing space in README.source (use wrap-and-sort(1) ;-)) > > > Fixed (using vim...) > > > Wishlist: > > > (wishlist items related to README.Debian) > > - I see docs are not packaged for privacy reasons. Could they be when > > the docs being patches (not an unseen in Debian)? > > (e.g I hate it if the docs are not matching the version I have > > installed, as often the docs for the newer version won't apply well > > enough) > > > I don't follow you here... This should really be fixed upstream, by an > easy-to-use option for users
Re: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
On Sun, 13 Sep 2020 at 04:02:56 +0100, Phil Wyett wrote: > Can we have this uploaded for the upcoming 10.6? Still seen no love and > missed so many point releases now. Just need someone with permissions to > do it and a little time. Sorry, the GNOME team has the same problem as every other major team in Debian: too many packages and too little time. Many of us run testing or unstable, so properly testing an upload to stable requires switching between installations or machines, or borrowing partners'/family members' stable installations. The default for stable is always to not upload, because regressions in stable are considered worse than pre-existing bugs. I'll put this on my queue to review and test. smcv
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Tobias, Here we go: On 12/09/2020 16:28, Tobias Frost wrote: > Control: owner -1 ! > > Two remarks: > - d/changelog You could bumpt the timestamp on the changelog from time to > time, though > ;-): dch -r "" is a nice trick ;-) Indeed, thanks! Tried now, will need to to it again. > - (nitpick) d/changelog Please be consitent on the Closes: Stancas > - Line 2 says Closes: 948702, line 3 says Closes #962213. Please use > either with '#' or without '#' … just for my eyes to relief… Fixed > d/control: > - you can drop opencpn-plugins; I guess this is for people who > installed before Debian had the package. Not really. It's about an old version which seemingly has existed in Debian about 2015 (I find the traces in the salsa git log for opencpn. Still drop? (leaving for now) > OK to keep the > Break/Replace until opencpn has been released with a Debian stable > release. (I cant check if the version constraint is right, because "<<" > is strictly earlier, that means 4.8.6~20180801.8d20a06+dfsg.1 was the > first version with an empty plugins package?; It would be safe to us << > 4.8.8~, though. Update: #917561 seems to indicate that this change was > actually introduced in 4.8.8+dsfg.1-1 -- so the above restriction would > be too old…) Again, this is (was?) about the traces I found in the salsa log. Shall we drop the Breaks/Replaces? Or update to the correct value << 5.0.0+dfsg? Certainly happy to drop, these things are messy and nice to get rid of. Your thoughts? (leaving for now) > - is wx3.0-i18n really required to run opencpn? Maybe Recommends is > enough? Recommends: is indeed enough. Fixed (*how* did you catch that one? Tooling? Experience?) > - opencpn recommends binutils. Can you say why, its a bit unusual for > non-development applications. It's about some built-in crash-reporting stuff which uses addr2line. > d/opencpn.install and d/rules… > There are some issues, I'll follow up later on those, > probably with a patch/MR (hint to update salsa, see below). OK. > d/clean > - NSIS.template.in is appearantly recreated during build, it should be > deleted via d/clean. (Then debuild twice will work, too) Indeed, thanks! Fixed. > d/rules: > In the override > - instead of making the links to the licenses, you could use > dh_links(1) Problems: $ man dh_links No manual entry for dh_links $ apt-cache search dh_links $ Google doesn't give anything meaningful either. > multiarch: > - the plugin *.so are not installed in an multiarch aware path. This is actually on purpose. I read the multiarch docs like multiarch paths are only applicable to libraries i. e., there are no multiarch applications. opencpn is an application, we cannot have multiple architectures in $PATH, and hence the plugins which are an integrated part of the application lives in /usr/lib/opencpn rather than the multiarch path. Or? > nitpicks: > - theres a trailing space in README.source (use wrap-and-sort(1) ;-)) Fixed (using vim...) > Wishlist: > (wishlist items related to README.Debian) > - I see docs are not packaged for privacy reasons. Could they be when > the docs being patches (not an unseen in Debian)? > (e.g I hate it if the docs are not matching the version I have > installed, as often the docs for the newer version won't apply well > enough) I don't follow you here... This should really be fixed upstream, by an easy-to-use option for users to download the docs (the download is available upstream). However, I don't think it's reasonable to fix it downstream. Basic problem is that the docs are generated using a wiki system which just havn't (and cannot have) sources which are public. Please don't ask me why this system is used... > - (as you are upstream-involved, this is probably easy to fix on your > side:) The plugin code could also look into alternative directories… It actually already does. It's perfectly possible to create .deb-packaged plugins, and there are plenty around -- this is the way plugins have been packaged for Debian/ubuntu since long. In the upstream bugs (which you seem to have skimmed to in some cases?), these are referred to as legacy plugins. > - The /usr/share/ hierachicy is reserved for packaged stuff, so > encouraging users to copy stuff there is a bit meeeh; it can > create problems when e.g a new package provides this file. > - So probably /usr/local/… or /opt/… would be a better > recommendation. > - Additionally, when users should be able to install plugins without > being root, something like $HOME/.local/… (not sure if this is > consenus in Debian, though) There are just so many problem here. In Fedora, packages are explicitly forbidden to write anything under /home for good reasons. I don't think Debian is or should be different. But, see above, .deb packages work out of the box. I have pushed a new version to mentors, with fixes above. The patches and d/copyright are fixed to
