Am Samstag, den 28.02.2015, 17:17 +0200 schrieb Antti Järvinen: > Tobias Frost writes: > > Am Samstag, den 28.02.2015, 12:16 +1100 schrieb Riley Baird: > .. > > should fix them, also please read https://wiki.debian.org/UpstreamGuide > > -- you definitly need to separate upstream source and debian packaging; > > don't ship a debian dir in the tarball. > > Ok, thanks a million for your good comments Tobias and Riley, there > seems to be things that did not cross my mind yet .. :) > > But, before attempting to address the listed problems I'd like to > get clarification on a few unclear items: > - Mixing OpenSSL with LGPL is ok and requires no license-statement > acrobatics? While I'm the upstream, switching the license from > GPL to LGPL is possible and would also suit well together Licensing can be tricky. You can also stay with GPL: https://people.gnome.org/~markmc/openssl-and-the-gpl.html Plain GPL is problematic, but can get around with openssl exception as quoted exemplantory in that link. Another option is, of course, to avoid openssl and port your program to use e.g GNUTLS. (note: For relicensing you need the ok from all copyright holdes. If you had contributors, you need to ask or have asked them via contributors agreeement) > with the fact that the text editor code from Nokia is in LGPL too.. LGPL and GPL is compatible, so no problem. > - ..about the debian directory in the tarball: as it is handy to > have the build-related items in same version control with the > sw what do people normally do? Maybe rename the directory > "debian" to something else and the re-re-name when it is actually > needed? Or just delete directory from the tarball, making it > impossible to simply fetch latest .tar.gz from version control to > be treated as "original sources"? It might cause problems at Debian. The benefit is also limited, as you can not guarantee that Debian's package is always in sync with your upstream tarball. Imagine a NMUs as an example or the fact that it not necessary to always release a new upstream version when you only need to fix a Debian issue. The implementation details are up to you, just don't have it in the tarball. My recommendation: If you want to have it your repository, have it in its own branch. Otherwise, make a own repository, using a git-buildpackage layout, and sometime, when you are more involved in Debian, we'll get you an account at alioth and we move it to collab-maint, if you're ok with maintaining it within collab-maint. http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html https://wiki.debian.org/Teams/CollabMaint > - The Lenin photograph, according to > http://en.wikipedia.org/wiki/Newspaper#mediaviewer/File:Lenin_reading_Pravda.gif > is by Pyotr Otsup who was not credited in copyright. The file is > in the public domain in most countries yes, but is it still a > problem to have it included, if there is some imaginary country > that for instance grants eternal copyright to every graphical item? Copyright's tricky, too. Paul answered this question already. From the packaging perspective, you need to document *all* copyrights in debian/copyright. Every file needs to be covered! (makeu sure to the dep5 documentation as you can combine several files into one section; just to avoid that you'll have a section per file then...) BTW, How's about that turtle? > - Supposing I can somehow fix the pending problems, what should I do > next after that? dput yet another version and make a notice about > that in comments of this bug #779377 or maybe file another bug > report or what? just re-upload to mentors, and reply to this RFS bug with the changes you did (basically quoting my mail and briefly say on every point what you did.) I'll pick up from there. Don't file another bug. Another note: d/changelog always says only "Initial Release (Closes:#<your-ITP-Bug>) for new packages -- you do not elaborate the above fixes or progress on package, remove old versions from it. > Thanks for your patience, > > -- > Antti Järvinen No problem, every start is difficult. Afterall, I hope that you also start packaging other packages, and the second package will already be much easier ;-) Happy contributing! -- tobi
Attachment:
signature.asc
Description: This is a digitally signed message part