Re: Fwd: Re: libmseed licensing
Pierre Duperray wrote on 03/12/2019: > > Hello Paride, > > On 12/3/19 2:09 PM, Paride Legovini wrote: >> Hi Pierre, >> >> I'm working at the libmseed3 Debian package. One thing I noticed is that >> IRIS relicensed libmseed from LGPL-3.0+ to Apache-2.0, plus there are a >> couple of files in the repo that are MIT/Expat licensed. > ok >> I have a couple of questions for you: >> >> 1. Are you fine with relicensing debian/* as Apache-2.0 for licensing >> uniformity? > no problem >> 2. d/copyright lists you as the copyright owner of mseed.pc.in, licensed >> LGPL-3.0+. Apparently they didn't really take this into account when >> doing the relicensing. Are you fine with relicensing this as Apache-2.0? >> (Given the nature of the file I'd probably drop the copyright claim and >> just consider it as part of upstream, but this is up to you.) > > Yes I don't claim anything, we can consider it part of upstream. Ok, perfect, and thanks for reaching out via debian-science. Anyway I'll upload libmseed3 to experimental and I think it will stay there for a while. The other tools depending on libmseed (mseed2sac, sac2mseed) still need libmseed2, and apparently they are not compatible with libmseed3. Upstream don't seems to care as they ship libmseed2 with the tools as a vendored library, but we want to use the Debian packaged one. > You will do an NMU? How will you proceed? I'm not sure to have > permission to push something on salsa... Well I co-maintain the package with you (see our email exchange of September 2018), and I have upload rights for it :) Paride
Re: Committing to a team-maintained package repository
Mattia Rizzolo wrote on 16/07/2018: > On Sat, Jul 14, 2018 at 07:56:08PM +0200, Paride Legovini wrote: >> One last question. Do we actually need these lines: >> >> include /usr/share/dpkg/architecture.mk >> ifeq ($(origin CC),default) >> CC := $(DEB_HOST_GNU_TYPE)-gcc >> endif >> >> in d/rules? >> Are they still relevant with Multi-Arch? > > They are very relevant with Multi-Arch, the point is that nowadays > debhelper takes care of them, so they are *usually* not needed anymore. > > I recommend you just try to remove the lines and cross build the > package, but I expect you can safely remove them. Thanks Mattia, it does indeed cross-compile fine without them. They are now gone. > Note that these days cross building is extremely easy with both sbuild > and pbuilder, you just need to pass --host (for sbuild) or --host-arch > (for pbuilder), and they took care of everything (ISTR sbuild needs > another flag to install a foreign package, but that will be easy to find > out if you use sbuild…). I had to call sbuild with --add-depends=libc6-dev:, I guess this is what you were referring to. I pushed my changes, I think the package is ready to be uploaded. Paride
Re: Committing to a team-maintained package repository
Hi Andreas, thanks a lot for reviewing my changes. Andreas Tille wrote on 14/07/2018: > Hi Paride, > > On Wed, Jul 11, 2018 at 03:18:08PM +0200, Paride Legovini wrote: >>> just go for it push and sak for sponsoring here. >> >> I would be glad if you could review my commits here: >> >> https://salsa.debian.org/science-team/libmseed > > So just let me know if you want to > > 1. Add yourself as Uploaders I'm glad to follow your suggestion here. > 2. Switch to d-shlibs I didn't know it and it is indeed a nice tool, so thanks for the pointer. But: it seems to me that the really interesting feature is the installation of the .so/.a/.la files and related links in the right places. The destination path for the include files and documentation still has to be specified manually, so I think there is no real advantage over dh_install or dh_installdocs (which gained some nice features in compat 11). For this reasons, I'm using d-shlibs only to install the shared object. I'm not yet completely sure on how I like it: the toolchain is already complex, do we want to add another tool to it? I would probably like to see it become a debhelper first class citizen (as e.g. dh_installshlibs). Please check the relevant commit for libmseed. If you think I somehow missed the point with this tool don't hesitate to let me know. Comments are always welcome. > Whatever you decide I'll also sponsor in the current state. I think the package is ready, I will let you s/UNRELEASED/unstable/ and tag the release. I'd be happy to do it myself, but you would need to grant me DM upload rights for this package. There is no hurry for this: do as you prefer. I pushed the upstream/2.19.5 tag, which was missing. One last question. Do we actually need these lines: include /usr/share/dpkg/architecture.mk ifeq ($(origin CC),default) CC := $(DEB_HOST_GNU_TYPE)-gcc endif in d/rules? They are suggested here: https://wiki.debian.org/CrossBuildPackagingGuidelines Are they still relevant with Multi-Arch? Cheers, Paride
Re: Committing to a team-maintained package repository
Andreas Tille wrote on 04/07/2018: > Hi Paride, > > just go for it push and sak for sponsoring here. Hi Andreas, I would be glad if you could review my commits here: https://salsa.debian.org/science-team/libmseed I did more changes than I initially thought, so I left the package UNRELEASED for the moment. If you think it's ready to be uploaded let me know and I will finalize the changelog and tag the release. Thank you, Paride
Committing to a team-maintained package repository
Hi,
I'd like to fix #890571, and I think I know how [0]. This means
committing to:
https://salsa.debian.org/science-team/libmseed
and doing a (sponsored) team upload. As a group member ("Developer"
gitlab role), I have write access to the repository [1], but I am not
used to pushing commits for packages I do not (co)maintain. Should I
just proceed, or is some preliminary coordination normally expected?
Cc: Pierre Duperray (libmseed maintainer).
Cheers,
Paride
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890571#12
[1] https://science-team.pages.debian.net/policy/#idm145
Re: Looking for feedback on a recent upload
Lumin wrote on 29/06/2018: > 1. Git repository layout in question > >File debian/source/format writes "3.0 (quilt)", so the master >branch should hold the "packaging commits" instead of the >"upstream commits". By the way, please always keep the >"upstream" and "pristine-tar" branches up to date. In order >to achieve that, you can use this command when importing >a new upstream verison: > >│ >│ $ gbp import-orig --pristine-tar XXX_YYY.orig.tar.gz >│ Dear Lumin, I maintain a couple of package in debian-science using the classic workflow you describe, but I normally prefer the "pure git" workflow and the DEP14 branch layout. DEP14 clearly conflicts with the debian-science policy, but I'm not sure about the "pure git" approach. By "pure git" I basically mean having the upstream repository as a remote, fetching and merging new upstream versions via git, and using (possibly signed) tags instead of tarballs. It is still possible to maintain a pristine-tar branch, if desired, and uscan has a very handy ‘mode=git’ option (see for example [1]). Is this workflow to be considered incompatible debian-science's policy? Cheers, Paride [1] https://salsa.debian.org/debian-phototools-team/imv/blob/debian/sid/debian/watch
Re: Packaging several tiny upstrem packages in a single Debian package
Ole Streicher wrote on 17/06/2018: > Dear Paride, > > Paride Legovini writes: >> I was thinking of packaging them together, in a single Debian package, >> named for example ‘miniseed-tools’ or ‘seiscode-tools’ (suggestions are >> welcome). I know this is not very commonly done in Debian, but I know >> there are cases where is has been done. Should this be done, mseed2sac >> and sac2mseed would become dummy transitional packages. >> >> Before I start to work in this direction, what do you think of this >> idea? > > I personally would prefer to keep them separated, especially when > upstream keeps them separate. Then you don't need to fiddle with the > version numbers, updates of individual packages etc. Better discuss this > with upstream first -- they may have a good reason to keep them > separate, and as a rule of thumb I would usually follow them. > > This also makes your packages more standard on the upstream side, and > keeping the standard is alsways a good thing for potential team > maintenance. > > And I don't see the disadvantage to have many source packages instead of > maintaining a collection by yourself. Thanks for your feedback, Ole. Yours are all good points, while on the other side there is no strong argument for consolidating the packages. I will keep them separated. Paride
Packaging several tiny upstrem packages in a single Debian package
Dear science-team, I currently maintain two packages that deal with MiniSEED, a file format used in seismology: mseed2sac and sac2mseed. These tools are part of a bigger software collection, SeisCode: https://seiscode.iris.washington.edu/ I would like to package more software from SeisCode, e.g.: msi, dataselect, msmod, mseed2ascii, ascii2mseed, and probably others. These packages have a lot in common: - They are maintained by the same person and institution; - They are released under the same license; - They are all very small (sometimes just a couple of source files); - They are written in C and rely on the same library (libmseed); - They are strongly related. I was thinking of packaging them together, in a single Debian package, named for example ‘miniseed-tools’ or ‘seiscode-tools’ (suggestions are welcome). I know this is not very commonly done in Debian, but I know there are cases where is has been done. Should this be done, mseed2sac and sac2mseed would become dummy transitional packages. Before I start to work in this direction, what do you think of this idea? Should we decide this is not the best approach, I think the alternative is packaging them individually and then prepare a metapackage which depends/recommends all of them. Cheers, Paride signature.asc Description: OpenPGP digital signature
Accepted sac2mseed 1.12+ds1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 08 Feb 2018 17:01:14 +0100 Source: sac2mseed Binary: sac2mseed Architecture: source Version: 1.12+ds1-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers <debian-science-maintain...@lists.alioth.debian.org> Changed-By: Paride Legovini <p...@ninthfloor.org> Description: sac2mseed - Convert SAC waveform data to MiniSEED Changes: sac2mseed (1.12+ds1-2) unstable; urgency=medium . * d/control: use the correct maintainers mailing list address Checksums-Sha1: e431e6dd1b21b9feb847fec3de14806f8125d8f9 2130 sac2mseed_1.12+ds1-2.dsc 20b3215b0cf06238686cbc356bc5d52ea433d70b 2236 sac2mseed_1.12+ds1-2.debian.tar.xz 1a63ba799dc1754d5bf9eeced50f155c8a95875c 5611 sac2mseed_1.12+ds1-2_source.buildinfo Checksums-Sha256: 0b6a66f6cdf9b1cf29f3b4fe447883117dbd78db33c518cb9288d7897d51c144 2130 sac2mseed_1.12+ds1-2.dsc 0db280ffbe4f649802c208b29fadbdf2a6e352dcf7dc01e73b09c929aed6a538 2236 sac2mseed_1.12+ds1-2.debian.tar.xz 9058e5f46e5ccc05e71cd3d4755953914c4cdff43b810923c9a35e08cd3743ec 5611 sac2mseed_1.12+ds1-2_source.buildinfo Files: 41b3e6f1cc2214984cdc11912de57619 2130 science optional sac2mseed_1.12+ds1-2.dsc f7a1d2a6b5424c0e4c5b2c7a089960fa 2236 science optional sac2mseed_1.12+ds1-2.debian.tar.xz 2bbc123ff5705dcbd3b6e46cbfdd7778 5611 science optional sac2mseed_1.12+ds1-2_source.buildinfo -BEGIN PGP SIGNATURE- Comment: Debian powered! iQKTBAEBCgB9FiEE890J+NqH0d9QRsmbBhL0lE7NzVoFAlp+wwlfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEYz REQwOUY4REE4N0QxREY1MDQ2Qzk5QjA2MTJGNDk0NEVDRENENUEACgkQBhL0lE7N zVphjw//dC+N01cgOSU2PtsTHPawH1dZhLEbR/ipuFGUXFSOPRINljfXteAcMWkG ZQqwy8IlwAZN2OVNFPUmIB5gsO9Dx6mRUCm1xJEmbiSz/7xULS9BjLLLy/gQG53g Lq9tuRoIddEz6ZtE02b6Tf6JQsiEZ8lk6Hck8akDQXgDcjdwy/4DcZ4LNvrEgkyz EkuZ1tfD7WUSe4+UmtqdcKwrgoB2iGlAoBenAwCoxN2shXQK9Nz0ZlXP5SCbbWwL b0exIiLrEuXynDcV9/d2e8O19miGxUIBVa6eKcuwoI2uvs82TV5VWZD/7zX7aI8S oKFiw+PZJ77y50+nANxXSVa2roCJZi3XSRiHIc1njv0HARsqfpquEO/RJP9D2ZRl msDpgY21hyD8eQhPnHjb97TyUcuWrQMVZfgY10P43cZm2n1JgYThVSd121ltALkm I5LEoHhwMO+YujtD+HyQBnnbHMm0fy+tJJEe1WT/BZNm7knDVZNEe8//Uf2CvWUS ukd8VH2Ocmwp3c6VjkzF5MFhA/YH6JxVpwHfCgdWp6qyT2c252bLQPmFOvY4BU1d 20It+DvTnK6Np7dKaHWzTwE44Kw42IGFQWQrajwZXD3imHS7bkxb2f2g379Qg+iE r1lALlcF88z+C8wG+dU/J0G3hmN72KyiQ1f45t/9MyxGmwCOZmU= =clLn -END PGP SIGNATURE-
Accepted mseed2sac 2.2+ds1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 08 Feb 2018 17:00:19 +0100 Source: mseed2sac Binary: mseed2sac Architecture: source Version: 2.2+ds1-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers <debian-science-maintain...@lists.alioth.debian.org> Changed-By: Paride Legovini <p...@ninthfloor.org> Description: mseed2sac - Convert MiniSEED time series data to SAC Changes: mseed2sac (2.2+ds1-2) unstable; urgency=medium . * d/control: use the correct maintainers mailing list address * Depend on debhelper >=11~ (allows backporting to stretch-backports) Checksums-Sha1: 4384c2b6a89d6bf26df2b57db6cabe75c894cb75 2135 mseed2sac_2.2+ds1-2.dsc 2163c8fbb15c2e6109d53b5252b42e2acc1fdd33 2264 mseed2sac_2.2+ds1-2.debian.tar.xz 1100fe7b5f07c5473656b4a7f0fa6fdb427199e6 5639 mseed2sac_2.2+ds1-2_source.buildinfo Checksums-Sha256: 70f3ef7093435a1cd604ca86832d04295c7dc35ef91666c30454983506eaf6cb 2135 mseed2sac_2.2+ds1-2.dsc ff63ec450cf8cde4fca390596a51678a4b62d205d37d82e2ff9bffe7f7c1f079 2264 mseed2sac_2.2+ds1-2.debian.tar.xz 902300e60ce722756bd92ccb3ca33055e5d0c288061212db76941c220d43aeb5 5639 mseed2sac_2.2+ds1-2_source.buildinfo Files: 02cdcde4f7dead0de9d170f3c5b6e63c 2135 science optional mseed2sac_2.2+ds1-2.dsc d805a8d10b404f86fd4370823e803bbf 2264 science optional mseed2sac_2.2+ds1-2.debian.tar.xz e9b7ec9b71c2441db5466d72e4f98f4f 5639 science optional mseed2sac_2.2+ds1-2_source.buildinfo -BEGIN PGP SIGNATURE- Comment: Debian powered! iQKTBAEBCgB9FiEE890J+NqH0d9QRsmbBhL0lE7NzVoFAlp+wbBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEYz REQwOUY4REE4N0QxREY1MDQ2Qzk5QjA2MTJGNDk0NEVDRENENUEACgkQBhL0lE7N zVrO7Q/+Ix5bPinEoTNs3LIIJwQWbv53IfWB8i1mo0utHAT1FkeyZ5jLlRjENhmO 7HxVQA87ZAJ2hZD1RidsyNQCongfYJsv7eVhqg3Dc2P2lbQZjvMuK01FeTbwDipY t3lePQgyanfQA1Zr+sXf+Ph+K9YqE/m38iHvUDqwD+t1VxUmFWz6BvT92piy1uxU W15C4tr9e3o3V+ID2L7FSj77yBkJrlTl4Zo/mpxdajl+9rK40KumuV7vTy1JROV3 zJGC460pToVJch8S5/pOMEVckXxzY4RF8kUQ/2CjgEAacaUGLhKJ7RUt+FlChn5i q4RG14s+sOSWUYKbiyZj2NHUgR3XtOSUGpawxT9cwPjasmVhYAGaJd6+5wA4+hJk 03JRnSapPOPVgfxRHpFFE9vKiYPgrrLE1FUztzva4RcFPqj8y5yHcdk0DMtmJmcj z5/2A+/wUH4l8sZfYKE35VwlrZJ/6bU7nzU7VySfrAdvkK7ZdchDnJ9IrJ7a2Ewk H4SNAjMima4jCiKP4dtXqDpn2zUroMVDFTlT6C/bIHozKbn+A9eMTIQxoQEm5y0W GExmoPu3vcs//ztm7uBkUAvcDbwsIDyMi2rFv/rBYEBeMp/60o/Y0Y1gUdDSBxg4 hcl+HbZMzOSw0MkwwzavUwuRHWT8IkL1aNobTd0MRkLT2fWnDTM= =z8Dn -END PGP SIGNATURE-
Re: [RFS] mseed2sac and sac2mseed: seismic data conversion tools
On 2018-01-29 11:56, Sébastien Villemot wrote: > > So I just created the repositories in science-team on salsa and added you > as Developer for each project (since you are apparently not yet a member of > the > Science Team group). > > The URLs should be: > > Vcs-Browser: https://salsa.debian.org/science-team/mseed2sac > Vcs-Git: https://salsa.debian.org/science-team/mseed2sac.git Thanks Sébastien, I pushed the updated packaging repositories there. I also set: Maintainer: Debian Science Maintainers <debian-science@lists.debian.org> Uploaders: Paride Legovini <p...@ninthfloor.org> (Perhaps the Debian Science Policy Manual should be updated with the new mailing list address.) >>> - please also use standard git-buildpackage branch names, i.e. "upstream" >>> for >>> upstream sources and "master" for Debian packaging (this naming scheme is >>> expected in the Debian Science Team). Done, now I hope for a final review and finally for sponsorship. Regards, Paride
Re: [RFS] mseed2sac and sac2mseed: seismic data conversion tools
Hello Sébastien, Thanks for your careful review. On 2018-01-23 16:47, Sébastien Villemot wrote: > I just looked at mseed2sac, but maybe the remarks below also apply to > sac2mseed: Indeed most of them did apply also to sac2mseed. > - the Vcs-Git and Vcs-Browser fields in debian/control should point to the > Debian packaging (on salsa.debian.org), not to the upstream sources Fixed, but of course at some point I would prefer to host the repositories in the science-team group. > - it looks like you repackaged the original tarball by removing the libmseed/ > directory. This should be made clear in the Debian version by adding a > suffix > (typically "+ds", for "Debian source", so that the Debian version will be > "2.2+ds-1"). Done, I'm using 2.2+ds1-1, so I have a version number to bump if I have to modify the Debian source branch. > Then you also want to update debian/watch to take into account the +ds > suffix (with the "dversionmangle" option), and also debian/copyright (by > using the Files-Excluded field) to make repacking easy (see the manpage for > "uscan" for both points) Done. > - please add a "pristine-tar" branch, we rely on it in the Debian Science Team Done. > - please also use standard git-buildpackage branch names, i.e. "upstream" for > upstream sources and "master" for Debian packaging (this naming scheme is > expected in the Debian Science Team). Well, I chose this naming scheme (branch "master" tracks upstream, branch "debian/sid" contains the Debian packaging) because it was what the gbp documentation suggested, see: /usr/share/doc/git-buildpackage/manual-html/gbp.import.upstream-git.html Are you asking me to change the names of the branches just to keep the structure of the debian-science packages uniform, or is there another reason I'm missing? I'm asking just to understand: I have no problem in changing the names, but on the other side I'd like to stick with a somehow uniform workflow for my Debian packages. Is there a general best practice to follow when using git and upstream tagged releases? > - why do you add -O3 in debian/rules? Unless you have a good reason (like it > avoids a build failure), you are expected to use standard Debian build flags Done. > Otherwise your packaging looks good (though I can't promise that there are no > other issues that may be discovered in a second round of review). Thanks. In debian-science do you rely on mentors for reviewing, or do you review directly from the git repository? Cheers, Paride
Re: [RFS] mseed2sac and sac2mseed: seismic data conversion tools
On 2018-01-12 14:13, Paride Legovini wrote: > Dear debian-scientists, > > I packaged two small utilities to convert seismic data between the two > most commonly used data formats. Both the tools use the recently > packaged libmseed2 library (thanks Pierre). > > Here are the ITPs: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886993 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886995 > > and the uploads to mentors: > > https://mentors.debian.net/package/mseed2sac > https://mentors.debian.net/package/sac2mseed I updated the packages. The repositories are linked in the ITPs, I'll copy the links here for convenience: https://salsa.debian.org/paride-guest/mseed2sac https://salsa.debian.org/paride-guest/sac2mseed Checkout the "debian/sid" branch. Still looking for reviews and sponsorship :) Cheers, Paride signature.asc Description: OpenPGP digital signature
[RFS] mseed2sac and sac2mseed: seismic data conversion tools
Dear debian-scientists, I packaged two small utilities to convert seismic data between the two most commonly used data formats. Both the tools use the recently packaged libmseed2 library (thanks Pierre). Here are the ITPs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886993 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886995 and the uploads to mentors: https://mentors.debian.net/package/mseed2sac https://mentors.debian.net/package/sac2mseed I'd like to maintain these two packages in the debian-science team and I'm looking for a sponsor. Thank you, Paride signature.asc Description: OpenPGP digital signature
