On 2015-03-21 22:56:09, Pavel Kalian wrote: > On 03/21/2015 07:18 PM, Antoine Beaupré wrote:
[...] > While it can be built, it is pretty sure there are issues in how it > works with wx3 on Linux, it received very little testing upstream and > certainly won't get any but totally trivial and safe wx3 related fixes > in the 4.0 series. > Master leading to 4.2 is a different thing, but currently alpha quality > due to Android support landing. > Until Precise reaches EOL it's support will get precedence over Debian > as for upstream it represents more users with less skill, equaling to > more support "costs" if it stops to be totally straightforward. I understand. But my point is more that the Debian package can be made to build against wx3 without forcing the Ubuntu side to do the same. We could upload first to experimental for example and test out the results. If Ubuntu stability is important, maybe we should just diverge the packages from the PPA from the packages uploaded into debian directly. Eventually they will merge as the Debian packages trickle down into the next Ubuntu releases... [...] > I would also love to live in a Debian/GNU centric world where Windows > users don't think they can build packages from source without reading > C++ for Dummies and OS X users that they use the only platform on > Earth... Unfortunately I don't ;) I am not sure that's what pabs was suggesting. :) All that we're saying here is that there could be a base tarball with just the OpenCPN source code (and I also believe the VCS repos should hold only that) and a separate tarball with dependent libraries builtin. At the VCS level, this could (for example) be accomplished through git submodules. However... > Anyway, I have modified the Launchpad packaging scripts to strip > everything not needed for the Linux build while creating the source > tarball, ... while not the ideal solution in my mind, that's fine too! :) > how can it be submitted for review? Well, how do you manage the source now? Should we collaborate somewhere or would you prefer the source for the Debian-specific packages to be managed separately? I often use "collab-maint" for such collaboration, but OpenCPN is a bit special as it falls under the lead of the GIS team (in CC), and therefore has its own set of tools. More information: https://wiki.debian.org/CollaborativeMaintenance https://wiki.debian.org/DebianGis > Or should I submit a patch for get-orig-source? I think that would be the most standard solution. > Where and how > (http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/trunk/ > seems a bit out of date)? I think that SVN repository was a different packaging effort than yours (unless you started from there!) and should probably be disregarded at this point, as it is outdated. Furthermore, it seems the GIS team is switching to git: https://wiki.debian.org/DebianGis/Svn2Git So the proper place for the repository should probably be a git repo in the GIS team. But I am not sure how to grant you access to that on Alioth, maybe the GIS people can tell us here? > I suppose the data packages opencpn-doc, opencpn-gshhs and > opencpn-tcdata should be usable in the same form they already have on > Launchpad. I haven't reviewed those so I can't say, but I assume that's correct. I will probably do a final review before sponsoring the upload anyways. So far I am trusting you things were magically fixed, but unfortunately I *will* need to do some more audit work before the upload just to avoid pissing off the FTP-masters needlessly (the poor souls ;). Thank you for your patience! A. -- Un éducateur dans l'âme ne prend rien au sérieux que par rapport à ses disciples -- soi-même non excepté. - Nietzsche, "Par delà le bien et le mal" -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org