Re: Rationale for removing binary data from debian source package
Am Mon, Feb 07, 2022 at 10:26:16AM +0100 schrieb Mathieu Malaterre: > Dear Debian Med, > > I am trying to remember the rationale for removing binary data from a > Debian source package. > > Let's consider charls: > > ``` > Files-Excluded: */test/conformance > */test/jlsimage > */test/*.raw > */test/*.jls > */test/*.dcm > */test/*.ppm > */test/MR2_UNC > ``` This was added in commit: commit 936c46cce7fb88a032bb7f964406c5f171575f4e Author: Andreas Tille Date: Thu May 19 17:27:01 2016 +0200 New upstream version (use Files-Excluded) If I go back to commit 3c1373841374b5fb75c4da2d2da7345ddd513943 (HEAD) Author: Mathieu Malaterre Date: Fri Nov 7 08:24:52 2014 + update to 3.9.6 `git blame` uncovers: ^e1fc389 (Mathieu Malaterre 2011-04-27 16:54:06 + 43) get-orig-source: $(UPSTREAM_SRC).zip ^e1fc389 (Mathieu Malaterre 2011-04-27 16:54:06 + 44) rm -rf $(DEBIAN_SRC_DIR) ^e1fc389 (Mathieu Malaterre 2011-04-27 16:54:06 + 45) unzip -q $(UPSTREAM_SRC).zip -d $(DEBIAN_SRC_DIR) 3784391f (Mathieu Malaterre 2011-04-27 19:37:57 + 46) # UNIX eol 481f011f (Mathieu Malaterre 2011-04-27 19:07:43 + 47) dos2unix $(DEBIAN_SRC_DIR)/*.h 481f011f (Mathieu Malaterre 2011-04-27 19:07:43 + 48) dos2unix $(DEBIAN_SRC_DIR)/*.c* 481f011f (Mathieu Malaterre 2011-04-27 19:07:43 + 49) dos2unix $(DEBIAN_SRC_DIR)/*.txt 3784391f (Mathieu Malaterre 2011-04-27 19:37:57 + 50) # remove dataset to reduce source size 3784391f (Mathieu Malaterre 2011-04-27 19:37:57 + 51) rm -rf $(DEBIAN_SRC_DIR)/test/conformance/ 3784391f (Mathieu Malaterre 2011-04-27 19:37:57 + 52) rm -rf $(DEBIAN_SRC_DIR)/test/jlsimage/ 3784391f (Mathieu Malaterre 2011-04-27 19:37:57 + 53) rm $(DEBIAN_SRC_DIR)/test/*.raw 3784391f (Mathieu Malaterre 2011-04-27 19:37:57 + 54) rm $(DEBIAN_SRC_DIR)/test/*.jls 3784391f (Mathieu Malaterre 2011-04-27 19:37:57 + 55) rm $(DEBIAN_SRC_DIR)/test/*.dcm 48689d69 (Mathieu Malaterre 2011-04-27 19:44:40 + 56) rm $(DEBIAN_SRC_DIR)/test/*.ppm 3784391f (Mathieu Malaterre 2011-04-27 19:37:57 + 57) rm $(DEBIAN_SRC_DIR)/test/MR2_UNC ^e1fc389 (Mathieu Malaterre 2011-04-27 16:54:06 + 58) GZIP="--best --no-name" tar czf $(DEBIAN_SRC_TAR) $(DEBIAN_SRC_DIR) ^e1fc389 (Mathieu Malaterre 2011-04-27 16:54:06 + 59) rm -rf $(DEBIAN_SRC_DIR) ^e1fc389 (Mathieu Malaterre 2011-04-27 16:54:06 + 60) rm $(UPSTREAM_SRC).zip So if you remember why you excluded those files at that point in time it makes sense to document this. If not just keep them in if it permits a sensible testing. > Long story short, upstream is relying on some of these files to run > unit tests (please no debate). Would it be acceptable to add a portion > of these binary data back into the source package ? If so, what should > I pay attention to? I do not consider image data binary without source since there are image editing tools inside Debian. The only thing we need to pay attention is that there are no copyrighted images (like "lena" amongst these). > ref: > https://salsa.debian.org/med-team/charls/-/blob/master/debian/copyright#L5-13 Long story short: I'm fine with keeping all test data. Kind regards Andreas. -- http://fam-tille.de
does anyone know of its whereabouts? Fwd: r-bioc-progeny_1.14.0+ds-1_amd64.changes REJECTED
Hello, I just checked but could not find any info on r-bioc-progeny. Andreas has fixed the missing license info for https://afeld.github.io/bootstrap-toc/ (which looks good btw) . @Andreas do you happen to recall if you have uploaded this again? Or was this rejected with a request to provide a package for bootstrap-toc? The package would also work without it, so I may presume, and I would then vote for a simplification. Many thanks and regards Steffen Forwarded Message Subject:r-bioc-progeny_1.14.0+ds-1_amd64.changes REJECTED Date: Tue, 23 Nov 2021 19:00:08 + From: Thorsten Alteholz To: Debian R Packages Maintainers , Steffen Moeller Hi Steffen, please mention the license of bootstrap in your debian/copyright. Thanks! Thorsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
Re: Bug#1004498: RFP: toml11 -- C++11 (or later) header-only toml parser/encoder
Am Fri, Feb 04, 2022 at 02:01:34PM + schrieb Lance Lin: > > Okay, here's the review: > Thank you for the feedback. I've made a lot of these changes and I'm working > through the gbp setup. I have not seen those changes. Did I miss anything? It would be great to respond to the sponsoring review mail and add some "Done" response at the according item and ask back if you do not agree. Kind regards and thanks for your work in any case Andreas. -- http://fam-tille.de
Re: Bug#1004498: RFP: toml11 -- C++11 (or later) header-only toml parser/encoder
Hi Lance, when re-reading Nilesh's mail I agree with all his points. I've fixed several of them when reviewing. Am Thu, Feb 03, 2022 at 07:51:33PM +0530 schrieb Nilesh Patra: > On Thu, Feb 03, 2022 at 01:50:39PM +, Lance Lin wrote: > > Hi Nilesh, > > > > On Wednesday, February 2nd, 2022 at 9:33 PM, Nilesh Patra > > wrote: > > Ok, I've tested the package and the only warning is an improbable bug > > number. > > However, it is the correct bug number. > > I do not see that problem; since you see a probable bug number problem, most > likely > you are using an older version of lintian (before we had our on-million'th > bug report) > Please upgrade +1 > > It is hosted on the debian med namespace [1]. > > Please review the work, but I think it should be complete. > > Okay, here's the review: > > 1. Naming: Since this is a header-only lib, IMO it can/should be named to > libtoml11 instead I agree. Please rename. > 2. Branch structure is wrong > >+ We follow dep-14 protocol which means there are three branches, master; > upstream and pristine-tar. Please skim-through our > policy[2] and dep-14 docs[3] should you find it useful I've created those branches and like to stress that reading the suggested links is a good advise. >+ Looks like you are not using gbp, using it can save you from these > pitfalls. +1 > @Andreas, can you link here to a recent packaging tutorial of yours, using > gbp? Lance confirmed he has seen at least parts of my DebConf workshop. > 3. Remove debian/debhelper-build-stamp; that's the default debhelper > behaviour, you don't need this Done. > 4. Remove debian/files; did you commit this file off after doing a > dpkg-buildpackage? Are you not building in a clean chroot? Done. > 5. d/patches is empty, so purge this Done. > 6. d/rules: > >+ "export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic" is un-needed, that'd > get these by default >+ "export INSTALL_PREFIX = /usr/" -- I do not see it when I grep the code; > so I think this is un-needed. > Debhelper will take care of the prefix on its own, provided the > upstream build does not override it Fully ACK - please remove. > 7. d/control: > >+ Maintainer field should be 'Debian Med packaging team' along with our > alioth list email; take a look at > any package on our namespace's salsa >+ You should be mentioned in uploaders Done. >+ Bump Standards-Version to 4.6.0 >+ Add Rules-Requires-Root field Both done >+ Binary package name is wrong, it should be libtoml11-dev; check library > style packaging guide[4] ACK. Please rename >+ Description seems a bit weird, you might want to reformat it ACK. Also the wording is a bit monotone to read but we could possibly live with this. > 8. No d/upstream/metadata: github-debian-upstream script from pkg-js-tools > can help create one Done by using lintian-brush (called by routine-update) > 9. No autopkgtests: Since you are familiar with these (you added it to a > couple of packages) you might want to have >it in here too. ACK. > Welcome, hope this helps. I hope Andreas can steer this discussion after this > point; less time in the week :-) Lance, it would be nice if you would work down such a list of todos as created by Nilesh and ask for a second review afterwards. Please come back here once you fixed the remaining items. Please note that I bumped the upstream version to latest upstream when I did the changes (partly by calling routine-update). Meanwhile I learned that the package uncalled is featuring a code copy of toml11 so I see a good reason to maintain it in Debian Med team. Kind regards Andreas. > > [1] https://salsa.debian.org/med-team/toml11 > [2]: > https://med-team.pages.debian.net/policy/#to-create-a-new-local-git-repository > [3]: https://dep-team.pages.debian.net/deps/dep14/ > [4]: https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html > > Regards, > Nilesh -- http://fam-tille.de
Rationale for removing binary data from debian source package
Dear Debian Med, I am trying to remember the rationale for removing binary data from a Debian source package. Let's consider charls: ``` Files-Excluded: */test/conformance */test/jlsimage */test/*.raw */test/*.jls */test/*.dcm */test/*.ppm */test/MR2_UNC ``` Long story short, upstream is relying on some of these files to run unit tests (please no debate). Would it be acceptable to add a portion of these binary data back into the source package ? If so, what should I pay attention to? Thanks, ref: https://salsa.debian.org/med-team/charls/-/blob/master/debian/copyright#L5-13
