Bug#779377: RFS: classified-ads/0.03-1 / ITP
Tobias Frost writes: Almost... you must regenerate the bitmap during the build. Manually is not enough. (Its ok do do it via d/rules, no need to patch your upstream buildsystem. Remember to clean the generated images, e.g using debian/clean. All right, please see dget -x http://mentors.debian.net/debian/pool/main/c/classified-ads/classified-ads_0.07-1.dsc Had to bump orig.tar.gz version number too as I could not get clean to work cleanly without changes to sources. For this generation purpose there is now build-dependency to imagemagick ; xcftools could not handle scanling+trasparency as required. Thats ok. However, you can also put that file in the repository (debian/gbp.conf) -- git-buildpackage will look there too. It is there, Did you think about pristine-tar, too? as is branch pristine-tar that now should be up-to-date. -- Antti message.txt.asc Description: Message with signature
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Tobias Frost writes: Almost... you must regenerate the bitmap during the build. Manually is not enough. (Its ok do do it via d/rules, no need to patch your upstream buildsystem. Remember to clean the generated images, e.g using debian/clean. Ok, question: Initiating bitmap conversion seems very easy, just by adding into d/rules: override_dh_auto_configure: + cd graphics-highres ; make dh_auto_configure -- CONFIG+=nosilent the line marked with + and both debuild+dpkg-buildpackage seem both happy, as is lintian. The part that concerns me is that this addition overwrites files that are also included in .orig.tar.gz - is this considered bad thing? Having the generated png-files inside tarball is handy for doing build for windows+mac, but if necessary, this could be handled with git branching-tricks quite easily. Btw, I've agreed about identification+pgp-key signing with a DD living in Helsinki area, no date is set yet as I'm some 600km away but it will happen eventually.. -- Antti message.txt.asc Description: Message with signature
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Am Dienstag, den 07.04.2015, 19:21 +0300 schrieb Antti Järvinen: Ok, there is a new version at mentors, available via dget -x http://mentors.debian.net/debian/pool/main/c/classified-ads/classified-ads_0.06-1.dsc Changes compared to previous version are: - dpkg-dev build-dependency gone - Original High-res bitmaps again included, with semi-automatic conversion method. xcf2png could not do resize so imagemagick is used, from a included makefile. Bitmap conversion needs to be initiated manually, dpkg-buildpackage uses files already in .orig.tar if manual update is not triggered first. Almost... you must regenerate the bitmap during the build. Manually is not enough. (Its ok do do it via d/rules, no need to patch your upstream buildsystem. Remember to clean the generated images, e.g using debian/clean. - d/changelog Commit message shortened, timestamp closer to present time. - d/control debhelper version dependency now 9 - Structured d/copyright like this License: A or B or C License A: Grant + reference to text of A License B: Grant + Additional text to B + reference to text of B License C: Grant only as it makes no reference to any external document Also removed trailing whitespaces. - d/rules hardening flag gone - d/watch not changed, looks like github offers only .zip and .tar.gz for tarball dl. - pushed pristine-tar branch to github In ~/.gbp.conf I have [DEFAULT] debian-branch = debian as I wanted to have the future development in master-branch but hopefully it won't complicate work of others. Thats ok. However, you can also put that file in the repository (debian/gbp.conf) -- git-buildpackage will look there too. Did you think about pristine-tar, too? And: [net/retrievalengine.cpp:113]: (error) Dereferencing 'connectCandidate' after it is deallocated / released = Urgh. Gross. Debug build only but still.. - In the source code you've mixed tabs and spaces... Maybe you can work towards a coherrent coding-style-guidline to ease reading of the code? - configure your editor to remove trailing whitespaces :) - check-all-the-things has also some input for you, eg. codespell is a little bit sad and there are warnings from flawfinder regarding potential unsafe use of the random number generator. = Flawfinder is partly right: the traditional libc6 rand() -routines are seeded too but not used for anything sensitive. There are uses. Some flawfingers warnings could be fixed, while they're not outright errors, they're not nice either, for instance frequent usage of fixed-size char-arrays just for sake of formatting strings for log-macro.. Lets at least run code-beautifier once, it will structure the text. astyle style=attach at least unifies the indentation and removes trailing spaces. Emacs configures the user to remove trailing whitespaces when editing. Almost always. Thanks for this :) -- Antti I guess, last iteration, finally. tobi signature.asc Description: This is a digitally signed message part
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Ok, there is a new version at mentors, available via dget -x http://mentors.debian.net/debian/pool/main/c/classified-ads/classified-ads_0.06-1.dsc Changes compared to previous version are: - dpkg-dev build-dependency gone - Original High-res bitmaps again included, with semi-automatic conversion method. xcf2png could not do resize so imagemagick is used, from a included makefile. Bitmap conversion needs to be initiated manually, dpkg-buildpackage uses files already in .orig.tar if manual update is not triggered first. - d/changelog Commit message shortened, timestamp closer to present time. - d/control debhelper version dependency now 9 - Structured d/copyright like this License: A or B or C LicenseA: Grant + reference to text of A License B: Grant + Additional text to B + reference to text of B License C: Grant only as it makes no reference to any external document Also removed trailing whitespaces. - d/rules hardening flag gone - d/watch not changed, looks like github offers only .zip and .tar.gz for tarball dl. - pushed pristine-tar branch to github In ~/.gbp.conf I have [DEFAULT] debian-branch = debian as I wanted to have the future development in master-branch but hopefully it won't complicate work of others. And: [net/retrievalengine.cpp:113]: (error) Dereferencing 'connectCandidate' after it is deallocated / released = Urgh. Gross. Debug build only but still.. - In the source code you've mixed tabs and spaces... Maybe you can work towards a coherrent coding-style-guidline to ease reading of the code? - configure your editor to remove trailing whitespaces :) - check-all-the-things has also some input for you, eg. codespell is a little bit sad and there are warnings from flawfinder regarding potential unsafe use of the random number generator. = Flawfinder is partly right: the traditional libc6 rand() -routines are seeded too but not used for anything sensitive. There are uses. Some flawfingers warnings could be fixed, while they're not outright errors, they're not nice either, for instance frequent usage of fixed-size char-arrays just for sake of formatting strings for log-macro.. Lets at least run code-beautifier once, it will structure the text. astyle style=attach at least unifies the indentation and removes trailing spaces. Emacs configures the user to remove trailing whitespaces when editing. Almost always. -- Antti message.signed.asc Description: Message content with signature
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Am Mittwoch, den 01.04.2015, 22:51 +0300 schrieb Antti Järvinen: Tobias Frost writes: Control: owner -1 ! Control: tags -1 pending Aye, best aprils fool's prank for some time :) https://wiki.debian.org/Mentors/BTS Debian sees the (high-res image) as part of the source code, the preferred form of the source actually. So you should include it into your tarball and create the actual bitmaps at build-time. Hmm, I could do something like introducing a build-time dependency to imagemagick (I think I crafted the lower-resolution bitmaps with gimp by hand) and try to do the format+size conversion tricks with that? Isn't imagemagick a bit huge and unconventional build-dependency? Take a look at xcftools -- xcf2png(1) seems to be the tool you want (not tried, though) Sure, just follow the ITa procedure. (I will also sponsor you on this) ... Its just a git repository ;-) No big risk to ruin everything. You could also move the repository somewhere else, if you don't like collab-maint. Yes, this was actually my question ; is it ok for me to fork the collab-maint repo of qemuctl to some other place (say, github) and make the changelog-change from there and reference that in ITA-ticket? Or is getting write permission to repository in collab-maint a difficult process? Anything goes, my primary interface is anyway git and the address of remote repository is not much an issue.. Look at https://lists.debian.org/debian-devel-announce/2012/01/msg6.html Just ITA my RFA, do 1) from the link and then trigger me on 2). Of course, you can also move the repository somewhere, we can also agree that you work own repository until your account get approved. For the upload procedure: In short-term, yes: You need a sponsor for upload. Mid-Terms: You can become a Debian Maintainer with upload rights for your packages (https://wiki.debian.org/DebianMaintainer) Long-Term: You join the project as Debian Developer Ok, I've read through https://wiki.debian.org/DebianMaintainer and https://wiki.debian.org/DebianMaintainer/Tutorial and feel ok with privileges and responsibilities regarding becoming a maintainer. This anyway looks like the way of least hassle for keeping my packages up-to-date. I'll write about this to debian-devel-announce. Naah, not so fast ;-) First things first. First you need to get some track record as Debian Contributor; so you need first to do some contributions through sponsored uploads, and after a few months of involvement you'll be ready to apply for DM status. An this gives you plenty time to fix this: But here I need advice as https://wiki.debian.org/DebianMaintainer says I'll need a PGP-key with at least 2k key length. The key I used at https://mentors.debian.net/my was my pgp key that I normally use. I don't consider it compromised, it is from year 2000 and has 1k key len - do I fullfill the requirement if I add additional longer encryption key into my current key and replace the key in mentors ; the key in there still has no signatures from any party relevant in this debian process.. pabs already replied on this, so please follow his advice here. Additionally, you can already start to collect signatures on your new, stronger key. e.g take a look at https://wiki.debian.org/Keysigning/Offers#FI; if you go on vacation you can also check there for offers at your destination. (BTW, it is stronlgy recommended to use at least 4096 bits..) And it there any (documented? where? )process for .. situation that a maintainer might face, like 1. notification a new bug report 2. creation of patch 3. ??? 4. upload to ftp.upload.debian.org especially the step three there is interesting.. You should read (also the documents linked at) http://mentors.debian.net/qa, especially the New Maintainers Guide, The Developer's Reference and get familiar with the Debian Policy Manual. That will probably answer most. It also has links where to asks the tricky questions ;-) (e.g debian-devel or debian-mentors mailing lists) 3) is usually (for non DD and DM) 3a) preparing the package, 3b) point your sponsor to it, 3c) sponsor checks it and if ok, 3d) the sponsor uploads it. In long term I can consider trying to become DD too. But lets start with small amount of packages.. Yes, first things first ;) Anyway DD status is not achieved with a certain amount of packages, but with the experience/knowledge gained on the way. But lets just start with first steps... I'll happy to help you as your sponsor here. I saw that debian/source/format is missing in the repository. Ahem. Not any more. -- Antti Let me come back to the original topic of #779377 in a separate mail. -- tobi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1428047155.2397.38.ca...@debian.org
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Am Mittwoch, den 01.04.2015, 22:51 +0300 schrieb Antti Järvinen: back to the package: Hmm, I could do something like introducing a build-time dependency to imagemagick (I think I crafted the lower-resolution bitmaps with gimp by hand) and try to do the format+size conversion tricks with that? The image topic is not solved yet, as written earlier: Take a look at xcftools -- xcf2png(1) seems to be the tool you want (not tried, though) d/changelog: remove the reference to experimental. (and please update the timestamp; hint: dch -r ) d/control: It is sufficient to depend on debhelper 9, (9~ is not required.) d/copyright: We're almost there... The paragraph at line 37 is not yet right. If you have in a Files: section License A or B or C those are actually 3 licenses, which needs each of them its own paragraph. Continuing this abstraced example, you'd have: Files: ... License: A or B or C License A: Grant + Text of A License B: Grant + Text of B License C: Grant + Text of B One of them will be LGPL-2.1-with-Nokia-Exception For this, your d/copyright is incomplete: You have to quote the *complete* license text, namely the content of the LGPL_EXCEPTION.txt file in d/copyright; a reference to it is not enough. There a a few trailing whitespaces in the file d/rules: the second export line can go. Hardeing is enabled with compat level =9. d/watch: It is best practice to use a more broad file extension regex: \.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) (refer to: https://wiki.debian.org/debian/watch#Common_mistakes) (But I do not know if if github offers something better(tm) than gz when releasing tarballs.) The git repositroy should also have a pristine-tar branch to keep the orig.tar.gz in the repository. gbp-importorig(1) could help you here, even if that is not the original intention of this command and might need cleanup e.g tags and brancheslater.) (see the pristine-tar option; you might need a temporary branches and tell it not to merge; you maybe also want to delete extra tags it creates..) This should to it, YMMV: git checkout master git checkout -b tmp git checkout debian \ gbp import-orig --no-merge --pristine-tar --no-interactive \ --upstream-branch=tmp ../classified-ads_0.05.orig.tar.gz (of course you can also use pristine-tar(1) directly, but I'd play with gbp to see how gbp is doing it and the resulting pristine-tar-branch structure) Please check this if it is valid: $ cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not find or open any of the paths given.' [net/retrievalengine.cpp:113]: (error) Dereferencing 'connectCandidate' after it is deallocated / released (not required for the upload but on my wishlist:) - You have a testsuite which may should be run at buildtime and at ci.debian.net - In the source code you've mixed tabs and spaces... Maybe you can work towards a coherrent coding-style-guidline to ease reading of the code? - configure your editor to remove trailing whitespaces :) - check-all-the-things has also some input for you, eg. codespell is a little bit sad and there are warnings from flawfinder regarding potential unsafe use of the random number generator. -- tobi signature.asc Description: This is a digitally signed message part
Bug#779377: RFS: classified-ads/0.03-1 / ITP
On Thu, Apr 2, 2015 at 3:51 AM, Antti Järvinen wrote: I'll write about this to debian-devel-announce. That is only for announcements :) But here I need advice as https://wiki.debian.org/DebianMaintainer says I'll need a PGP-key with at least 2k key length. The key I used at https://mentors.debian.net/my was my pgp key that I normally use. I don't consider it compromised, it is from year 2000 and has 1k key len - do I fullfill the requirement if I add additional longer encryption key into my current key and replace the key in mentors ; the key in there still has no signatures from any party relevant in this debian process.. OpenPGP keys of 1024 bits are considered trivially breakable by well funded organisations: https://help.riseup.net/en/security/message-security/openpgp/best-practices#use-a-strong-primary-key Please read through the OpenPGP best practices and do a transition to a 4096-bit key: https://help.riseup.net/security/message-security/openpgp/best-practices -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6eqpm05bo2-rgewrhae59mmenzcstwfhp5csnho6hb...@mail.gmail.com
Bug#779377: RFS: classified-ads/0.03-1 / ITP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tobias Frost writes: Control: owner -1 ! Control: tags -1 pending Aye, best aprils fool's prank for some time :) Debian sees the (high-res image) as part of the source code, the preferred form of the source actually. So you should include it into your tarball and create the actual bitmaps at build-time. Hmm, I could do something like introducing a build-time dependency to imagemagick (I think I crafted the lower-resolution bitmaps with gimp by hand) and try to do the format+size conversion tricks with that? Isn't imagemagick a bit huge and unconventional build-dependency? Sure, just follow the ITa procedure. (I will also sponsor you on this) ... Its just a git repository ;-) No big risk to ruin everything. You could also move the repository somewhere else, if you don't like collab-maint. Yes, this was actually my question ; is it ok for me to fork the collab-maint repo of qemuctl to some other place (say, github) and make the changelog-change from there and reference that in ITA-ticket? Or is getting write permission to repository in collab-maint a difficult process? Anything goes, my primary interface is anyway git and the address of remote repository is not much an issue.. For the upload procedure: In short-term, yes: You need a sponsor for upload. Mid-Terms: You can become a Debian Maintainer with upload rights for your packages (https://wiki.debian.org/DebianMaintainer) Long-Term: You join the project as Debian Developer Ok, I've read through https://wiki.debian.org/DebianMaintainer and https://wiki.debian.org/DebianMaintainer/Tutorial and feel ok with privileges and responsibilities regarding becoming a maintainer. This anyway looks like the way of least hassle for keeping my packages up-to-date. I'll write about this to debian-devel-announce. But here I need advice as https://wiki.debian.org/DebianMaintainer says I'll need a PGP-key with at least 2k key length. The key I used at https://mentors.debian.net/my was my pgp key that I normally use. I don't consider it compromised, it is from year 2000 and has 1k key len - do I fullfill the requirement if I add additional longer encryption key into my current key and replace the key in mentors ; the key in there still has no signatures from any party relevant in this debian process.. And it there any (documented? where? )process for .. situation that a maintainer might face, like 1. notification a new bug report 2. creation of patch 3. ??? 4. upload to ftp.upload.debian.org especially the step three there is interesting.. In long term I can consider trying to become DD too. But lets start with small amount of packages.. I saw that debian/source/format is missing in the repository. Ahem. Not any more. - -- Antti -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iEYEARECAAYFAlUcTCEACgkQUTdja+nNMWNAgQCdGEHMEYi46hA7ugWAUQYxYMKZ cG8AnR8YeSh6jXiwCig7rlH2NSvZH/q4 =MObn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21788.19541.463232.147...@muikku.katiska.org
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Control: owner -1 ! Control: tags -1 pending # (above means: I will sponsor you) Am Samstag, den 28.03.2015, 23:34 +0200 schrieb Antti Järvinen: Tobias Frost writes: Am Donnerstag, den 26.03.2015, 01:19 +0200 schrieb Antti Järvinen: E: classified-ads source: depends-on-build-essential-package-without-using-version dpkg-dev so the version numbers remain. You probably do not need the dpkg-dev dependency at all, do you? I was under impression that dpkg-shlibdeps comes from dpkg-dev. pbuilder seems to happily build without and lintian is not complaining - away it goes.. dpkg-dev pulled in by build-essential and therefore you do not need to exclitly state it, except if you have a version constraint. (need a minimum version of dpkg-dev; (read the description on the above quoted lintian error; this also points you to Policy §4.2) You need to add -b debian then to VCS-Git (Refer to Policy 5.6.26) Yes. Well, you should not copy the license *text* into d/copyright, but you still need to put the license *grant* into it. The license grant is the header of your source files. So, you'd write License: LGPL-2.1+ Classified Ads is free software; you can redistribute it and/or ... Ok, I'll try restructuring. Software aside, this seems like complexiest thing ever.. No doubt, Copyright is complex; and this also very usual that sponsorees don't get it right the few first times :) But looking at the repository it looks fine now. (Though I will do a final copyright check just before uploading -- because this topic is complex and it is easy to overlook something.) general: - Huge high-resolution bitmaps removed from source Not checked in the code, but this raises a flag: In Debian you need to have the source in the preferred form for modifications and for images this is the _best_ resolution. (And as said earlier, you need to compute the lower resolution at build time) Bitmaps are not modified at build-time, only wrapped into qt-format resource file. The binary .deb contains actually exactly same bits in bitmaps that are in orig.tar.gz. I was thinking about keeping the high-resolution gimp files in upstream repo anyway but not in source package as there is no transform done.. No, you've got me wrong... In Debian we build *everything* from source. Spoken in source code analogy: Your high resolution file is the source (like a cpp file) code, the bitmap is the object code: As like you need to compile your cpp file, you must regenerate the bitmap during the build from the highres image. Debian sees the (high-res image) as part of the source code, the preferred form of the source actually. So you should include it into your tarball and create the actual bitmaps at build-time. Did not check the code, but you also ensure that the RAM is not swapped out? Yes and no. For actual key handling the task is outsourced to OpenSSL and I hope it is doing the Right Thing (starting from 1.0.1g it actually might, seems..). For content no, it is all over the place and goes through qt code also so I think easiest would be to flag the whole process out of swap if possible. After the heartbleed episode I marked a future development task of moving all key-handling into separate process, away from process where networking happens. ..the paranoid operators will have no swap or encrypted swap. ..but I've tried to keep things simple also for end-users. Here you get automatic content signing+encryption always whenever possible. Still I wouldn't like to start adding a manpage section about setting up encrypted swap. Fine with me, just wanted to know if you put some thoughts into this aspect. Regarding my question regarding your plans for involvement into Debian -- Do you want to share your thoughts about this? I've been trying to get involved into group things, as I was thinking this is kind of soft-landing into debian process. I've been in discussion with openssl team but then received no definite yes/no answer from them, nor any concrete work items to start working with. In the meantime I've been trying to do reviews on tickets that no-one has yet checked. Yes I saw it; thank you a lot. I noticed you had been marketing qemuctl in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780270 so if I say that I know qt and qemu in advance (I do) and after half-hour study about understand the qemuctl behaviour, you think I could ITA this package? Sure, just follow the ITa procedure. (I will also sponsor you on this) .. the part that I'm worried about is the mechanics of actual releasing (done in collab-maint?) so that I won't wreck the whole distro.. Its just a git repository ;-) No big risk to ruin everything. You could also move the repository somewhere else, if you don't like collab-maint. I'm not lazy, but this qemuctl looks like a low-maintenance work-item to me. ..isn't the
Bug#779377: RFS: classified-ads/0.03-1 / ITP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tobias Frost writes: Am Donnerstag, den 26.03.2015, 01:19 +0200 schrieb Antti Järvinen: E: classified-ads source: depends-on-build-essential-package-without-using-version dpkg-dev so the version numbers remain. You probably do not need the dpkg-dev dependency at all, do you? I was under impression that dpkg-shlibdeps comes from dpkg-dev. pbuilder seems to happily build without and lintian is not complaining - away it goes.. You need to add -b debian then to VCS-Git (Refer to Policy 5.6.26) Yes. Well, you should not copy the license *text* into d/copyright, but you still need to put the license *grant* into it. The license grant is the header of your source files. So, you'd write License: LGPL-2.1+ Classified Ads is free software; you can redistribute it and/or ... Ok, I'll try restructuring. Software aside, this seems like complexiest thing ever.. general: - Huge high-resolution bitmaps removed from source Not checked in the code, but this raises a flag: In Debian you need to have the source in the preferred form for modifications and for images this is the _best_ resolution. (And as said earlier, you need to compute the lower resolution at build time) Bitmaps are not modified at build-time, only wrapped into qt-format resource file. The binary .deb contains actually exactly same bits in bitmaps that are in orig.tar.gz. I was thinking about keeping the high-resolution gimp files in upstream repo anyway but not in source package as there is no transform done.. Did not check the code, but you also ensure that the RAM is not swapped out? Yes and no. For actual key handling the task is outsourced to OpenSSL and I hope it is doing the Right Thing (starting from 1.0.1g it actually might, seems..). For content no, it is all over the place and goes through qt code also so I think easiest would be to flag the whole process out of swap if possible. After the heartbleed episode I marked a future development task of moving all key-handling into separate process, away from process where networking happens. ..the paranoid operators will have no swap or encrypted swap. ..but I've tried to keep things simple also for end-users. Here you get automatic content signing+encryption always whenever possible. Still I wouldn't like to start adding a manpage section about setting up encrypted swap. Regarding my question regarding your plans for involvement into Debian -- Do you want to share your thoughts about this? I've been trying to get involved into group things, as I was thinking this is kind of soft-landing into debian process. I've been in discussion with openssl team but then received no definite yes/no answer from them, nor any concrete work items to start working with. In the meantime I've been trying to do reviews on tickets that no-one has yet checked. I noticed you had been marketing qemuctl in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780270 so if I say that I know qt and qemu in advance (I do) and after half-hour study about understand the qemuctl behaviour, you think I could ITA this package? .. the part that I'm worried about is the mechanics of actual releasing (done in collab-maint?) so that I won't wreck the whole distro.. I'm not lazy, but this qemuctl looks like a low-maintenance work-item to me. ..isn't the very idea of collab-maint to have group of maintainers so I'd have someone to ask for help in the beginning? I've been using linux since kernel 0.98, I'm no newbie, I do sw development for living, but about packaging I've been only on installation side this far - if I'm about to release a new version of any package, someone else will still need to review my work before it gets uploaded into actual releasing, right? If I take one package first, see how get things done and if time permits, adopt more packages after I know the releasing mechanics, does that sound fair? As said, I'm not lazy and in the beginning said that I can contribute to overall process too. There is a new upload to mentors with same version number (0.05-1) that has changes to d/copyright and d/control. - -- Antti -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFVFx5GUTdja+nNMWMRAuQYAJ9zZZjCOSr4gnuQjlpuatDhrhm2CQCfXGPT nP6F8ePNdvGGThLGAmthP9w= =w25K -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21783.7752.589884.389...@muikku.katiska.org
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Am Donnerstag, den 26.03.2015, 01:19 +0200 schrieb Antti Järvinen: Dear Sirs, there is now a new version available at dget -x http://mentors.debian.net/debian/pool/main/c/classified-ads/classified-ads_0.05-1.dsc After I have agreement with a sponsor, a re-re-review would be in order. The new-emitted lintian warning unused-license-paragraph-in-dep5-copyright isn't exactly true, I think lintian fails to parse line License: LGPL-2.1-with-Nokia-Exception or GPL-3.0 or Nokia-nonfree that does make reference to LGPL-2.1 that indeed is included. This version tries to address all previously raised issues, including: d/changelog: - Removed changelog, added new with dch. Debian version is -1. Distribution is unstable instead of experimental. Wrap-and-sort run. d/control - Cdbs now gone, I'm still not sure about d/rules format if it conforms to dh9 format but at least it is simple. Looks good. If there is no version numbers in debhelper or dpkg-dev then lintian thinks that W: classified-ads source: package-needs-versioned-debhelper-build-depends 9 E: classified-ads source: depends-on-build-essential-package-without-using-version dpkg-dev so the version numbers remain. You probably do not need the dpkg-dev dependency at all, do you? libqt4-sql-sqlite dependency remains as it is used at runtime only and sw is not functional without. Rest of the lib-deps are gone. - Added Cvs-Git and Vcs-Browser. Debian packaging files are in branch debian of repo pointed by Cvs-Git. You need to add -b debian then to VCS-Git (Refer to Policy 5.6.26) - Changed maintainer e-mail addr d/copyright - Changed to look like example above. Also added LGPL_EXCEPTION.txt from original nokia sources into source code. LGPL is not included verbatim in d/copyright to avoid E: classified-ads: copyright-should-refer-to-common-license-file-for-lgpl instead a reference is made. Well, you should not copy the license *text* into d/copyright, but you still need to put the license *grant* into it. The license grant is the header of your source files. So, you'd write License: LGPL-2.1+ Classified Ads is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. . Classified Ads is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. . On Debian systems, the full text of the GNU Lesser General Public License version 2.1 can be found in the file `/usr/share/common-licenses/LGPL-2.1'. The first two paragraphs are the license grant, the last one is the reference to the license text. Note, that your section for LGPL-2.1 is counted as unused as it is not used as a license of its own. Here you would delete this and add the On Debian ... sentences to the license grants of the complex license LGPL-2.1-with-Nokia-Exception or GPL-3.0 or Nokia-nonfree general: - Huge high-resolution bitmaps removed from source Not checked in the code, but this raises a flag: In Debian you need to have the source in the preferred form for modifications and for images this is the _best_ resolution. (And as said earlier, you need to compute the lower resolution at build time) - Manpage again slightly re-visited - Binary has a lot of key-handling inside. General rule is that no plaintext private keys end up in filesystem file, that kind of material is kept in RAM only. Same applies to content originally sent encrypted, unless user specifically exports a file. Did not check the code, but you also ensure that the RAM is not swapped out? - Db file mode is set to 0600, good and rather obvious improvement - Lintian is now mostly quiet. -- Antti Järvinen This is only a short review -- I did only check above points due to limited time. One point I spotted is that d/control still has a himself, please rewrite gender neutral. Regarding my question regarding your plans for involvement into Debian -- Do you want to share your thoughts about this? -- tobi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1427488236.1884.26.ca...@debian.org
Bug#779377: RFS: classified-ads/0.03-1 / ITP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Sirs, there is now a new version available at dget -x http://mentors.debian.net/debian/pool/main/c/classified-ads/classified-ads_0.05-1.dsc After I have agreement with a sponsor, a re-re-review would be in order. The new-emitted lintian warning unused-license-paragraph-in-dep5-copyright isn't exactly true, I think lintian fails to parse line License: LGPL-2.1-with-Nokia-Exception or GPL-3.0 or Nokia-nonfree that does make reference to LGPL-2.1 that indeed is included. This version tries to address all previously raised issues, including: d/changelog: - - Removed changelog, added new with dch. Debian version is -1. Distribution is unstable instead of experimental. Wrap-and-sort run. d/control - - Cdbs now gone, I'm still not sure about d/rules format if it conforms to dh9 format but at least it is simple. If there is no version numbers in debhelper or dpkg-dev then lintian thinks that W: classified-ads source: package-needs-versioned-debhelper-build-depends 9 E: classified-ads source: depends-on-build-essential-package-without-using-version dpkg-dev so the version numbers remain. libqt4-sql-sqlite dependency remains as it is used at runtime only and sw is not functional without. Rest of the lib-deps are gone. - - Added Cvs-Git and Vcs-Browser. Debian packaging files are in branch debian of repo pointed by Cvs-Git. - - Changed maintainer e-mail addr d/copyright - - Changed to look like example above. Also added LGPL_EXCEPTION.txt from original nokia sources into source code. LGPL is not included verbatim in d/copyright to avoid E: classified-ads: copyright-should-refer-to-common-license-file-for-lgpl instead a reference is made. general: - - Huge high-resolution bitmaps removed from source - - Manpage again slightly re-visited - - Binary has a lot of key-handling inside. General rule is that no plaintext private keys end up in filesystem file, that kind of material is kept in RAM only. Same applies to content originally sent encrypted, unless user specifically exports a file. - - Db file mode is set to 0600, good and rather obvious improvement - - Lintian is now mostly quiet. - -- Antti Järvinen -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFVE0J1UTdja+nNMWMRAmhhAJ9zMxg+U5js/svrWkpb915DGqXusgCcCAVQ geT40FPKT97SpxOMXQsV0nQ= =9mNp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21779.17039.957398.299...@muikku.katiska.org
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Hallo Antti,
yes, I received your mail already, but I simply did not have time to
take another look.
Formally I have to state that I did not yet decide if I sponsor this
package, but of course do the offered review.
Am Donnerstag, den 12.03.2015, 08:16 +0200 schrieb Antti Järvinen:
Tobias Frost writes:
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.
Hello Tobias,
I think I left you out of loop for my latest comments regarding my ITP
bug at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779377 ; do
you think there is still something to do regarding packaking/licensing
etc.?
If this thing moves forward, maintenance within collab-maint is very
ok for me, especially if collaboration means also that that there is
someone who might help me when I'm about to commit potentially
disastrous actions..as said, I'm long-time debian user, have some
years behind in various sw development circles but I'm totally clueless
about ways of getting things done iwnside debian organization.
--
Antti Järvinen
Ok, let's do another round of review.
- please use wrap-and-sort(1), this makes reviewing easier and looks
nicer.
d/changelog:
- Debian version part needs to be -1 (do not iterate it until uploaded
the first time)
- As this is a new package, you can upload to unstable; one should only
package refrain when there is already a package in testing -- to avoid
disruption. (Sorry, I know you changed that before; but Riley was wrong
here.)
- There are extra trailing spaces..
- Do you know dch(1)?
d/control:
- Why did you switch do cdbs? (I do not sponsor packages using cdbs)
- You have both B-Ds on cdbs and debhelper. The version = on debhelper
is not needed; its as already fulfilled by wheezy. Same for dpkg-dev.
- You MUST NOT specify libraries dependencies for your binary package
-- this is what ${shlibs:Depends} is supposed to do for you.
- In the description, there is an extra space before a ;. It should
be also written gender neutral.
- VCS-* fields are missing.
- You are aware that libgcrypt-dev | libgcrypt11-dev will always select
libgcrypt-dev on the buildds? (That's ok, but you just need to be aware)
- Please do not use a pacakge-related email adress for Maintainer.
You certainly can have something like deb...@katiska.org, but avoid
having the package name in it. (see also the end of this mail for a
rationale; Debian tools usually associate you by your mail, and if you
have more than one package with different emails that won't work well)
d/copyright:
- You do not need to repeat the License-Text for the same license. Just
use Licene: license for the Files section and have a dedicated
License: Paragraph with the actual License text e.g at the end of the
file. Sketch:
Files: a
Copyright: 2015 foo bar
License: LGPL-2.1
Files: b
Copyright: 2014 joe doe
License: LGPL-2.1
License: LGPL-2.1
GNU Lesser General (...)
(PS: No need to repeat the Words (C) Copyright in the Copyright lines;
Just the names are ok.)
Nokia-Part: You need to have the _verbatim_ copy of the license grant.
Yours is two paragaphs too short, and the License is actually
LGPL-2.1-with-Nokia-Exception or GPL-3.0 or Nokia-nonfree. You need
then also to provide that file in your sources and also have this text
in the License paragraph.
Nokia-nonfree refers to the last paragraph starting with the headline
Other Usage
(I did not yet check remaining d/copyright for completeness and
correctness)
- turt*.png
(Upstream advice: There are many coppies of your turtle in the
repository. You should only keep one. Do you really need also the gimp
files for the small ones? I'd clean up a little; But this is not
related to the Debian packaging)
For Debian it is required that you build everything from source.
Let's say that your turtle with the highest resolution is your source.
You then need to regenerate all the small versions at build time.
- classified-ad.1
It is usual that user data is not removed from $HOME/ upon uninstall,
but it is unusual to tell that the user in the manpage.
So should rephrase that, maybe under a Files section in the manpage
that user data is stored here and contains encryption keys.
Some stupid question regarding this (I did not run your programm yet):
Do they need to be safeguarded, btw? Is there a password on them?
Are the access rights to the database set to sane values, so that only
the user can access (e.g. 0600)
- d/rules
Sorry, I do not sponsor cdbs based packages.
Some lintian messages:
I: classified-ads: spelling-error-in-binary usr/bin/classified-ads
altough although
P: classified-ads: no-upstream-changelog
I: classified-ads: using-first-person-in-description line 5: me
I: classified-ads: hyphen-used-as-minus-sign
usr/share/man/man1/classified-ads.1.gz:11
I: classified-ads: desktop-entry-lacks-keywords-entry
Bug#779377: RFS: classified-ads/0.03-1 / ITP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tobias Frost writes: d/control: - Why did you switch do cdbs? (I do not sponsor packages using cdbs) All right, thank you for comprehensive look at things. Cdbs allowed me to have basically empty d/rules as I could not figure out how I was in disagreement with dh9 format of d/rules. Debhelper is quite enough for building the package, just the makefile format was the issue. But ok, I'll have a look at these issues. - -- Antti -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFVBfitUTdja+nNMWMRAph/AJ9P7r2mALZcbCq7fHI3Gz0CS6OCsQCgh9hK mI5AW7EwwkOz9fBX6khc8Uk= =9ArL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21765.63698.615757.547...@muikku.katiska.org
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Am Sonntag, den 15.03.2015, 23:25 +0200 schrieb Antti Järvinen: Tobias Frost writes: d/control: - Why did you switch do cdbs? (I do not sponsor packages using cdbs) All right, thank you for comprehensive look at things. Cdbs allowed me to have basically empty d/rules as I could not figure out how I was in disagreement with dh9 format of d/rules. Debhelper is quite enough for building the package, just the makefile format was the issue. Usually, debhelper short format is also quite straight forward. Let me know if you need hints or where you are stuck. But ok, I'll have a look at these issues. -- Antti -- tobi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1426457934.3105.22.ca...@debian.org
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Riley Baird writes: ... just two more things: -Add a d/source/format containing the only the string 3.0 (quilt) (without the quotation marks). This ensures that your package will use the new format for any patches you may make in future. -You can add a d/watch file to check for upstream releases. I made one that you can use from the uscan manpage: version=3 https://github.com/operatornormal/classified_ads/tags (?:.*/)?v?(\d[\d \.]*)\.tar\.gz Ok, in version 0.04-2 that is visible at http://mentors.debian.net/package/classified-ads those 3 modifications are now done (source/format, watch-file and the closed bug #). Looks like uscan was able to correctly pick up the releases from github. -- Antti -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21756.8784.639671.966...@muikku.katiska.org
Bug#779377: Fw: Re: Bug#779377: RFS: classified-ads/0.03-1 / ITP
So, does it look any better now? Yes, a lot better! You're almost there, but just two more things: -Add a d/source/format containing the only the string 3.0 (quilt) (without the quotation marks). This ensures that your package will use the new format for any patches you may make in future. -You can add a d/watch file to check for upstream releases. I made one that you can use from the uscan manpage: version=3 https://github.com/operatornormal/classified_ads/tags (?:.*/)?v?(\d[\d \.]*)\.tar\.gz By the way, I just sent you a message using classified-ads! pgpUHj9LMQufE.pgp Description: PGP signature
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Tobias Frost writes: 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. Dear Sirs, I've made some updates to my package, it should available by saying dget -x http://mentors.debian.net/debian/pool/main/c/classified-ads/classified-ads_0.04-1.dsc I picked up items from discussion of bug #779377 and tried to address them somehow, please see following list: d/changelog: -This file should only contain Debian-related changes. Upstream changes -You won't be able to upload to unstable at the moment, since it's frozen for jessie. You should change this to experimental. = Cleaned up, target is experimental, added Closes: -tag d/compat: -Debhelper 7 is old. You should switch to 9. = Changed d/classified-ads.1: -You should include this with the software, not just in Debian. -You should get rid of the comments explaining what nroff is. -You note that Upon uninstall of the program, the datafile is left lingering around. You might want to ask someone else, but this seems like bad practice. = Moved manpage, removed comments remaining from template and adjusted the text a bit. Reason for leaving the datafile still remains but instructions have been added. d/control: -Priority should be optional, not extra. -Either fill in the Vcs-* fields, or get rid of them. -You've listed some dependencies twice: once in d/classified-ads.substvars, and once in d/control. -The long description of your package has some spelling/grammatical errors and is a bit short. Perhaps you could take some of the information off your homepage and put it there? = Changed priority, removed Vcs- -field, substvars gone as not needed. Long description made longer. libqt4-sql-sqlite dependency is not obvious at compile time so it must remain. For some reason dpkg-buildpackage does not pick up dep to to libssl so it remains to be manually listed d/copyright: -You should use DEP-5 copyright = modified format, also changed license GPL3 - LGPL2.1. d/docs: -If you don't have any docs, get rid of this file. Otherwise, put them in there. = Removed d/README.source: *Delete this file if there is no reason to keep it. = Removed d/rules: -You'll need to update this to dh9 syntax. See here for a guide: https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules = Simplified somewhat. General: -It's a good idea to keep Debian development and upstream development separate. Don't include the debian/ directory with your upstream tarballs. = In version control debian/ -directory is in different branch and gbp buildpackage seems to correctly exclude that. (side note, how do I get gbp buildpackage to correctly sign my changes file with GPG or does it sign only git commits or what?) -I don't think that Debian can legally distribute classified-ads, since Nokia has not made the OpenSSL exception. On the other hand, I'm not sure if the LGPL cancels this out. I'm going to ask debian-legal. = License is now LGPL - Another first-sight: icon.png? Somehow does not relate to my perceived use of the program = Was historical remains, not there any more - Why have your source-files have the executeable bit set? = Interesting note. Mode has been changed. - I'd also know where is the source of the icons? (in images/*)? The image in ui Lenin-reading-pravda is probably still under copyright protection at least in some countries. This would mean you can not distribute it. However, IANAL. (There are also some other png which copyright is unclear) = now included in copyright and Lenin has been replaced with Stal^H^H^H^H static text. - Why do you need to manually add dependencies to libraries in your binary package? = Some removed. Sqlite must be manually added as it needed at runtime only, about openssl I don't know why it is not picked up automatically.. So, does it look any better now? -- Antti Järvinen -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21752.45978.244435.970...@muikku.katiska.org
Bug#779377: RFS: classified-ads/0.03-1 / ITP
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 signature.asc Description: This is a digitally signed message part
Bug#779377: RFS: classified-ads/0.03-1 / ITP
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 with the fact that the text editor code from Nokia is in LGPL too.. - ..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? - 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? - 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? Thanks for your patience, -- Antti Järvinen -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21745.56341.680811.785...@muikku.katiska.org
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Am Samstag, den 28.02.2015, 12:16 +1100 schrieb Riley Baird: I am looking for a sponsor for my package classified-ads That's great! I'm not a DD, so I can't sponsor your package, but I've had a look at it, and here are some things that I've noticed: d/changelog: -This file should only contain Debian-related changes. Upstream changes -You won't be able to upload to unstable at the moment, since it's frozen for jessie. You should change this to experimental. actually, in this case unstable is fine -- That package is new, so it won't interfere with Jessie. However the problems reported by Antti below are valid, you 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. Please also check if you can relicense with the OpenSSL exception. I did not really take a deep look at the package (I prefer that you fix the below first, especially the licensing), but for those where things I saw when browsing it: package-description in debian/control is nothing-saying. Or is this programm only good if you need a new bike? See Policy 3.4 Another first-sight: icon.png? Somehow does not relate to my perceived use of the program Why have your source-files have the executeable bit set? d/docs is 0 bytes long. I'd also know where is the source of the icons? (in images/*)? The image in ui Lenin-reading-pravda is probably still under copyright protection at least in some countries. This would mean you can not distribute it. However, IANAL. (There are also some other png which copyright is unclear) Please also consider running wrap-and-sort -- for example this removes trailing whitespaces and sorts your deps. Why do you need to manually add dependencies to libraries in your binary package? d/compat: -Debhelper 7 is old. You should switch to 9. d/classified-ads.1: -You should include this with the software, not just in Debian. -You should get rid of the comments explaining what nroff is. -You note that Upon uninstall of the program, the datafile is left lingering around. You might want to ask someone else, but this seems like bad practice. Just remove that sentence. (We do not delete files from $HOME upon uninstall) d/control: -Priority should be optional, not extra. -Either fill in the Vcs-* fields, or get rid of them. Remark: I'll only sponsor packages when the packaging is held in a repository. (That's not required by the Policy, but it is in my sponsoring policy) -You've listed some dependencies twice: once in d/classified-ads.substvars, and once in d/control. -The long description of your package has some spelling/grammatical errors and is a bit short. Perhaps you could take some of the information off your homepage and put it there? d/copyright: -You should use DEP-5 copyright d/docs: -If you don't have any docs, get rid of this file. Otherwise, put them in there. d/README.source: *Delete this file if there is no reason to keep it. d/rules: -You'll need to update this to dh9 syntax. See here for a guide: https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules General: -It's a good idea to keep Debian development and upstream development separate. Don't include the debian/ directory with your upstream tarballs. -I don't think that Debian can legally distribute classified-ads, since Nokia has not made the OpenSSL exception. On the other hand, I'm not sure if the LGPL cancels this out. I'm going to ask debian-legal. Good luck getting your package into Debian, Riley Bairdhttp://mentors.debian.net/debian/pool/main/c/classified-ads/classified-ads_0.03-1.dsc (PS: Please configure your MTA to wrap your lines automatically) -- tobi signature.asc Description: This is a digitally signed message part
Bug#779377: RFS: classified-ads/0.03-1 / ITP
On Sat, Feb 28, 2015 at 11:17 PM, Antti Järvinen wrote: - The Lenin photograph, according to http://en.wikipedia.org/wiki/Newspaper#mediaviewer/File:Lenin_reading_Pravda.gif A better link: https://en.wikipedia.org/wiki/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? According to the above page, Pyotr died in 1963 and was Russian. According to the Wikipedia page on copyright length, Russian copyright lasts the life of the author plus 70 years. So the image is not in the public domain in Russia yet. Many other countries have the same period so distribution of the image by Debian mirrors could constitute a copyright violation in some places. It has expired to the public domain in countries where the standard is life+50 years. https://en.wikipedia.org/wiki/List_of_countries%27_copyright_length -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6g+3xgytjo-bqdve+hz+kzjswf6uax1lc9nuicka25...@mail.gmail.com
Bug#779377: RFS: classified-ads/0.03-1 / ITP
I am looking for a sponsor for my package classified-ads That's great! I'm not a DD, so I can't sponsor your package, but I've had a look at it, and here are some things that I've noticed: d/changelog: -This file should only contain Debian-related changes. Upstream changes -You won't be able to upload to unstable at the moment, since it's frozen for jessie. You should change this to experimental. d/compat: -Debhelper 7 is old. You should switch to 9. d/classified-ads.1: -You should include this with the software, not just in Debian. -You should get rid of the comments explaining what nroff is. -You note that Upon uninstall of the program, the datafile is left lingering around. You might want to ask someone else, but this seems like bad practice. d/control: -Priority should be optional, not extra. -Either fill in the Vcs-* fields, or get rid of them. -You've listed some dependencies twice: once in d/classified-ads.substvars, and once in d/control. -The long description of your package has some spelling/grammatical errors and is a bit short. Perhaps you could take some of the information off your homepage and put it there? d/copyright: -You should use DEP-5 copyright d/docs: -If you don't have any docs, get rid of this file. Otherwise, put them in there. d/README.source: *Delete this file if there is no reason to keep it. d/rules: -You'll need to update this to dh9 syntax. See here for a guide: https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules General: -It's a good idea to keep Debian development and upstream development separate. Don't include the debian/ directory with your upstream tarballs. -I don't think that Debian can legally distribute classified-ads, since Nokia has not made the OpenSSL exception. On the other hand, I'm not sure if the LGPL cancels this out. I'm going to ask debian-legal. Good luck getting your package into Debian, Riley Baird pgpXjmJ8luLC3.pgp Description: PGP signature
Bug#779377: RFS: classified-ads/0.03-1 / ITP
Package: sponsorship-requests Version: 0.03 Severity: wishlist Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package classified-ads * Package name: classified-ads Version : 0.03-1 Upstream Author : Antti Järvinen classified-ads.questi...@katiska.org * URL : http://katiska.org/classified_ads/ * License : GPLv3+ Section : net It builds those binary packages: classified-ads - Program for displaying classified advertisement items To access further information about this package, please visit the following URL: http://mentors.debian.net/package/classified-ads Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/classified-ads/classified-ads_0.03-1.dsc I've uploaded a package into mentors.debian.net in a hope that others too will find it useful. It is my own attempt to handle human-to-human communications inside internet, from end-users perspective. As a long-time internet-user this is to-day more or less the way I see how messaging should happen. Features of the program include, but are not limited to: * Sending and retrieving messages public and private, between humans or inside groups * No need for server-side support of any kind * Minimal hassle for the end-user * No need for contracts with any service-operators, not counting your ISP * Identification of message senders while allowing some withdrawal of personal details * Text-based search of public posting * Unfortunately no text-based or mobile UI yet, only Qt. * Early stage of development ; while basic functions seem to be all right there is surely bugs, featuresand 2 million fatal errors. As developer and user of the program I naturally will maintain it for debian too. I'm not member of any packaging team but if I can give my hand to any team interested, with my limited resources. I'm not a debian developer so I'm seeking for a sponsor to have a look at my sw ; please take contact via e-mail or to classified ads operator 6AC2D159AB3A0B0F241DD6D12E4A1673588DD0E8 that is the operator address for my private messages. -- Antti Järvinen, Oulu, Finland Changes since the last upload: * no changes -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.14-2-686-pae (SMP w/1 CPU core) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150227210804.16934.51869.report...@muikku.katiska.org
