Re: Data updates in debian packages
On 28/10/16 12:38, Ole Streicher wrote: Hi, My question is now how to provide a good and consistent packaging: Usually, one would just put the data into a package. This works nicely for the immutable data, and reasonably for the slowly changing data. The fast changing data shall be available for all people, but not everyone needs a daily update. So, for consistency, and to have them available in CI and build time tests, I would like to also package them directly, but then to provide an (optional) update service. How should the update service work? Can it just overwrite the existing files? How one should handle if an update (with possibly older data) in installed to not downgrade the data? I wonder i the very idea to package this data is the correct one. What if you instead package an update service which is able to download all required data and make it available somewhere under /var/lib i. e., not in any package at all? And then adds some packages from which you can seed this service in situations where it's needed: off-line, tests, persistent data etc... Cheers! --alec
Re: Build a sort-of-systemd-dependent package on kfreebsd
On 08/11/16 14:13, Henrique de Moraes Holschuh wrote: On Tue, Nov 8, 2016, at 10:39, Alec Leamas wrote: I'm now trying to wrap my head around how to conditionalize a packet such as lirc. I'm coming from Fedora/RPM and used to just spread some %ifarch in the spec file. Now, is something similar possible in debian? That said, I think you could get either better (or faster) help on debian-mentors@lists.debian.org (which I added to Cc:). It is a list specific to help new maintainers, and doubts about packaging corner cases are routinely handled there. Thanks for reply. That said, I'm aware of both lists and posting to devel was a deliberate choice. So, if anyone has an actual reply on the original post [1], please reply on -devel so we don't run into cross-posting problems. Cheers! --alec [1] https://lists.debian.org/debian-devel/2016/11/msg00288.html
Re: Packaging from Git
On 20/12/16 12:57, Narcis Garcia wrote: Maintaining debian-branch, upstream-branch and pristine-tar... Does it mean that I'll need to replicate "master" branch to those 3 sub-branches each time I wan to apply an update? Same for each upstream/ subdirectories? I have been struggling with this myself. My current approach - One separate branch for the debian packaging - In that branch, add the release branch as a git submodule - In the debian branch, check in and tag the pristine tarball. There are most likely better ways to do this; tyhis is just my current understanding. IMHO, the dreaded submodule actually works quite fine here. Cheers! --alec
Re: Packaging from Git
On 20/12/16 13:21, Andrey Rahmatullin wrote: On Tue, Dec 20, 2016 at 01:10:03PM +0100, Alec Leamas wrote: I have been struggling with this myself. My current approach - One separate branch for the debian packaging - In that branch, add the release branch as a git submodule - In the debian branch, check in and tag the pristine tarball. That is very wrong, what problems do you have with the workflows described in the gbp docs? Well, wrong... I'm in the same situation as Narcis being both upstream and packager. On top of that, I maintain the debian branch om Fedora, so I assume gbp is not an option for me. That said, if using gbp is in the focus of this thread, just disregard my message as being off-topic. Cheers! --alec
Re: Packaging from Git
On 20/12/16 15:25, Adam Borowski wrote: On Tue, Dec 20, 2016 at 11:00:20AM +0100, Narcis Garcia wrote: Hello, I'm trying to maintain a small project in my public Git, and to have an easy way to build a package for Debian OS obtaining a good/clean result. Even just using git directly without any helpers is, IMO, much better -- you can conveniently transfer patches both ways between your and upstream repository, at every point you get an appropriate form for modification -- you can just hack on the code (with something quilt-based you need to finalize patches after every incremental edit), etc. Well then I'm not alone. Basically, this is what I do, adding the "upstream as a submodule" idea to the mix. Cheers! --alec
Adequate reports obsolete conffiles: and now what?
Dear list, The new, shiny lirc 0.9.4 has received a bug report #851618. At the core, this is about adequate reporting lirc: obsolete-conffile /etc/lirc/irexec.lircrc lirc: obsolete-conffile /etc/lirc/lircmd.conf lirc: obsolete-conffile /etc/lirc/hardware.conf lirc: obsolete-conffile /etc/lirc/lircd.conf lirc: obsolete-conffile /etc/lirc/lirc_options.conf However, all of these files exists for a purpose and are not obsolete. The details: - hardware.conf is indeed obsolete in 0.9.4. However, the manual, breaking update is about moving bits and pieces from hardware,conf to other files, so it needs to be around for some cycles before it's removed. - For the other files I'm using my own scheme: The upstream files are installed as e. g.,lirc_options.conf.dist. This file is updated but not used. If the actually used lirc_options.conf is missing it's created as a copy of the *dist file, but otherwise kept as-is.. In other words, I don't try to merge possible upstream changes, I just keep the *dist files around as reference Since the overall idea is that the adequate (or really dpkg) error message is a bug: How should I resolve this bug? Any clue out there? Shortcut to the packaging at [1] --alec [1] https://sourceforge.net/p/lirc/git/ci/debian/tree/debian/
Fwd: Re: Adequate reports obsolete conffiles: and now what?
oops, happened to send the reply to James as a PM... here it comes, it was actually meant for the list Forwarded Message Subject: Re: Adequate reports obsolete conffiles: and now what? Date: Sat, 21 Jan 2017 16:40:10 +0100 From: Alec Leamas To: James Cowgill On 21/01/17 13:16, James Cowgill wrote: Hi, Hi, thanks for taking time to reply! By definition, an obsolete conffile is a file which used to be a conffile, isn't in a new package version, but wasn't moved/removed on upgrade. So, when I have done such an operation on purpose, the warning is sort a false positive, right? Removing a conffile with dpkg-maintscript-helper will actually move it (to xxx.dpkg-back) if it was modified, so I think you can safely remove this as users will still be able to refer to it later. Well... I have made both manual instructions and a script based on that hardware.conf is still in it's original location. Of course, the file should eventually be removed, but doesn't it make make sense to leave it in it's original location for the first update cycle(s)? Basically, having it in it's original location IMHO makes it much more visible. Or? Isn't this the problem conffiles was meant to solve? Dpkg will ask the user before updating those config files and not touching them is the default option. This will also warn the user when they may need to update them anyway (eg new features). I guess this is a maintainer decision on how they want to do this (even if I think it's a bad idea) so using .dist files is still OK. Yes...the lirc history is plagued with some bugs related to this. I'm not saying that following this scheme is the ultimate solution, but for better or worse it's a decision I have made. In this case, and as long as you're sure your maintainer scripts always do the right thing, you can ignore adequate. OK... But "being sure that the maintainer scripts does the right thing" is not something I feel comfortable with. The conffiles handling is hard to understand for anyone; it's even harder for me with a RPM background ;) However I think the .dist files should be installed in /usr/share and copied from there instead of being installed in /etc. This is of course the Right Thing to do. Will implement, thanks! Cheers! --alec
Re: Fwd: Re: Adequate reports obsolete conffiles: and now what?
On 23/01/17 18:03, Gianfranco Costamagna wrote: hello, Hi! However I think the .dist files should be installed in /usr/share and copied from there instead of being installed in /etc. This is of course the Right Thing to do. Will implement, thanks! This is nice, however I think this "workaround" should be dropped post-Stretch release. Right now living for an year or two with such conf files, will make people switch to the new lirc, so an adequate report is not so much a problem to my eyes, and will remember us to drop the hack at some point :p OK, I see your point. In my usual, provocative style: To me, this means that the bug should be closed without further actions unless there is more input. Just to be clear ;) --alec
Re: Bug#852415: RFS: scap-security-guide/0.1.31-6 [ITP] -- security guides and conformity checks using SCAP standard
On 02/02/17 15:27, p...@reseau-libre.net wrote: Dear security team, I'm contributor to scap-security-guide project for 2 years now and I'm looking for a mentor for packaging the project into Debian. I'm certainly not your mentor. That said, FWIW this seems packaged in Fedora [1]. At a glance, that packaging looks trivial. Fedora has included one or two patches which might be worth considering, dunno. Cheers! --alec [1] https://apps.fedoraproject.org/packages/scap-security-guide
Uploading bugfix, normal uploader on holidays
Dear list, During the past year(s) I have been cooperating with Gianfranco who kindly has reviewed and uploaded my lirc packages. On Friday, he uploaded 0.10.0-1 and then started a well.deserved holiday. Now, we have a bug [2] which needs to be fixed in 0.10.0-1. I have prepared a 0.10.0-2 which resolves it on mentors [1], but need help with actually uploading the fix. Is there anyone out there which could give me a hand? Cheers! --alec [1] https://mentors.debian.net/package/lirc [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872074 PS: The 0.10.0-1 on mentors does not reflect the package actually uploaded, caused by the recent mentors.net outage. DS
Bug#872147: RFS: lirc/0.10.0-2 NMU
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lirc" * Package name: lirc Version : 0.10.0-2 Upstream Author : leamas.alec AT gmail DOT com (current maintainer) * URL : http://sf.net/p/lirc * License : GPLv2+ and BSD Section : utils It builds those binary packages: liblirc-client0 - infra-red remote control support - client library liblirc-dev - Infra-red remote control support - development files liblirc0 - Infra-red remote control support - Run-time libraries liblircclient-dev - Transitional placeholder. liblircclient0 - Transitional placeholder lirc - Infra-red remote control support - daemons and utils lirc-doc - Infra-red remote control support - website and manual docs lirc-x - infra-red remote control support - X utilities To access further information about this package, please visit the https://mentors.debian.net/package/lirc. Alternatively, one can download the package with dget using: dget -x https://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.10.0-2.dsc More information on lirc can be obtained from http://sf.net/p/lirc Changes since the last upload: lirc (0.10.0-2) unstable; urgency=medium * Fixed missing media/lirc.h, closes: #872074 * Fixed VCS browser path * Restore parallel builds, accidentally disabled in -1 * Fixed upstream bus #294 (VPATH build issues, in -1). * Fixed upstream bug #295 - lircmd non-existing socket writes, in -1. Regards, -- Alec Leamas
NMU help.
Dear list, Gianfranco, who usually kindly offers me reviews and also actually uploads my lirc packahes is in a well deserved holiday. During his holiday, we have a new bug in the recently uploaded lirc-0.10..0-1. It's kind of bad, a FTBS in packages compiled against lirc. It surfaced in the libirman package. I have prepared a RFS bug [1]. It's a simple bugfix + some administrative data updates. Is there anyone on this list which could help me with uploading this so that dependent packages can be compiled again? Cheers! --alec [1] https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1540599.html
Bug#872147: RFS: lirc/0.10.0-2 NMU
Hi! Thanks for feedback! I seem to have lost some chunk of messages, or possibly I just missed your reply and removed it. Sorry for that. That said, here we go: On Mon, 14 Aug 2017 23:26:47 +0500 Andrey Rahmatullin wrote: > Control: tags -1 + moreinfo > > Why does the report title say "NMU"? Perhaps it shouldn't - large parts of the debian workflow is still a mystery for me. > On Mon, Aug 14, 2017 at 05:41:45PM +0200, Alec Leamas wrote: > > * Restore parallel builds, accidentally disabled in -2 > debian/compat says 10, so --parallel is the default. yes... OTOH, at some point when 0.9.4c (last version before 0.10.0) was built locally the builds was indeed parallel. Now, it seems like it uses make -j1. But it turns out that this is the case using --parallel or not, so adding it makes actually no sense. Removing it. > > * Fixed upstream bus #294 (VPATH build issues, in -1). > s/bus/bug/ Fixed. > There are three new patches in debian/patches that are not mentioned in > debian/patches/series. Old garbage, an oversight. Removed. > How are those two upstream bugs fixed? They was fixed by the experimental 0l.10.0-rc3 upstream release, which eventually became 0.10.0 by upstream and pushed to sid as 0.10.0-1. This should have been mentioned in -1, but was not, hence the -1 note. > I haven't looked at the package itself, but wtf is happening in prerm? Removing files not owned by the package any more (but left on install to niot remove anything user-edited). > And you shouldn't call python3 -m compileall in postinst. Fixed Uploaded new version to mentors [1] --alec [1] https://mentors.debian.net/package/lirc
Bug#872147: RFS: lirc/0.10.0-2 NMU
On Wed, 16 Aug 2017 02:01:12 +0500 Andrey Rahmatullin wrote: > On Tue, Aug 15, 2017 at 10:32:55PM +0200, Alec Leamas wrote: > > > Why does the report title say "NMU"? > > > > Perhaps it shouldn't - large parts of the debian workflow is still a mystery > > for me. > Please read > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu > If you are the package maintainer you don't do NMUs, but plain uploads. Done, got it. I was confused by the fact that while I am the maintainer, I havn't done the uploads myself. > > > How are those two upstream bugs fixed? > > > > They was fixed by the experimental 0l.10.0-rc3 upstream release, which > > eventually became 0.10.0 by upstream and pushed to sid as 0.10.0-1. This > > should have been mentioned in -1, but was not, hence the -1 note. > If they are fixed in an old version, why are they mentioned in this upload > entry? Please read > https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-debian-changelog Just because I missed to document it in the correct -1 entry. Would it be better to update the -1 changelog entry? > > > I haven't looked at the package itself, but wtf is happening in prerm? > > Removing files not owned by the package any more (but left on install to > > niot remove anything user-edited). > Why are they not owned by the package? Basically because the package from 0.9.4 is systemd-centric. > Obsolete conffiles should be > removed by dpkg-maintscript-helper rm_conffile. Looking at rm_conffile at [1] this doesn't look relevant here (?) The current code is basically a left-over from the disruptive change from 0.9.0 which is several versions beyond current version. So the checksums from previous version is not available. Current code just makes sure everything is cleaned up on a final remove. > I've also noticed the priority: extra field, which means when you updated > Standards-Version to 4.0.1 in the previous upload you haven't actually > consulted > https://www.debian.org/doc/debian-policy/upgrading-checklist.html Indeed, I was not aware of it. Checking, updated Priority: to optional. Thanks for pointers to relevant documents, very helpful! Uploaded a new version to mentors, for now with irrelevant sources included. Have not been able to verify the upload, but sends this reply anyway - will be way for the day and cannot send it until this evening otherwise. Cheers! --alec
Bug#887126: RFS: ddupdate/0.2.0-1 #886546
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "ddupdate" Package name: ddupdate Version : 0.2.0-1 Upstream Author : Alec Leamas URL : https://github.com/leamas/ddupdate License : MIT Section : net It builds those binary packages: ddupdate - Tool updating DNS data for dynamic IP addresses To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ddupdate Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.2.0-1.dsc More information about ddupdate is on README at https://github.com/leamas/ddupdate. Packaging-wise it's a small python3 package with very few dependencies. Changes since the last upload: ddupdate (0.2.0-1) experimental; urgency=medium * Initial debian package, closes: #886546. -- Alec Leamas Sat, 13 Jan 2018 17:35:38 +0100 Regards, --Alec Leamas
package review: ddupdate.
Dear mentors, Following the checklist for new packages on debian mentors FAQ [2] I'm approaching the review point: "Ask on the debian-mentors mailing list for people to check your packaging..." So: Have anyone time to check my package ddupdate[1] for errors or mistakes? ddupdate is a small python3 application with very few dependencies. Cheers! --alec [1] https://mentors.debian.net/package/ddupdate [2] ttps://wiki.debian.org/DebianMentorsFaq#I_want_to_help_Debian._Tell_me_what_I_can_do
Re: package review: ddupdate.
On 15/01/18 19:13, Andrey Rahmatullin wrote: > On Mon, Jan 15, 2018 at 06:46:22PM +0100, Alec Leamas wrote: >> So: Have anyone time to check my package ddupdate[1] for errors or >> mistakes? > The RFS is 1 day old. It's too early to ask. OK. So, what's an appropriate time to wait before asking? --alec
Bug#887126: RFS: ddupdate/0.2.0-1 #886546
Hi Juhani! On 07/02/18 15:38, Juhani Numminen wrote: > Hi Alec, > > Alec Leamas kirjoitti 04.02.2018 klo 18:32 > >>> Please use up-to-date lintian. It'll give you an error tag and several >>> informational and pedantic tags, some of which are easily dealt with. >> >> I'm using sid, updated as of current?! > > "lintian -EIi --pedantic *.changes" will show the pedantic and info tags > that I mentioned. OK, it's now basically looks OK. The debian-watch-does-not-check-gpg-signature, quilt-patch-missing-description and testsuite-autopkgtest-missing diagnostics looks like false negatives to me (given that the patch is truly trivial and will never be upstreamed) >>> debian/rules: >>> Debhelper has picked Makefile instead of setup.py, so you should add >>> "--buildsystem=pybuild" after the --with arguments. Then you can >> remove override_dh_build, >>> override_dh_auto_install and override_dh_python3 rules, and delete the >> file debian/install. >> >> However, this is on purpose. I control upstream, and the Makefile >> actually does the right things. Is there anything wrong with this approach? >> >> That said, rules is in a much better shape since the review, cleaned up >> and with a dh_override_missing added. > > Your approach is fine, although you're using "--quiet" while verbose > builds are preferred[1]. Back in 0.2.0 the Makefile didn't contain the > build target and so I thought it was only for pylint etc. hmalthough that link is in the autotools context. I'm using the --quiet flag because I missed an error message in the flood of non-silent output. IMHO, if the package contained native, compiled code being verbose makes sense. But I don't really see it here... Perhaps I should implement V=1 support in the upstream Makefile... > Alright. I think debian/py3dist-overrides is left over and can be deleted. Indeed, fixed. Thanks for explanations, much appreciated! New version uploaded to mentors. Cheers! --alec
Bug#901510: RFS: ddupdate/0.6.1-2 (Upstream bugs #11, #12, #13)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate" * Package name: ddupdate Version : 0.6.1-2 Upstream Author : Alec Leamas * URL : https://github.com/leamas/ddupdate * License : MIT Section : net It builds those binary packages: ddupdate - Tool updating DNS data for dynamic IP addresses To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ddupdate Alternatively, one can download the package with dget using: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.1-2.dsc More information about ddupdate can be obtained from github homepage. Changes since the last upload (merging 0.6.1-1 and 0.6.2-1) * Fix packaging glitches: standards-version, whitespace * Add missing debian/upstream/metadata. * New upstream maintenance release Upstream bugs fixed by upstream release: #11, #12, #13 at https://github.com/leamas/ddupdate/issues?q=is%3Aissue+is%3Aclosed Regards, Alec
Bug#910895: RFS: lirc/0.10.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lirc" * Package name: lirc Version : 0.10.1-1 Upstream Author : Christoph Bartelmus l...@sf.net * URL : http://sf.net/p/lirc * License : GPL-2+ Section : utils It builds those binary packages: liblirc-client0 - infra-red remote control support - client library liblirc-dev - Infra-red remote control support - development files liblirc0 - Infra-red remote control support - Run-time libraries liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev liblircclient0 - Transitional placeholder for obsoleted liblircclient0 lirc - Infra-red remote control support - daemons and utils lirc-doc - Infra-red remote control support - website and manual docs lirc-x - infra-red remote control support - X utilities To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lirc Or, download the package with dget: dget -x https://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.10.1-1.dsc More information about lirc can be obtained from http://lirc.org. Changes since the last upload: - Updated to latest upstream bugfix release - Fixed a crash when starting lirc-setup(1). - Dropped an upstreamed build patch. - Update to version 4.2.1, compat level 11 (systemd fixes). Regards, Alec Leamas
Bug#911541: RFS: wxsvg/2:1.5.15+dfsg.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wxsvg" * Package name: wxsvg Version : 2:1.5.15+dfsg.2-1 Upstream Author : Alex Thuering * URL : http://wxsvg.sourceforge.net/ * License : GPL-2+ and wxWindows Section : libs It builds those binary packages: libwxsvg-dev - Development files for wxSVG libwxsvg-tools - SVG library for the wxWidgets toolkit (tools) libwxsvg3 - SVG library for the wxWidgets toolkit To access further information about this package, please visit https://mentors.debian.net/package/wxsvg Or, download the package with dget using: dget -x https://mentors.debian.net/debian/pool/main/w/wxsvg/wxsvg_1.5.15+dfsg.2-1.dsc The package has an ongoing but stalled review, see the mentors comment dated 2018-10-19 15:18. Changes since the last upload: * Re-introduce wxsvg to Debian, latest upstream release. * New -tools package with svgview viewer. * Update dfsg versioning scheme. * Drop get-orig-source in favor of regular uscan download. * Add hardening build flags. * Move to libwxsvg3 to match soname. * Add rudimentary d/upstream/metadata. * Bump Standards-Version. * Add libexif build dependency. * Drop libav10 patch * Drop --with-scour build dependency. * Drop bundled but generated files from package. * Drop obsolete version requirement on libpango1.0-dev. * Drop obsolete g++ and dh_autoreconf dependencies. Regards, Alec Leamas
Bug#917561: RFS: opencpn/4.8.8+dfsg.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "opencpn" * Package name: opencpn Version : 4.8.8+dfsg.1-1 Upstream Author : Dave Register * URL : https://www.opencpn.org * License : GPL2+ Section : misc It builds those binary packages: opencpn- Chartplotter and Marine GPS Navigation Software opencpn-data - Chartplotter and Marine GPS Navigation Software (data) opencpn-plugins - Chartplotter and Marine GPS Navigation Software (transitional) To access further information about this package, please visit https://mentors.debian.net/package/opencpn Alternatively, one can download the package with dget using: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_4.8.8+dfsg.1-1.dsc More information about opencpn can be obtained from https://www.opencpn.org. Changes since the last upload: opencpn (4.8.8+dfsg.1-1) unstable; urgency=medium * New upstream version * Fix ITP bugs. (closes: #907065, closes: #538067). * README.harmonics: dropped, we now use the opencpn data. * README.lucid: dropped, outdated. * Drop all existing patches (outdated). * compat level bumped to 9. * The copyright file is updated and now also supports the repacked source, but #831870 makes it necessary to use get-orig-source. * Add 14 patches (0001..0014) backported from current upstream/master, mostly build fixes. * Add two patches currently in an upstream PR (0015, 0016). * Add one downstream patch 0017. * Patching includes flexible freedesktop plugin paths, see new manpage. * The manpage which used to be a debian patch is upstreamed. * The -doc package is dropped in favor of downloading the manual from the opencpn website. Downstream patch provides HTML pointer-to-docs page. * A large number of new build dependencies. * The -plugins package is dropped, opencpn is not usable without the default, limited set of plugins. * A debian/upstream/metadata file is added. Regards, Alec Leamas
Bug#926715: RFS: ddupdate/0.6.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate" * Package name: ddupdate Version : 0.6.2-1 Upstream Author : Alec Leamas * URL : https://github.com/leamas/ddupdate * License : Expat Section : net It builds those binary packages: ddupdate - Tool updating DNS data for dynamic IP addresses For more information on this package see https://mentors.debian.net/package/ddupdate Alternatively, one can download the package with dget using: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.2-1.dsc More information about ddupdate: https://github.com/leamas/ddupdate Changes since the last upload: * New upstream release. Regards, -- Alec Leamas
Bug#930461: RFS: ddupdate/0.6.3-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate" * Package name: ddupdate Version : 0.6.3-1 Upstream Author : Alec leamas * URL : https://github.com/leamas/ddupdate * License : MIT Section : net It builds those binary packages: ddupdate - Tool updating DNS data for dynamic IP addresses To access further information about this package, please visit: https://mentors.debian.net/package/ddupdate Alternatively, one can download the package with dget: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.3-1.dsc More info: https://github.com/leamas/ddupdate Changes since the last upload: ddupdate (0.6.3-1) sid; urgency=medium * New upstream release * Bump Standards-Version -- Alec Leamas
Bug#931582: RFS: ddupdate/0.6.4-1
package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate" Package name: ddupdate Version : 0.6.4-1 Upstream Author : Alec Leamas leamas.alecgmail.com URL : https://github.com/leamas/ddupdate License : MIT It builds the single binary package: ddupdate - Tool updating DNS data for dynamic IP addresses More info: https://mentors.debian.net/package/ddupdate or: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.4-1.dsc Changes since the last upload: ddupdate (0.6.4-1) sid; urgency=medium * New upstream release * Drop global systemd/system units in favor of systemd/user ones. Regards, Alec Leamas
Bug#962714: RFS: ddupdate/0.6.5-1 -- Tool updating DNS data for dynamic IP addresses
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate" * Package name: ddupdate Version : 0.6.5-1 Upstream Author : https://github.com/leamas/ddupdate/issues * URL : https://github.com/leamas/ddupdate * License : Expat * Vcs : https://github.com/leamas/ddupdate/tree/debian Section : net It builds the single, standard python package: ddupdate - Tool updating DNS data for dynamic IP addresses This is a bugfix upstream release. More info is available at https://mentors.debian.net/package/ddupdate Alternatively, one can download the package with dget using: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.5-1.dsc Changes since the last upload: * New upstream release. * Bump debhelper from old 11 to 12. * Set debhelper-compat version in Build-Depends. * Set field Upstream-Contact in debian/copyright. * Set upstream metadata fields: Bug-Submit, Repository. * Remove obsolete fields Contact, Name from debian/upstream/metadata (already present in machine-readable debian/copyright). * Update standards version to 4.5.0, no changes needed. * Fix error running ddupdate-config (#41) * New plugin domains.google.com * Multiple python 3.9 fixes. Regards, -- Alec Leamas
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "opencpn" * Package name: opencpn Version : 5.2.0+dfsg-1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-2+ * Vcs : https://gitlab.com/leamas/opencpn Section : misc It builds those binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) opencpn-plugins - Open Source Chartplotter and Marine GPS Navigation Software (transition) To access further information about this package see https://mentors.debian.net/package/opencpn Alternatively, one can download the package with dget: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.2.0+dfsg-1.dsc Changes since the last upload: * New upstream release * Closes: #962213 * Update debian/copyright due to new upstream source layout. * Bump Standards-Version to 4.5.0, no changes. * Drop upstreamed patches. Regards, -- Alec Leamas
Re: About sponsorship in real life
On 08/09/2020 13:10, Geert Stappers wrote:
> On Tue, Sep 08, 2020 at 07:39:14AM +0200, Thomas Dettbarn wrote:
>>> Francisco M Neto hat am 08.09.2020 03:31 geschrieben:
>>>
>>>
>>> Greetings,
>>>
>>> I see a lot of RFS email that just sits there in the mailing list,
>>> without ever getting a response... is that normal? Do responses about
>>> requests
>>> for sponsorship usually not get sent to debian-mentors?
>>>
>>> Is there something I should be doing to get someone to sponsor my
>>> package?
>>>
>>
>> Yes, the process is highly frustrating.
>> Hang in there, buddy!
>>
> Yes, the same webpage has a list of RFS that need follow-up.
Indeed. I have actually one of two RC bugs ("Important bugs") sitting
here since end of July. Even so, not much happens.
> Just "Hang in" will not help.
Hm... yes. I will have to do something, I guess. Not entirely clear to
me what that would be, though. But thanks for suggestions.
--alec
Backporting package which missed bookworm.
Dear list, I'm trying to handle the opencpn package. Upstream has just released 5.8.0. Despite other intentions, it has thus missed bookworm. Hence I need to use the backports. I see no particular problem with backporting 5.8.0 from sid/testing once it's there to bookworm-backports. However, what about bullseye-backports? At which point can I backport the package in sid (yet ot be uploaded) to bullseye? Of course, what I want is to do it "now". Any advice out there? --alec
Bookworm backport status
Dear list, Trying to understand the backport mechanics after the bookworm release. Specifically, I try to push a new opencpn release 5.8.2 which missed the freeze into the backport branches. For bullseye, my upload ended up in the backports new queue, which is as expected. My upload to bookworm-backports was accepted, but after that I have seen no trace of it. Looking more into this I realize that question might be if bookworm-backports actually exists at this point. Anyone which can shed some light on the bookworm-backports status and perhaps also where my upload ended up? Cheers! --alec
Re: Bookworm backport status
Hi Paul, On 21/06/2023 06:16, Paul Wise wrote: On Mon, 2023-06-19 at 14:40 +0200, Alec Leamas wrote: Anyone which can shed some light on the bookworm-backports status and perhaps also where my upload ended up? I suggest checking the debian-backports mailing list archives and if the answer isn't there, ask on the list or on the IRC channel. Ah... thanks for that pointer! Still confused, but on a higher level. Will sort it out there. Cheers! --alec
Upload to bookworm-backports
Dear mentors, I'm trying to upload openpcn to bookworm-backports. Since I'm just a DM, I need a sponsor to upload the first package heading into the NEW queue. However, bookworm-backports is yet not accepted by the mentors infrastructure. Is there any other way I could get some help with this upload? The package is available at https://gitlab.com/leamas/opencpn in the branch debian/bookworm-backports. The delta against sid is as expected minimal. Cheers! --alec
Bug#1042006: RFS: opencpn/5.8.4+dfsg-1~bpo11+1 -- Open Source Chartplotter and Marine GPS navigation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn". I have DM upload permissions for this package, but needs help to get the first bullseye-sloppy to enter the NEW queue (!) * Package name : opencpn Version : 5.8.4+dfsg-1~bpo11+1 Upstream contact : Dave S. Register * URL : https://opencpn.org * License : SGI-B-2.0, SGI-B-1.1, GPL-2, Expat, public-domain, GPL-2+, LGPL-2+, Khronos, BSD-3-clause, wxWidgets, GPL-3+, GPL-3, Expat or GPL-2+ * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info on https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.8.4+dfsg-1~bpo11+1.dsc Changes since the last upload: opencpn (5.8.4+dfsg-1~bpo11+1) bullseye-backports-sloppy; urgency=medium . * New upstream-release * Rebuilt for bullseye-backports-sloppy. Regards, -- alec leamas
Bug#1051759: opencpn/5.8.4+dfsg-1~bpo12+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my backport of the package "opencpn". This is a clean rebuild of the package in sid. I have DM rights for opencpn. However, this does not allow me to even upload for review by ftp-masters so I need some DD help to enter the NEW queue. Details: * Package name : opencpn Version : 5.8.4+dfsg-1~bpo12+1 Upstream contact : Dave S. Register * URL : https://opencpn.org * License : SGI-B-2.0, SGI-B-1.1, GPL-2, Expat, public-domain, GPL-2+, LGPL-2+, Khronos, BSD-3-clause, wxWidgets, GPL-3+, GPL-3, Expat or GPL-2+ * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info on https://mentors.debian.net/package/opencpn or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.8.4+dfsg-1~bpo12+1.dsc Changes since the last upload: opencpn (5.8.4+dfsg-1~bpo12+1) bookworm-backports; urgency=medium . * New upstream release * Rebuilt for bookworm-backports. Regards, -- Alec Leamas
Re: git packaging workflows (Was: Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer) IO tracing
Hi list, On 13/08/2024 16:00, Matthew Fernandez wrote: On 8/13/24 04:34, Daniel Gröber wrote: On Mon, Aug 12, 2024 at 11:37:24PM +1000, Dmitry Smirnov wrote: IMHO GBP approach is counter-productive, with needlessly complicated workflow, redundant upstream branch(es) and incredibly inconvenient merge of debian packaging and upstream files in "master". I haven’t followed the gbp discussion closely, but as a package maintainer who does not know Debian thoroughly I found all documented workflows except gbp near incomprehensible. This is not to say they are poorly founded or documented, but rather that they did not fit my intuitions. gbp on the other hand seemed to “just work”. The criticisms on the wiki seem to assume you’re importing a tarball, whereas I was starting from an upstream already in git (I am also the upstream maintainer). The ease of gbp to people like me is that we already know git well, but do not know Debian well. I'm also sort of newbie as a maintainer, and it's not my main focus which is in upstream. But I basically agree, I find gbp perfectly useful. Another aspect when coming from outside is that gbp being so much used makes things easier to understand. You need some really big benefits with another workflow to motivate even more fragmentation of how to package. Can you see these big benefits? --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Tobias, Thanks for taking some time for this! On 08/09/2020 16:29, Tobias Frost wrote: > a short review: > > * New upstream release including plugin downloader. Closes: 948702 > > It is a privacy violation to download stuff. Do you inform your user about it? Not really. Do you think a patch is motivated? If so, for each and every plugin, or just for the first one? > Are the downloads somehow validated that it won't execute malicious / (MITM) > modified code? I'm fairly active upstream where these plugins are created. They all live on github, and the sources are available. The actual list of downloadable plugins (the plugin catalog) is kept under tight control upstream. > (It would be better if plugins of relevance would be packaged.) It's just not feasible. There are some 20 plugins, and just the administrative work is IMHO prohibitive. Also, the user experience is built around a workflow which does not fly using packaged plugins. > Consistency: in other changelog entries you write a #bugnumber, here only > bugnumer… > > * Add two plugin compatiblity patches (#1997). The lower numbers are upstream bugs. Sort of obvious, but only for me... Should the notation opencpn#1997 work? > Spelling error: > W: opencpn-plugins: spelling-error-in-changelog compatiblity compatibility Agreed, will fix > - d/copyright has some todos: "blushes" Will fix. > - compat-level is still at 12. Actually on purpose to make ubuntu backports somewhat easier. I could certainly upgrade if you feel that this is the correct decision. Sending this reply now so I hopefully can get some more input before doing real work. Again: thanks for reviewing! Cheers! --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Tue, 8 Sep 2020 19:05:21 +0200 Tobias Frost wrote: > > Not really. Do you think a patch is motivated? If so, for each and every > > plugin, or just for the first one? > > I'm not sure how plugins are installed. If there is an UI, the warning > could be presented in that gui. The basic workflow is similar to the browsers: User sees a list of possible plugins, points to plugin to install, it's downloaded and installed. It is certainly possible to patch this with a dialog showing some info, for example for the first installed plugin. I know the code good enough to make such a patch. All this said: do you think it's motivated to make such a patch? > I meant with Man in the Middle: There would be many possiblities for attacks… > If they are not protected by e.g a checksum, Malice one could > replace them, either in the repo or in transit. There is no gurantee > that binaries match the sources, as well, if not build in trusted enviorments > or somehow signed. … Checksum/signing is definitely on the agenda, the plugin system is still not mature. That said, as of today I think an attack needs to hijack either a github url (for the catalog) or some url on the cloudsmith deployment server. While certainly possible, it's probably not trivial To be honest, this is probably not the biggest attack surface on opencpn > "tight control upstream" somehow sounds that you control what plugins > can be installed. Just to make sure that we cover all those freedoms > we care about: I can have my own plugin installed, right? Yes, using an import function any plugin can be installed from disk. > OK, maybe, I'm not a user, so I can't tell. > However, you don't likely need _all_ plugins packaged… Focusing on the other aspect: the workflow (think of the browser's plugin systems) is really hard to implement when installation requires root privileges. Thinking about it, it might be possible to install from a .deb package, basically "downloading" from /usr/lib instead of an url. Might be worth an upstream bug. Not sure how much user-value this would add, though. Will file upstream bug. > Packaged plugins have advantages too, because > the packaging system can be your friend: We have had these discussions in depth. Also, as you might noticed, I'm not completely new to packaging. Yes, they have advantages. But in the opencpn context the cons weighs more. It's the combination of user experience, the need to install as a regular user, multiple linux distros and administrative work. It's certainly not a binary black and white decision. But, it is a decision. > How are you planning to support all the architecures Debian supports? The plugins uses a CI build chain which supports the core architectures. Plugins are built and uploaded automatically. They become available to users when url and metadata is included in the catalog -- this is semi-automatic process ending up in a PR against the catalog. > Welcome, and sorry for being too Debianite ;-) No need for apologies, discussions are always good. If I required an apology for these remarks I should probably not be in this business...:) As a result I will file two upstream bugs. And perhaps make a patch, if you deem it motivated. All good things. > Your plugin approach is not how we usually do things here… I know. But still not unheard of, the browsers comes to mind. Now, I need to do some work. Will unfortunately not happen today, need to prepare for work tomorrow. Cheers! --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Tue, 8 Sep 2020 21:01:47 +0200 Tobias Frost wrote: > On Tue, Sep 08, 2020 at 08:10:48PM +0200, Alec Leamas wrote: >> On Tue, 8 Sep 2020 19:05:21 +0200 Tobias Frost wrote: >> All this said: do you think it's motivated to make such a patch? > > I guess. (Again being Debianite ;-)) OK, will do. Being Debianite is your role here, right?! > Debianites are generally very sensitive about privacy, so any feature that > "calls home"* feature is usually frowned upon; And this is kind of a side > effect of a plugin manager that pulls stuff from the Internet… I see the arguments and concur. >> The plugins uses a CI build chain which supports the core architectures. >> Plugins are built and uploaded automatically. They become available to >> users when url and metadata is included in the catalog -- this is >> semi-automatic process ending up in a PR against the catalog. > > For Debian core architecures means > https://wiki.debian.org/DebianBuster#Architectures Just after pushing the Send button I knew that referring to Debian core architectures was wrong. Our users basically either uses a PC or some raspberry device; we support x86_64 and armhf when it comes to plugins. Now, this should not really change anything. OpenCPN is perfectly usable without any plugins, and builds fine on all Debian core platforms (sic!) Cheers! --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi, A new version is uploaded to mentors. Time to reset the history. Changes since last round: - New warning dialog for downloading binary plugin content (patch). - Spelling error fixed - Removed references to upstream bugs. I think it's a pity, the references linked patches in d/patches to upstream bugs. - Fixed the d/copyright mess. - Left compat level at 12 according to discussion. Thoughts? Cheers! --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Wed, 9 Sep 2020 22:53:37 +0200 Alec Leamas wrote: > Hi, > > A new version is uploaded to mentors. Time to reset the history. Changes > since last round: ... Dammit. There's still one copyright for src/gshhs.cpp to fix. I'm on it, but holding next upload until I hear from you. "Annoyed" --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Wed, 9 Sep 2020 18:44:17 +0200 Tobias Frost wrote: > On Wed, Sep 09, 2020 at 07:39:38AM +0200, Alec Leamas wrote: > > > Now, this should not really change anything. OpenCPN is perfectly usable > > without any plugins, and builds fine on all Debian core platforms (sic!) > > Sounds good ;-) > > (And it can happen that someone is showing up later and packaging the > plugins for Debian, > who knows that in a volunteer project :-D) > > When your package is ready, don't forget to remove the moreinfo tag! Sorry, I missed your reply and sent two messages out of sync. I have removed the moreinfo tag (that interface *is* arcane!) As you should be aware, there is a new upload with an error I spotted. Can you see anything else, or should I just fix that and make a new round? Cheers! --alec PS: My Englisch is not what it should be, and if you have a better proposal for the message in the 0008-... patch I would certainly prefer to use that... DS
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Thu, 10 Sep 2020 07:46:32 +0200 Tobias Frost wrote: > On Wed, Sep 09, 2020 at 11:08:53PM +0200, Alec Leamas wrote: > > On Wed, 9 Sep 2020 22:53:37 +0200 Alec Leamas wrote: > just go ahead and update the package on mentors. Done. --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Tobias, On Thu, 10 Sep 2020 08:06:10 +0200 Tobias Frost wrote: > On Wed, Sep 09, 2020 at 11:08:53PM +0200, Alec Leamas wrote: > > On Wed, 9 Sep 2020 22:53:37 +0200 Alec Leamas wrote: > > Dammit. There's still one copyright for src/gshhs.cpp to fix. I'm on it, > > but holding next upload until I hear from you. > > PS: Hints to make your life easier: > - there are tools that might help https://wiki.debian.org/CopyrightReviewTools > (probably you know already, as some lines look tool-generated ;-) Yes, as Fedora packager I've been using licensecheck since too many years. And once you have been able to set up cme it's a great tool. However, current fixes is basically wrapping up after some cme wrongdoing. To maintain a copyright file like this manually would be , well, interesting... [snip] > Hope that helps a bit. It does (thanks!), taking it with me to next release. However, keeping delta small at this point. Cheers! --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Thu, 10 Sep 2020 05:12:34 -0400 The Wanderer wrote: > On 2020-09-10 at 01:45, Tobias Frost wrote: > > > On Wed, Sep 09, 2020 at 10:53:37PM +0200, Alec Leamas wrote: > > > > Well, actually, all those lines probably should be removed: > > debian/changelog is intended to record changes to the packaging part > > only, it is not to record changes made upstream; more generally: Only > > stuff that changes files in the debian directory should be mentioned > > in d/changelog. (See > > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog > > for some better/more accurate wording in the Policy) > > I'm not sure I read that section as meaning that. Could you point more > specifically to the exact wording there which you understand as > reflecting this rule? > > Regardless, I'm fairly sure there are exceptions to this in practice. > For example, if a new upstream release includes a change which closes an > open Debian bug report or fixes a particular CVE, a notation in the > changelog recording that fact seems to be de rigueur, and in fact as I > understand matters the tooling recognizes and parses notes such as > "Closes: #123456" or "CVE-1000-123-1234" to auto-close the given bug > report or to mark a newly-packaged version as unaffected by the given > CVE. > > For that matter, look at the Linux kernel packages > (linux-image-VERSION-ARCH, among others). They don't seem to ship a > changelog.Debian.gz, but the changelog.gz which they do ship seems to be > This seems to be a Deep Philosophical Discussion between Debian Developers. I should thus basically stay quiet, but I feel the discussion is a little bit off in this case. I'm working tight with upstream, so the upstream/downstream boundaries are a little obscured. The references was a result (all cases) of a workflow like - Packaging, I find a bug and make a patch in d/patches - The bug is filed upstream. - The patch is converted to an upstream PR. - The PR is merged on upstream master branch, to be included in next release. - The patch in d/patches is updated with DEP-5 info (yes, did that). - The line in the changelog is (was) updated with the upstream bug #. So, these references stem from my downstream work. They do (did) *not* reference anything in the release tag, only changes after that. Having these lines, with or without upstream references is no big thing, at least not for me. Just trying to clarify Cheers! --alec
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 t
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#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#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
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: > 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 * Done, as well as some general cleanup. Nothing about patches is overridden, things became so much easier after updating sid thus getting rid of what might have been multiple lintian bugs.Still overriding warnings about get-orig-source and doc files used in runtime. Personally, I find the comments used in the override files a nice way to document things which looks peculiar in the package. In the end it's a choice, I guess. > You should looking into setting up sbuild, pbuilder or some of that kind tools: > This will allow you to build in a clean enviornment without the need to have I'm using cowbuilder. But then again, it must also be updated. I'm probably damaged by my Fedora roots, where corresponding tools just sort of works. Need to learn. Uploading a new version. Timestamp at mentors: 2020-09-14 07:53 Cheers! --alec
Re: Questions about buildinfo
On 22/09/2020 10:29, Tobias Frost wrote: > Hi mentors, > - Forwarded message from Alec Leamas - > > Date: Sun, 20 Sep 2020 20:56:57 +0200 > From: Alec Leamas > To: Tobias Frost > Subject: cxx-serial > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 > Thunderbird/68.11.0 > > Hi! > > I have uploaded the one you pointed out as needing some love at > mentors: https://mentors.debian.net/package/libcxx-serial/. > > I have problems with the debugging info containing the local build path > and the buildinfo. Status: > > As uploaded, the Build-Path stanza is not part of buildinfo. As I > understand it, this is inconsistent with the local build path in the > debug package which does exist (and is really hard to get rid of). > > A plain 'dpkg-genbuildinfo --always-include-path ' does include > Build-Path in the buildinfo > > Using DEB_BUILD_OPTIONS as documented in dpkg-genbuildinfo(1) generates > a warning message and does not include the Build-Path: > > $ DEB_BUILD_OPTIONS="+path" dpkg-genbuildinfo > dpkg-genbuildinfo: warning: invalid flag in DEB_BUILD_OPTIONS: +path > dpkg-genbuildinfo: warning: invalid flag in DEB_BUILD_OPTIONS: +path > > $ grep Build-Path ../libcxx-serial_1.2.1-2_amd64.buildinfo > $ > > Perhaps you can shed some light on this? > - End forwarded message > See also: https://wiki.debian.org/ReproducibleBuilds/History#Giving_up_on_build_paths Cheers! --alec
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "libcxx-serial": * Package name: libcxx-serial Version : 1.2.1-2 Upstream Author : William Woodall wjww...@gmail.com * URL : https://github.com/wjwwood/serial * License : Expat, BSD-3-clause * Vcs : https://gitlab.com/leamas/cxx-serial Section : libs It builds two binary packages: libcxx-serial1 - Cross-platform, Serial Port library written in C++ (runtime) libcxx-serial-dev - Cross-platform, Serial Port library written in C++ (devel) More info: https://mentors.debian.net/package/libcxx-serial/ Or, using dget: dget -x https://mentors.debian.net/debian/pool/main/libc/libcxx-serial/libcxx-serial_1.2.1-2.dsc Changes since the last upload: libcxx-serial (1.2.1-2) unstable; urgency=medium . * Drop v8stdint.h header (not used in Debian). Closes: #921697 * Update python-catkin-pkg BR to python3. * Standards-version -> 4.5.0, no changes. * Update dephelper-compat -> 12 * Set Rules-Requires-Root * Add d/upstream/metadata * Handle DEB_BUILD_OPTIONS when overriding test target. * Clean up test target in d/rules, * Simplify d/rules using --buildsystem=cmake. * Reorganize repo branches according to dep-14. * Fix lingering templates in d/watch. * New local patches: - Drop v8stdint.h header (above) - Make build verbose. * Cherry-picked upstream bugfix patches: - Fix SerialImpl constructor resource leak. - Handle 500kpbs serial ports. - Plug memory leak in exceptions. - Use MONOTONIC clock. See also separate question on local build paths in the debug info: https://lists.debian.org/debian-mentors/2020/09/msg00243.html Regards, --Alec Leamas
Bug#970712: tags 970712 - moreinfo
tags 970712 - moreinfo
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Hi, On 22/09/2020 11:47, Tobias Frost wrote: > Control: tags -1 moreinfo Cleared > On Tue, Sep 22, 2020 at 10:58:26AM +0200, Alec Leamas wrote: > > Hi Alec, > > To avoid confustion, I'm comparing the version in the archive (1.2.1-1.1) with > yours, in case you missed the NMU. Which is exactly what I did... > - d/changelog you need to include the changelog of the NMU in your > changelog. Done > - d/copyright: Can you add the upstream contact? Done > You probably also want to update the years on the debian section. Done > - d/control: you re-adding python-catkin-pkg as B-D. Is it needed? > (asking, as #943082 says no) Indeed. Dropped. > - d/rules: in the dh_override_auto_configure: you don't need to repeat > the buildsystem parameter. Done. > - (not required for upload) > not sure if you really need the 0007 patch; verbose builds should be > enabled automatically. (If not, you probably want to pass > -DCMAKE_VERBOSE_MAKEFILE=On the dh_override_auto_configure > (patches patching CMakeLists.txt will break on every upstream release, >in my experience. Or TL;DL: It's PITA). Silly one, this. Of course it should be done using a parameter to cmake rather than a patch. Fixed. I need to upstream the CMake changes, there is actually a lot. But it's a bit complicated, need to refactor the first patch into separate, manageable ones. OTOH, upstream doesn't seem to release that often. > For later (as this requires a trip though NEW), maybe you want to put > the doxygen documentation on a arch:all -doc package? Hm... I know I actually considered this. On Fedora, the separate -doc package is a nobrainer. However, I have understood that on Debian "too" small packages are not really welcome. Here, the docs are about 450K in 40 files. Is this enough for a package to not be too small? What is really "small" in this context? > Only minor changes required ;-) Good job! hmpf. Missing the NMU wasn't minor, for sure. "depressed" Cannot upload to mentors: $ dput -f mentors ../libcxx-serial_1.2.1-2_source.changes Checking signature on .changes gpg: ../libcxx-serial_1.2.1-2_source.changes: Valid signature from 0A1DA7134E068B4C Checking signature on .dsc gpg: ../libcxx-serial_1.2.1-2.dsc: Valid signature from 0A1DA7134E068B4C Uploading to mentors (via ftp to mentors.debian.net): Uploading libcxx-serial_1.2.1-2.dsc: 553 Could not create file. Leaving existing libcxx-serial_1.2.1-2.dsc on the server and continuing And now, what? "confused" Many thanks for reviewing! Cheers! --alec PS: As long as it is possible in any way, I'm avoiding the NEW queue. Have been waiting there more than a year... DS
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Hi again, On 22/09/2020 12:51, Alec Leamas wrote: > Cannot upload to mentors: > > $ dput -f mentors ../libcxx-serial_1.2.1-2_source.changes > Checking signature on .changes > gpg: ../libcxx-serial_1.2.1-2_source.changes: Valid signature from > 0A1DA7134E068B4C > Checking signature on .dsc > gpg: ../libcxx-serial_1.2.1-2.dsc: Valid signature from 0A1DA7134E068B4C > Uploading to mentors (via ftp to mentors.debian.net): > Uploading libcxx-serial_1.2.1-2.dsc: 553 Could not create file. > Leaving existing libcxx-serial_1.2.1-2.dsc on the server and continuing Some kind of transient error. A new upload is available, timestamp on mentors: 2020-09-22 11:08 (#4) Cheers! --alec
Re: Questions about buildinfo
On 22/09/2020 16:05, Mattia Rizzolo wrote: > Hi Alec, > > On Tue, Sep 22, 2020 at 10:48:39AM +0200, Alec Leamas wrote: >>> I have problems with the debugging info containing the local build path >>> and the buildinfo. Status: [snip] > You misread the dpkg-genbuildinfo(1) manpage, the correct env var would > be > > DEB_BUILD_OPTIONS=buildinfo=+path > > (in general, the format of DEB_BUILD_OPTIONS is a space separated list > of options followed by their value after the = sign) > > However, what you are seeing is likely a byproduct of how your are doing > your builds. If you run your build in pbuilder or sbuild, the build > would happen in a path starting with /build/, and dpkg would include > that path. That's done as to not leak the personal local paths which > might include details you might not want to disclose. > However, as you likely noticed, that path is also embedded in some > compiled files; if you would like to remove them you might try to build > specifying (see dpkg-buildflags(1)): > DEB_BUILD_MAINT_OPTIONS=reproducible=+fixfilepath > We are in the process of making this flag a default of the debian > toolchain. Thanks for sorting this out! Had a hard time trying to wrap my head around it until your explanation... Cheers! --alec
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
On 22/09/2020 13:52, Tobias Frost wrote: > Uploading right after this mail with this cosmetic change: > > l-1.2.1_orig/debian/changelog libcxx-serial-1.2.1/debian/changelog > --- libcxx-serial-1.2.1_orig/debian/changelog 2020-09-22 13:46:47.366672711 > +0200 > +++ libcxx-serial-1.2.1/debian/changelog 2020-09-22 13:50:03.325964836 > +0200 > @@ -13,7 +13,6 @@ >* Fix lingering templates in d/watch. >* New local patches: > - Drop v8stdint.h header (above) > - - Make build verbose. >* Cherry-picked upstream bugfix patches: > - Fix SerialImpl constructor resource leak. > - Handle 500kpbs serial ports. > > > As always, thanks for your contributions! And thanks for your thoughtful review, uploading and not least fixing my last nitpicks! Cheers! --alec
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Hi Gianfranco,
On 23/09/2020 10:59, Gianfranco Costamagna wrote:
Hello,
just FYI, the upload fails on i386
https://buildd.debian.org/status/fetch.php?pkg=libcxx-serial&arch=i386&ver=1.2.1-2&stamp=1600846376&raw=0
Due to a difference between i686 and i386
The change in gst-omx might fix this problem
gst-omx (1.18.0-2) unstable; urgency=low
.
* debian/gst-omx-listcomponents.install and debian/rules:
Use ${DEB_HOST_GNU_TYPE} instead of ${DEB_HOST_MULTIARCH} to fix FTBFS
on i386.
HTH
libcxx-serial_1.2.1-3 is uploaded to mentors, available Real Soon (tm).
In haste,
--alec
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Hi again, On 23/09/2020 11:27, Alec Leamas wrote libcxx-serial_1.2.1-3 is uploaded to mentors, available Real Soon (tm). In haste, --alec Too much haste, new version uder way, need to wait for mentors to settle. Correct fix is available in my gitlab repo. In even more haste, --alec
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
On 24/09/2020 10:34, Tobias Frost wrote: > Control: tags -1 moreinfo > Control: reopen -1 > > On Thu, Sep 24, 2020 at 09:29:58AM +0200, Alec Leamas wrote: >> Hi again, >> >> On 24/09/2020 09:07, Alec Leamas wrote: > (Looking at the -dev package: they use a quite common filename (serial.h) > without subdirectory in /usr/include. I wonder if there are collisions > in the archvie…) If not, it would be because other packages are sane. This one is certainly not in this sense. Needs to be fixed (see below) > - Typo in d/changelog: s/FTBS/FTBFS/ Fixed. That was actually no typo, for some reason I have always used FTBS although it's obviously wrong. > - Please add the patch I sent in #970712#39… /me wants back to Fedora, where the only way to change a package is a commit in the dist-git repo. NMUs and free-running patches, I miss them all. OTOH, now I have now learnt and it will never happen again. "cough" New package on mentors: #4, timestamp:2020-09-24 11:08 There is a need for a bigger rewrite: - Refactor the cmake patch(es) - Add a doc subpackage. - Don't install serial.h directly under /usr/include. Please feel free to file a bug or two; I'm on it anyway (although perhaps not exact now). Cheers! --alec
Touching $HOME in postrm
Dear list, Touching files under $HOME in a postrm script is obviously a bad idea. However, a colluegue insists in trying to make me do this. Just to resolve this issue: is the the limitations on what files which can be touched by a packaging script documented somewhere? I have been skimming through the Policy Manual, but no luck. Did I miss something? Is it somewhere else? Or is it just an undocumented "good judgment" thing? Any clue, out there? Cheers! --alec
Re: Touching $HOME in postrm
Hi, Thanks for taking time to reply to this strange issue... On 04/05/2021 08:39, Andrey Rahmatullin wrote: > On Tue, May 04, 2021 at 04:46:42AM +0200, Alec Leamas wrote: >> Touching files under $HOME in a postrm script is obviously a bad idea. >> However, a colluegue insists in trying to make me do this. > Under which of the home dirs? Normally it just doesn't make sense to find > all real users and then find and access their homedirs, especially taking > into account various complex setups. >> Just to resolve this issue: is the the limitations on what files which >> can be touched by a packaging script documented somewhere? >> >> I have been skimming through the Policy Manual, but no luck. Did I miss >> something? Is it somewhere else? Or is it just an undocumented "good >> judgment" thing? > I think it's the latter, together with what I said above. On 04/05/2021 08:54, Geert Stappers wrote: > Describe the original goal, tell what you want to achieve. > Why the need for touching files under $HOME. It's certainly not what *I* want to achieve... Anyway, your replies are most useful to sort out this situation. I will invite my colleague pursue his arguments here, should he feel he needs more input. Again: thanks for your replies! Cheers! --alec
Re: Question about writing systemd unit for old package
Hi, On 20/05/2021 03:35, Paul Wise wrote: > On Wed, May 19, 2021 at 8:51 AM Richard Hector wrote: > >> Does that not depend on whether it does anything before dropping >> privileges? For example, a webserver can bind to low ports before >> dropping privilege. I imagine if the systemd service unit specified >> running as (eg) www-data, that wouldn't work. > > I don't know the details, but I think systemd can open the ports and > transparently pass them to the unprivileged process when it is spawned > without any data loss, in a similar way to the inetd stuff used to > work. http://0pointer.de/blog/projects/socket-activation.html Cheers! --alec
Bug#997793: RFS: libcxx-serial/1.2.1-5 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "libcxx-serial": * Package name: libcxx-serial Version : 1.2.1-5 Upstream Author : wjww...@gmail.com * URL : http://wjwwood.io/serial/ * License : Expat, BSD-3-clause * Vcs : https://gitlab.com/leamas/cxx-serial Section : libs It builds two binary packages: libcxx-serial-dev - Cross-platform, Serial Port library written in C++ (devel) libcxx-serial1 - Cross-platform, Serial Port library written in C++ (runtime) More info at: https://mentors.debian.net/package/libcxx-serial/ or using dget -x https://mentors.debian.net/debian/pool/main/libc/libcxx-serial/libcxx-serial_1.2.1-5.dsc Changes since the last upload: libcxx-serial (1.2.1-5) unstable; urgency=medium . * Handle uninstalled cmake configuration files. Closes: #997732 This is simple, bugfix release. Regards, -- Alec Leamas
Re: How to include the .git folder in a source package's .tar.xz archive?
On 29/10/2021 07:35, Tobias Frost wrote: On Thu, Oct 28, 2021 at 09:02:21PM -0500, Hunter Wittenborn wrote: The problem is that whenever I (and the other guy) build the program with something like debuild, the resulting .tar.xz archive doesn't contain the .git repository in which the 'debian/' folder is contained. I've attempted to do some Googling, but I didn't get much of anywhere with it (I actually got some answers on how to do the opposite for some reason :P). Anything I could try? For the packaging, I'd implement to retrieve the timestamp from d/changelog. (e.g. using dpkg-parsechangleog). Possibly you want to prepare your build system that it accepts injecting this timestamps.) Note that the Debian packaging, when the maintainer uses git for that, resides in its own git repository; even if it is now on the same place, this might change (e.g. if package maintainer changes). Best is you consider that already now and dont rely on the git repo. to be (See https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source to keep debian/) Other solutions could be creating a file like VERSION with relevant git data and add that to the distribution. That file can normally not be checked into git, it's a chicken and egg problem. The solution is to add the logic to autoconf/cmake/whatever is used. Also, git has provisions for substituting keywords like date and hash when checking out data. However, this is in my opinion utterly messy to handle. See git-attributes(1) --alec
Bug#1001494: RFS: opencpn/5.6.0+dfsg1-1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.0+dfsg1-1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-2+, public-domain, GPL-3+, SGI-B-1.1, SGI-B-2.0, Expat, GPL-3, LGPL-2+, Expat or GPL-2+, GPL-2, BSD-3-clause, wxWidgets * Vcs : https://gitlab.com/leamas/opencpn Section : misc It builds those binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info: https://mentors.debian.net/package/opencpn/ Or using dget: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.0+dfsg1-1.dsc This is a maintenance release. Changes since the last upload: opencpn (5.6.0+dfsg1-1) unstable; urgency=medium . * New upstream release * Drop upstreamed patches * Update standards-version to 4.6.0, no changes. * Drop repck suffix, dfsg1 -> dfsg * Update compat-level to 13, drop override_dh_missing from rules. * Drop walk-around for #831870 using zip download, clean up d/rules and d/watch Regards, -- Alec Leamas
Bug#1001494: RFS: opencpn/5.6.0+dfsg1-1 -- Open Source Chartplotter and Marine GPS Navigation Software
CC: to bug as well to keep discussion visible On 12/12/2021 11:16, Bastian Germann wrote: Copy to make sure you have received the remarks. d/changelog === Please remove the 5.2.4.210213gitcad0d456+dfsg1-1 entry. It was never uploaded to the archive. Done, finally d/copyright === There are four debian/opencpn* files listed. This does not make sense. Please list the source files, e.g. data/tcdata/harmonics-dwf-20210110-free.tcd instead of debian/opencpn-data/DEBIAN/md5sums with a line referring to usr/share/doc/opencpn-data/harmonics-dwf-20210110-free.tcd.gz. Having debian/opencpn-data/ files in d/copyright is of course not only wrong but stupid. These are generated and not part of the source package "ashamed". Why do these things show up in your new version? They are not in the 5.2.4+dfsg-1. Because I used cme to update the copyright which I suppose basically is fine. However, what I missed was to make at least a superficial review of the changes. Also, I obviously ran cme on a tree which wasn't clean, shouldn't do that. The core problem is that I just don't do these things often enough to not make simple mistakes like these. Control: tags -1 moreinfo Please untag moreinfo when you have provided a fixed version. Done, at least I hope so. Again, I'm no debian packaging wizard, for sure. Thanks for your patience! --alec
Bug#1001494: RFS: opencpn/5.6.0+dfsg1-1 -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Bastian, Just a ping. Any chance we can push things forward here? Happy Xmas! --alec
Bug#1002719: RFS: opencpn/5.6.0+dfsg1-1~bpo11+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.0+dfsg1-1~bpo11+1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-2+, public-domain, GPL-3+, SGI-B-1.1, SGI-B-2.0, Expat, GPL-3, LGPL-2+, Expat or GPL-2+, BSD-3-clause, wxWidgets * Vcs : https://gitlab.com/leamas/opencpn Section : misc It builds those binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) This is about backporting 5.6.0 which was recently accepted into sid. It's my first attempt on backporting, so all sorts of mistakes are possible. The backport checklist: - Package has a substantial user base. However, most of them are using the Ubuntu package sine the Debian packaging historically has been missing or outdated. - 5.6.o is a major update. - Package is accepted into sid and migrated to testing/Bookworm. - Package builds with a small delta (below). - I also did the work with the Sid version. More info: https://mentors.debian.net/package/opencpn/ or dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.0+dfsg1-1~bpo11+1.dsc Changes since the last upload: opencpn (5.6.0+dfsg1-1~bpo11+1) bullseye-backports; urgency=medium . * Rebuild for bullseye-backports. * Changes to Vcs-git in control and default branch in gbp.conf. Regards, -- Alec Leamas
Bug#1002992: sub...@bugs.debian.org
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wxsvg": * Package name: wxsvg Version : 2:1.5.23+dfsg-1 Upstream Author : Alex Thuering * URL : http://wxsvg.sourceforge.net/ * License : wxWindows * Vcs : https://salsa.debian.org/multimedia-team/wxsvg Section : libs It builds those binary packages: libwxsvg3 - SVG library for the wxWidgets toolkit libwxsvg-tools - SVG library for the wxWidgets toolkit (tools) libwxsvg-dev - Development files for wxSVG This is a minor update triggered by a new upstream version. More info: https://mentors.debian.net/package/wxsvg/ or using dget -x https://mentors.debian.net/debian/pool/main/w/wxsvg/wxsvg_1.5.23+dfsg-1.dsc Changes since the last upload: wxsvg (2:1.5.23+dfsg-1) unstable; urgency=medium . * New upstream version * d/watch: dfsg.1 -> dfsg (lintian warning) * d/control: Allow builds against wxWidgets 3.1 * d/control: Standards-version: 4.5.0 -> 4.6.0, no changes. * Add patch for separate -latomic library causing sh4 build errors.
Bug#1002992: sub...@bugs.debian.org
Made a new upload to mentors after syncing my git tree with salsa. Basically means that the VCS headers which was broken now should be OK --alec
Bug#1003214: RFS: opencpn/5.6.0+dfsg0-1~bpo10+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.0+dfsg0-1~bpo10+1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-2+, public-domain, GPL-3+, SGI-B-1.1, SGI-B-2.0, Expat, GPL-3, LGPL-2+, Expat or GPL-2+, BSD-3-clause, wxWidgets * Vcs : https://gitlab.com/leamas/opencpn Section : misc It builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info: https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.0+dfsg0-1~bpo10+1.dsc Changes since last upload: opencpn (5.6.0+dfsg0-1~bpo10+1) buster-backports-sloppy; urgency=medium . * Rebuild for buster-backports-sloppy. * Update VCS urls and gbp.conf default branch * Downgrade debhelper compat, 13 -> 12 * Drop libwxsvg build dep * Don't strip libwxsvg in d/copyright, repack sources with bundled library in place. Use dfsg0 to make it precede dfsg1 in bullseye. Regards, -- Alec Leamas
Bug#1003214: RFS: opencpn/5.6.0+dfsg0-1~bpo10+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Tobias, On Thu, 06 Jan 2022 16:59:00 +0100 Tobias Frost wrote: > Control: tags -1 moreinfo > > Hi Alec, > if you dont remove it using Files-Excluded, you need to document libwxsvg's > copyright in d/copyright... > Indeed, good catch! I have uploaded a new build to mentors. Cheers! --alec
Bug#1004134: RFS: ddupdate/0.6.6-1 -- Tool updating DNS data for dynamic IP addresses
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate": * Package name: ddupdate Version : 0.6.6-1 Upstream Author : https://github.com/leamas/ddupdate/issues * URL : https://github.com/leamas/ddupdate * License : Expat * Vcs : https://github.com/leamas/ddupdate/tree/debian Section : net It builds one binary packages: ddupdate - Tool updating DNS data for dynamic IP addresses More info at https://mentors.debian.net/package/ddupdate/ or using: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.6-1.dsc Changes since the last upload: ddupdate (0.6.6-1) unstable; urgency=medium . * New upstream bugfix release * Drop upstreamed FTBFS setup.py patch This is minor update to a standard python package, nothing complicated. Regards, -- Alec Leamas
Bug#1004134: RFS: ddupdate/0.6.6-1 -- Tool updating DNS data for dynamic IP addresses
On Sat, 22 Jan 2022 14:41:09 +0100 Bastian Germann wrote: > On Fri, 21 Jan 2022 16:08:31 +0100 Alec Leamas wrote: > > Changes since the last upload: > > > > ddupdate (0.6.6-1) unstable; urgency=medium > > . > > * New upstream bugfix release > > * Drop upstreamed FTBFS setup.py patch > > > > This is minor update to a standard python package, nothing complicated. > > Thanks for providing this update! > On 22/01/2022 16:12, Bastian Germann wrote: > Am 22.01.22 um 15:36 schrieb Debian FTP Masters: >> Version check failed: >> Your upload included the source package ddupdate, version 0.6.6-1, >> however unstable already has version 0.6.6-1. >> Uploads to unstable must have a higher version than present in unstable. > > Adam was faster than me... Thanks to all of you for uploading! Cheers! --alec
Bug#1009723: RFS: opencpn/5.6.0+dfsg0-1~bpo10+2 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.0+dfsg0-1~bpo10+2 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0 * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds the two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info on https://mentors.debian.net/package/opencpn/ or using: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.0+dfsg0-1~bpo10+2.dsc This is a bugfix update of an existing sloppy backport. Changes since the last upload: opencpn (5.6.0+dfsg0-1~bpo10+2) buster-backports-sloppy; urgency=medium . * Link to gtk2 instead of gtk3 to match available plugins. Closes: #1009701 * Add upstream patches to make it possible to define the target as a compile time constant. * Add patch to avoid getting multiple possible plugins to load besides the Debian version. Regards, -- Alec Leamas
Bug#1010187: RFS: opencpn/5.6.2+dfsg-1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.2+dfsg-1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0 * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info: https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1.dsc This is a bugfix upstream release, basically without any new functionality. Changes since the last upload: opencpn (5.6.2+dfsg-1) unstable; urgency=medium . * New upstream release. * Remove upstream debian packaging in source tarball. * Add patch for wrong desktop filename (tracker.debian.org warning). * d/rules: Add explicit CMAKE_BUILD_TYPE setting (upstream discussion in https://github.com/OpenCPN/OpenCPN/issues/2612) * d/watch: dfsg1 -> dfsg (lintian warning) * d/control: Add missing -b branch to Vcs-Git: * d/control: Make opencpn-data Multi-arch: foreign (tracker.debian.org warning). * d/copyright: Remove unused GPL-2 license. Regards, -- Alec Leamas
Bug#1010223: RFS: opencpn/5.6.2+dfsg-1~bpo11+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.2+dfsg-1~bpo11+1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0 * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info: https://mentors.debian.net/package/opencpn/ or using: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1~bpo11+1.dsc This is a backport to Bullseye. The sid version builds more or less out of the box, the delta is minimal. Changes since the last upload: opencpn (5.6.2+dfsg-1~bpo11+1) bullseye-backports; urgency=medium . * Initial bullseye backport of 5.6.2+dfsg-1 Regards, -- Alec Leamas
Backport version number problem.
Dear list, I'm about to backport opencpn from Sid to backports-sloppy, running into versioning problems. The Sid version is 5.6.2+dfsg-1. The sloppy version should then be something like 5.6.2+dfsg-1~bpo10.1. However, it has been necessary to repack the backport. This is a about a dependency which is available in Bullseye+, but not in Buster. OTOH, the library is bundled in the upstream source, so solution becomes to repack the sources with the bundled library present. The backport version then becomes something like 5.6.2+dfsg2-1~bpo10.1. But this sorts after the Sid version 5.6.2+dfsg-1, right? Making it a Bad Backport Version. Has anyone ideas how to handle this? Cheers! --alec
Bug#1010540: RFS: opencpn/5.6.2+dfsg-1~bpo10+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.2+dfsg-1~bpo10+1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0 * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds the following two packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1~bpo10+1.dsc Changes since the last upload: opencpn (5.6.2+dfsg-1~bpo10+1) buster-backports-sloppy; urgency=medium . * Initial buster backport of 5.6.2+dfsg2. * Rebase and renumber patches. * Add 1.2M patch restoring bundled wxsvg library since system libwxsvg is not available on buster (handled by repacking in 5.6.0). Regards, -- Alec Leamas
Bug#1010865: RFS: opencpn/5.6.2+dfsg-1~bpo11+2 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.2+dfsg-1~bpo11+2 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-2+, GPL-3+, wxWidgets, Expat or GPL-2+, SGI-B-1.1, GPL-3, Expat, SGI-B-2.0, LGPL-2+, public-domain, BSD-3-clause * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info on https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1~bpo11+2.dsc This is a pretty urgent bugfix release for the existing Bullseye backport. Changes since the last upload: opencpn (5.6.2+dfsg-1~bpo11+2) bullseye-backports; urgency=medium . * Add patch fur unusable buildd version. Closes: #1010860 Regards, -- Alec Leamas
Bug#1010905: RFS: lirc/0.10.1-7 [RC] -- Infra-red remote control support - daemons and utils
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "lirc": * Package name: lirc Version : 0.10.1-7 Upstream Author : Alec Leamas * URL : https://sf.net/p/lirc * License : MIT, GPL-2.0+ * Vcs : https://gitlab.com/leamas/lirc Section : utils The source builds the following binary packages: lirc - Infra-red remote control support - daemons and utils lirc-doc - Infra-red remote control support - website and manual docs liblirc0 - Infra-red remote control support - Run-time libraries liblircclient0 - Transitional placeholder for obsoleted liblircclient0 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev liblirc-dev - Infra-red remote control support - development files liblirc-client0 - infra-red remote control support - client library lirc-x - infra-red remote control support - X utilities More info on https://mentors.debian.net/package/lirc/ or using: dget -x https://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.10.1-7.dsc Changes since the last upload: lirc (0.10.1-7) unstable; urgency=medium . * Add patch from Fedora for failing tests. Closes: #1009389 * Add patch avoiding build path in docs. Closes: #961954 Regards, -- Alec Leamas
keys
Dear list, I have recently become a DM for some packages. In the process I had to create a new 4096-bits gpg key since the one I have used earlier was just 2096 bits. So, I have basically one "old" 2096 bits key and a "new" 4096 bits one. I now need to upload to mentors, a package I'm not DM for. Of course, I want to retire my old key and use the new instead. However, when I try to my upload after signing with this key it is rejected with a message "No public key found". My new key id is E2EA41DCE2F8A99AD17A1E463A67D5D966D15C5C. It is available in the ubuntu keyserver and also in the Debian keyring. although I fail to verify the latter. Any clues out there? --alec
Bug#1014946: RFS: wxsvg/2:1.5.23+dfsg-2 [RC] -- Development files for wxSVG
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "wxsvg": * Package name: wxsvg Version : 2:1.5.23+dfsg-2 Upstream Author : Alex Thuering * URL : http://wxsvg.sourceforge.net/ * License : wxWindows * Vcs : https://salsa.debian.org/multimedia-team/wxsvg Section : libs The source builds the following binary packages: libwxsvg3 - SVG library for the wxWidgets toolkit libwxsvg-tools - SVG library for the wxWidgets toolkit (tools) libwxsvg-dev - Development files for wxSVG More info on https://mentors.debian.net/package/wxsvg/ or using dget -x https://mentors.debian.net/debian/pool/main/w/wxsvg/wxsvg_1.5.23+dfsg-2.dsc Changes since the last upload: wxsvg (2:1.5.23+dfsg-2) unstable; urgency=medium . * New patch for ffmpeg-5 FTBFS. Closes: #1004632. * d/control: Standards-version: 4.6.0 -> 4.6.1, no changes. Regards, -- Alec Leamas
mentors.debian.net: upload stuck
Dear list, I did something I should not have done: I uploaded a package without sources to mentors. Now, I cannot upload the correct package with sources, it seems that the bad one is in the way. The package is ddupdate-0.6.6-2. Is there anyone listening who can clear things on the mentors incoming queue? Or, will it happen automatically over time? Cheers, --alec
Re: mentors.debian.net: upload stuck
Hi Mattia, On 13/11/2022 19:21, Mattia Rizzolo wrote: On Sun, Nov 13, 2022 at 07:11:54PM +0100, Alec Leamas wrote: I did something I should not have done: I uploaded a package without sources to mentors. Now, I cannot upload the correct package with sources, it seems that the bad one is in the way. Is it, now? No, it seemingly has healed automatically. Thanks for taking time for silly me. Cheers! --alec
Bug#1024025: RFS: ddupdate/0.6.6-2 [RC] -- Tool updating DNS data for dynamic IP addresses
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "ddupdate": * Package name : ddupdate Version : 0.6.6-2 Upstream contact : https://github.com/leamas/ddupdate/issues * URL : https://github.com/leamas/ddupdate * License : Expat * Vcs : https://gitlab.com/leamas/ddupdate Section : net The source builds the following binary package: ddupdate - Tool updating DNS data for dynamic IP addresses More info at https://mentors.debian.net/package/ddupdate/ or using 'dget' with this command: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.6-2.dsc Changes since the last upload: ddupdate (0.6.6-2) unstable; urgency=medium . [Stefano Rivera] * New patch for bundled distutils in setuptools. Closes: #1022527 [Alec Leamas] * Move packaging to separate repo at gitlab This is a RC bugfix release on a straight-forward python package, nothing strange. On a sidenote, I would appreciate if someone who reviews and eventually uploads this package also perhaps could sponsor me so I could get package upload rights (have for some others). -- Alec Leamas
Bug#1024853: RFS: wxsvg/2:1.5.24+dfsg-1 [RC] -- Development files for wxSVG
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "wxsvg": * Package name : wxsvg Version : 2:1.5.24+dfsg-1 Upstream contact : Alex Thuering * URL :http://wxsvg.sourceforge.net/ * License : wxWindows * Vcs :https://salsa.debian.org/multimedia-team/wxsvg Section : libs The source builds the following binary packages: libwxsvg3 - SVG library for the wxWidgets toolkit libwxsvg-tools - SVG library for the wxWidgets toolkit (tools) libwxsvg-dev - Development files for wxSVG Further information onhttps://mentors.debian.net/package/wxsvg/ or using dget -xhttps://mentors.debian.net/debian/pool/main/w/wxsvg/wxsvg_1.5.24+dfsg-1.dsc Changes since the last upload: wxsvg (2:1.5.24+dfsg-1) unstable; urgency=medium . * New upstream release * Relinked to wxWidgets 3.2 Closes: #1019765. * Drop patch for building against ffmpeg5. * Fix renamed tag in lintian overrides. * Fix d/copyright and an override, lintian warnings.
Newbie: "Review request" on an updated LIRC package
Dear list,
This is my first contact with the Debian community. I might be doing all
sorts of errors, including sending a questionable message to the wrong
list. Just tell me, I'll listen.
I'm the upstream LIRC [2] maintainer. We are currently in the 0.9.4
cycle which tentatively will be released around Christmas. The debian
official packaging is stuck on 0.9.0, and we have thus decided to
provide a debian packaging upstream [1] so Debian users should have a
more modern version available,
I'm not seeking any argument as to why the Debian packages are still
0.9.0. It's the debian packager's decision. Full stop.
However, I'm all new to Debian packaging (although I have some RPM
experience). Because of that, I would really appreciate if someone on
this list could take a look at the current packaging and make an
informal review. I don't really know how to contribute in return, but if
someone by accident here needs help with an RPM package I'm here.
The package is not based on the current LIRC packages. The upstream is
so much changed that I thought it was better to make fresh start.
lintian is almost silent.
Cheers!
--alec
[1] https://leamas.fedorapeople.org/lirc/debian-pkg/
{2] https://packages.debian.org/jessie/lirc
Re: Newbie: "Review request" on an updated LIRC package
On 30/10/15 09:51, Leopold Palomo-Avellaneda wrote: > El Divendres, 30 d'octubre de 2015, a les 09:34:09, Alec Leamas va escriure: >> Dear list, >> >> I'm the upstream LIRC [2] maintainer. We are currently in the 0.9.4 >> cycle which tentatively will be released around Christmas. The debian >> official packaging is stuck on 0.9.0, and we have thus decided to >> provide a debian packaging upstream [1] so Debian users should have a >> more modern version available, >> >> I'm not seeking any argument as to why the Debian packages are still >> 0.9.0. It's the debian packager's decision. Full stop. >> >> However, I'm all new to Debian packaging (although I have some RPM >> experience). Because of that, I would really appreciate if someone on >> this list could take a look at the current packaging and make an >> informal review. I don't really know how to contribute in return, but if >> someone by accident here needs help with an RPM package I'm here.. > Hi Alex, Hi! Thanks for reply! > why not try to contact directly with the lirc maintainers? > > https://packages.qa.debian.org/l/lirc.html > > Also, lirc package has several bugs > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=lirc They have got a copy. However, they have basically not responded to anything lately, see e. g., [1]. Believe me, the decision to make an upstream package is not an easy one. Cheers! --alec [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777199
Re: Newbie: "Review request" on an updated LIRC package
On 30/10/15 09:51, Gianfranco Costamagna wrote: > Hi Alec, > >> >> I'm not seeking any argument as to why the Debian packages are still >> 0.9.0. It's the debian packager's decision. Full stop. > > > the argument might be: we were in the freeze because of jessie release at > that time, > so no new packages have been uploaded yet. FYI, 0.9.0 (current version) was released March, 2011. 0.9.1 happened June, 2014. > and the maintainer retired a few months ago. Ah... Cheers! --alec PS: Will process review remarks later. Thanks for those!
Re: Newbie: "Review request" on an updated LIRC package
On 30/10/15 12:45, Ghislain Vaillant wrote: > Just my 2 cents here but quoting d-mentors FAQ [1]: > > "There are cases where upstream ships a tarball which already contains a > debian directory. This is undesirable, even if you're upstream yourself > or can commit there. Keep the released tarballs (used as .orig.tar.gz) > and the debian directory separated." hm... from the same reference: > There's no need to remove the debian directory from their revision > control system (although if it's out of date they may decide to do so > anyway), but at the very least the directory shouldn't appear in releases. > If you are upstream yourself, well, you can ask yourself to do it. We don't plan to ship the debian subdir in the package tarball, but as a separate set of files (debian,.tar.gz, lirc_0.9.4.orig.tar.gz, *.dsc, *.build). Isn't this according to this what's actually suggested in that FAQ? Or did I miss something? That said, I completely agree it would be better if someone (preferebly with debian packaging skills) maintained an actual package. It's just that it seems unlikey to happen unless upstream does something (?) Cheers! --alec
Re: [cmake][multipackaging] best practices
On 04/11/15 10:28, Raffi Enficiaud wrote: > Le 04/11/15 09:50, Gianfranco Costamagna a écrit : >> Hi, generating debian files from cmake is not trivial, and I'm not >> sure I can answer here. > > Hi, > > Thank you for your reply! Would you please tell me what are the > difficulties? I have more the developer hat, and not the packager one, > and to me it is a bunch of "install" commands in cmake (with proper > components and location), and "make" + "make package". Hi! I'm a newbie here (no mentor!), and possibly get it all wrong. That said, my gut feeling is that this kind of functionality isn't really helpful. I have seen some examples on the RPM side. The basic problem is actually illustrated by Gianfranco's reply. Packaging is taking place in a community, in this case Debian. The community sets up rules makes and makes reviews. The rules, tools and processes evolves over time. At this point it is clear that you haven't really understood the community to the point you can create a package which conforms to the rules. Packaging is so much more than lumping a bunch of files in a container. BTW, splitting the /usr hierarchy into sub-packages is IMHO one of the smaller problems in this context. The first question you need to answer is if your generated packages conforms to the Debian Policy Manual. Do they? If they do, this is something new. I have yet not seen an automatically generated package which conforms to the given rules (Fedora experience). And that experience might be the reason no-one else replies :) Cheers! --alec PS Not understanding the Policy Manual is actually also my problem... DS
Help: Package upgrade blues.
Dear list, I cannot get my first package into shape - the upgrade paths fail. The sad story: New packages: liblirc0, liblirc-dev, lirc, lirc-x, lirc-doc Old packages lirc, lirc-x, liblircclient0, liblircclient-dev. New packages 'lirc' and 'liblirc0' together obsoletes old 'lirc'. Furthermore, liblirc0 obsoletes liblircclient0 and liblirc-dev obsoletes liblircclient-dev. Trying the split option #8 from [1] piuparts fails with too many messages for my limited brain (although in the middle of the session they seem to be installed OK). Has anyone some time to look into this? piuparts log is in [2], control file in [3]. What goes wrong here, and why? "scratching my head" Cheers! --alec [1] https://wiki.debian.org/PackageTransition [2] http://ur1.ca/o8hxw (piuparts log) [3] http://ur1.ca/o8hxy (control file) BTW: The undefined symbol is actually OK. DS
Bug#806815: RFS: lirc/0.9.4-devel-0.1 [NMU] -- Linux Infrared Remote Control
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lirc": * Package name: lirc Version : 0.9.4-devel Upstream Author : Christoph Bartelmus et. al. * URL : http://sf.net/p/lirc * License : GPLv2 and MIT Section : utils It builds those binary packages: lirc - Infrared remote control support - Daemons and utils lirc-doc - Infrared remote control support - Website and manual docs. liblirc0 - Infrared remote control support - Runtime libraries liblirc-dev - Infrared remote control support - Development files lirc-x - Infrared remote control support - X11 utilities To access further information about this package see: http://mentors.debian.net/package/lirc Alternatively, one can download the package with dget using: dget -x http://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.9.4-devel-0.1.dsc More information can be obtained from upstream website: http://sf.net/p/lirc Changes since the last upload: * Non-maintainer upload. * First shot on major upstream updates. - Re-packaged from scratch based on new dh primitives. - Thanks for help on debian-mentors! * New upstream release 0.9.4 - Release 0.9.1 .. 0.9.3 was never packaged. - This is an experimental, pre-release package. - Old 'lirc' service split into separate systemd services: lircd.service, lircmd.service and irexec.service. - New package structure: lirc, lirc-doc, liblirc0, liblirc-dev with corresponding upgrade path dependencies. - Fixes "Not updated to last version" (Closes: #777199). - Fixes "Default device for mode2 is /dev/lirc" (Closes: #702140). - Fixes "/var/run/lirc contents disappear..." (Closes: #676343). - Fixes "lircrcd segfaults" (Closes: #780062). - Fixes "'/etc/init.d/lirc restart' is broken" (Closes: #782091). - Fixes "Prompting due to modified conffiles..." (Closes: #655969). - Fixes "LIRC installs bad udev rule" (Closes: #804397). * Old lircd output socket link /dev/lirc dropped. Use /var/run/lirc/lircd. * Update compiler flags: -Wl,as-needed + hardening [Stefan Lippers-Hollmann] * Avoid negative architecture deps like [!hurd] (Closes: #634807) [Stefan Lippers-Hollmann] * Add patch 0007-tools-remove-configs-symlink.patch + explicit link to walk around #801719. * Changing Vcs-* headers to point to upstream packaging branch. Currently, this package is maintained by pkg-lirc-ma...@lists.alioth.debian.org which seems to be MIA. I have invoked the MIA procedure by sending message to the QA team. I have also requested to be member of this group. The packaging situation has been discussed: https://lists.debian.org/debian-mentors/2015/10/msg00487.html The update is disruptive and needs manual intervention: https://lists.debian.org/debian-devel/2015/11/msg00082.html Regards, --Alec Leamas
Bug#808249: RFS: libirman/0.5.1-1 [NMU]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libirman" * Package name: libirman Version : 0.5.1 Upstream Author : Tom Wheeley * URL : http://sourceforge.net/projects/libirman/ * License : GPLv2+ and LGPLv2+ Section : libs It builds those binary packages: libirman-dev - library for accessing the Irman InfraRed hardware libirman0 - Shared library to access the libirman hardware. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libirman Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libi/libirman/libirman_0.5.1-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: libirman (0.5.1-1) unstable; urgency=medium * Update to latest upstream, closes: #801588. * Handle conditional build of lirc plugin when lirc >= 0.9.4. -- Alec Leamas Wed, 11 Nov 2015 18:16:26 +0100 Regards, Alec Leamas
Re: Failed to stop defining RPATH in libncl
On 04/01/16 11:40, Andreas Tille wrote: Oops... by mistake, I replied to -devel. Here is the reply in correct list. Hi, I'm trying to package libncl[1] but I failed to fight the following lintian error: E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter /usr/lib/x86_64-linux-gnu/ncl I deactivated my quilt patches and the override_dh_auto_configure since nothing really helped. Any hint would be welcome. Kind regards Andreas. [1] git://anonscm.debian.org/debian-med/libncl.git Hm... don't know the Debian docs that well, but Fedora has some info on [2]. Basically, you should be able to add something like that in a dh_ override. The debian GL seems to be in [3]; they look similar. --Cheers! -alec [2] https://fedoraproject.org/wiki/Packaging:Guidelines#Removing_Rpath [3] https://wiki.debian.org/RpathIssue
Re: Failed to stop defining RPATH in libncl
On 04/01/16 12:45, Andreas Tille wrote: Hm... don't know the Debian docs that well, but Fedora has some info on [2]. Basically, you should be able to add something like that in a dh_ override. The debian GL seems to be in [3]; they look similar. Thanks for your attempt to help but these links are clear. I simply failed to implement a dh_override / patch since the means that were usually helpful failed and thus was asking for help. Well, you just published the sources, not the debian/ stuff. That said, I presume that something like this should work if you are using the modern dh_ primitives It's not the nice way which would be a patch to configure.ac (there are examples out there), but it's simple and effective. The --fail-missing is just a copy-paste, you might want to skip it, and the installation paths (here debian/tmp) could of course be something else. control: Build-Depends: chrpath rules: override_dh_install: dh_install --fail-missing chrpath -delete debian/tmp/usr/bin/N* Cheers! --alec
Re: Failed to stop defining RPATH in libncl
On 04/01/16 13:45, Alec Leamas wrote: rules: override_dh_install: dh_install --fail-missing chrpath -delete debian/tmp/usr/bin/N* Oops... That won't work. But: rules: override_dh_install: chrpath -delete debian/tmp/usr/bin/N* dh_install --fail-missing If you already have an override_dh_auto_install the best might be to append chrpath to the end of that instead. Cheers! --alec
Re: Failed to stop defining RPATH in libncl
On 04/01/16 16:32, Gianfranco Costamagna wrote:
Hi Andreas,
Hmmm, the libraries are installed in usr/lib/{triplet} so I'm not sure>what you
are talking exactly. If git.d.o would be online I'd commit
the current status with cleaned up packaging and removed RPATH.
nope, they were installed in usr/lib/{triplet}/ncl/
so unless you try to export LD_LIBRARY_PATH or you use an RPATH your linker
just won't
be able to open them.
Expanding on this, IMHO you really have two choices:
- Leave the rpath in place, the libraries in .../ncl/ and ignore the
lintian warning after verifying that the rpath is indeed to the .../ncl/
dir.
- Move the libraries to /usr/lib/{triplet}, remove the rpath and mute
the warning.
The choice is really about if the libraries are "internal" in the sense
that they only are used by the applications in the package, or if they
are intended to be used by other applications.
From a guidelines perspective both solutions are fine. Fedora and
Debian seems to have the same rules here.
Cheers!
--alec
Bug#808249: RFS: libirman/0.5.1-1 [NMU]
On 02/03/16 19:27, Gianfranco Costamagna wrote: Hi, now we are waiting for Stefan to review the package :) cheers, G. And, probably more important, we we are waiting for Stefan to review the lirc package. lirc currently has a build dependency on libirman, but the upcoming lirc package turns things upside down: libirman is a plugin which depends on lirc. So the lirc package needs a review first, and until this is done the libirman one doesn't make much sense. Cheers! --alec
