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#781701: marked as done (RFS: node-convert-source-map/1.0.0-1 [ITP])
Your message dated Fri, 03 Apr 2015 16:59:40 +0200 with message-id 551eaadc.1010...@xs4all.nl and subject line RFS: node-convert-source-map/1.0.0-1 [ITP] [uploaded] has caused the Debian Bug report #781701, regarding RFS: node-convert-source-map/1.0.0-1 [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 781701: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781701 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package node-convert-source-map * Package name: node-convert-source-map Version : 1.0.0-1 Upstream Author : Thorsten Lorenz thlor...@gmx.de (http://thlorenz.com) * URL : https://github.com/thlorenz/convert-source-map * License : Expat Section : web It builds this binary package: node-convert-source-map - Converts a source-map from/to between formats To access further information about this package, please visit the following URL: http://mentors.debian.net/package/node-convert-source-map Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/node-convert-source-map/node-convert-source-map_1.0.0-1.dsc The packaging can be cloned using: debcheckout --user username git://git.debian.org/pkg-javascript/node-convert-source-map.git --git-track '*' Changes since the last upload: * Initial release (Closes: #780699) Regards, Ross Gammon -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ---End Message--- ---BeginMessage--- On 04/03/2015 04:47 PM, Ross Gammon wrote: Updated on alioth uploaded fresh to Mentors. Thanks for the fixes. I've uploaded the package. Because the package will have to pass through NEW, I'm closing the RFS manually. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1---End Message---
Bug#781701: [Pkg-javascript-devel] Bug#781701: RFS: node-convert-source-map/1.0.0-1 [ITP]
Thanks for the review :-) On 02/04/15 19:47, Sebastiaan Couwenberg wrote: Hi Ross, Thanks for your work on this package. On 04/01/2015 08:53 PM, Ross Gammon wrote: I am looking for a sponsor for my package node-convert-source-map There are some minor issues that needs to be addressed before the upload to the archive. debian/control: Testsuite: autopkgtest AFAIK this is not an official header yet, it should be XS-Testsuite. Fixed. I am still fine tuning my set up on the new Jessie laptop. cme fix dpkg-control got more things correct than I am used to on my desktop machine, but I clearly cannot completely trust it! debian/copyright: It contains an incorrect copyright year, npm2deb tends to get this wrong. The LICENSE file specifies 2013. Fixed. The upstream sources contain an example, you should consider including it in the package. Added a node-convert-source-map.examples file. Since inline-source-map is not packaged yet, you can't run the tests. If it get packaged in the future you should consider running the tests during the build process. Added a d/TODO file to remind me to check if the tests can be enabled next time. Kind Regards, Bas Updated on alioth uploaded fresh to Mentors. Regards, Ross -- 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/551ea801.4040...@mail.dk
Bug#781763: marked as done (RFS: node-coffeeify/1.0.0-1 [ITP])
Your message dated Fri, 03 Apr 2015 20:27:06 +0200 with message-id 551edb7a.3020...@xs4all.nl and subject line RFS: node-coffeeify/1.0.0-1 [ITP] [uploaded] has caused the Debian Bug report #781763, regarding RFS: node-coffeeify/1.0.0-1 [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 781763: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781763 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package node-coffeeify * Package name: node-coffeeify Version : 1.0.0-1 Upstream Author : Johan Nordberg h...@johan-nordberg.com * URL : https://github.com/jnordberg/coffeeify * License : Expat Section : web It builds this binary package: node-coffeeify - browserify plugin for coffee-script To access further information about this package, please visit the following URL: http://mentors.debian.net/package/node-coffeeify Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/node-coffeeify/node- coffeeify_1.0.0-1.dsc The Debian packaging can be cloned with: debcheckout --user username git://git.debian.org/pkg-javascript/node- coffeeify.git --git-track '*' Changes since the last upload: * Initial release (Closes: #780698) * Patch index.js to use through2 instead of through Regards, Ross Gammon -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ---End Message--- ---BeginMessage--- On 04/03/2015 07:31 PM, Ross Gammon wrote: I am assuming you will take the change from there, and I am therefore deleting the version on mentors. Yes, I'm building straight from git. The coffeeify source contains examples that are not installed in the package. I've added a change to also install the examples before uploading. Because the package will have to pass through NEW, I'm closing the RFS manually. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1---End Message---
Bug#781763: RFS: node-coffeeify/1.0.0-1 [ITP]
On 03/04/15 19:14, Sebastiaan Couwenberg wrote: On 04/03/2015 05:56 PM, Ross Gammon wrote: Thanks again for another review Bas. On 02/04/15 19:59, Sebastiaan Couwenberg wrote: You may want to consider extending Use_through2.patch to cover all files that use the through module, there are some tests that require it too. Since the test dependencies cannot be satisfied in Debian strictly required. I have fixed (I hope) all the other issues, but have one question before I finish. The package.json file also requires through. Should we leave this pristine so users know what upstream intended to be used (through), or also patch it to show what we used (through2)? I think the package.json installed by the Debian package should reflect the dependencies used by the package not npm. Kind Regards, Bas Okay - sounds logical. I updated the patch pushed the change to alioth. I am assuming you will take the change from there, and I am therefore deleting the version on mentors. Thanks for the clarification. Ross -- 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/551ece5f.40...@the-gammons.net
Bug#781763: RFS: node-coffeeify/1.0.0-1 [ITP]
On 04/03/2015 05:56 PM, Ross Gammon wrote: Thanks again for another review Bas. On 02/04/15 19:59, Sebastiaan Couwenberg wrote: You may want to consider extending Use_through2.patch to cover all files that use the through module, there are some tests that require it too. Since the test dependencies cannot be satisfied in Debian strictly required. I have fixed (I hope) all the other issues, but have one question before I finish. The package.json file also requires through. Should we leave this pristine so users know what upstream intended to be used (through), or also patch it to show what we used (through2)? I think the package.json installed by the Debian package should reflect the dependencies used by the package not npm. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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/551eca5e.9010...@xs4all.nl
Bug#781847: RFS: python-tappy/1.3-1 [ITP] -- Test Anything Protocol (TAP) tools for Python
Package: sponsorship-requests Severity: normal Dear Debian Mentors, I have packaged tap.py: * Package name: tap.py Version : 1.3-1 Upstream Author : Matt LAYMAN * URL : https://github.com/mblayman/tappy * License : BSD-2 Section : python tap.py is a python package that provides: - a test runner that produces a TAP compliant output; - facilities to load and parse the output produced by TAP compliant test runners. - Provides a lexer to colorize TAP output with Pygments. There are a few other python packages that do similar stuff, but none yet in Debian. Compared to other packages that I could find: - It is very easy to integrate in your tests, and plays well with the standard unittest framework; - It is actively maintained; - It is compatible with python from 2.6 to 3.4 (covers all python versions found in Debian); I have packaged it because I use it myself and having it packaged eases its deployment on the development and CI systems I maintain. I now hope that it will be useful to someone else... Packages are available for review on debian mentors and here: http://www.caniart.net/debian/NEW/ Relevant ITP bug report can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781832 Regards, Nicolas. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash 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/20150403185014.6747.9043.report...@amboss.schmiede.caniart.net
Re: Debian git workflow
On 03-04-15 17:55, Felix Natter wrote: does nobody have an opinion on this? In short: Is it better to have _a lot_ of beta gbp import-origs, commits that are reverted/superceded etc. OR develop on a private repository and copy the debian/* changes to alioth on a release? If this means that from one release to the next is only one commit, I personally don't like it. Usually history (with good commit messages) helps a lot with figuring out why what happened and where bugs were introduced. Not only for my own packages, but especially if I look at packages done by others, be it to fix some bug via NMU or because of take over. Basically, if you are only doing one commit, there is hardly any use for the repository, as I could get the same by downloading the packages from snapshot.d.o. Paul signature.asc Description: OpenPGP digital signature
RFS: python-tappy/1.3-1 [ITP] -- Test Anything Protocol (TAP) tools for Python
Package: sponsorship-requests Severity: normal Dear Debian Mentors, I have packaged tap.py: * Package name: tap.py Version : 1.3-1 Upstream Author : Matt LAYMAN * URL : https://github.com/mblayman/tappy * License : BSD-2 Section : python tap.py is a python package that provides: - a test runner that produces a TAP compliant output. - facilities to load and parse the output produced by TAP compliant test runners. - Provides a lexer to colorize TAP output with Pygments. There are a few other python packages that to similar stuff, but none yet in Debian. Compared to other package that I could find: - It is very easy to integrate in your tests, and plays well with the standard unittest framework; - It is actively maintained; - It is compatible with python from 2.6 to 3.4 (covers all python versions found in Debian); I have packaged it because I use it myself and having it packaged eases its deployment on the development and CI systems I maintain. I now hope that it will be useful to someone else... Packages are available for review on debian mentors and here: http://www.caniart.net/debian/NEW/ Regards, Nicolas. -- 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/CAOWzrLA+Roe5Dci=1me-mklisj5qm4dzbna7yoxzzjvd9tg...@mail.gmail.com
Re: Debian git workflow
hello Paul, Paul Gevers elb...@debian.org writes: On 03-04-15 17:55, Felix Natter wrote: does nobody have an opinion on this? In short: Is it better to have _a lot_ of beta gbp import-origs, commits that are reverted/superceded etc. OR develop on a private repository and copy the debian/* changes to alioth on a release? If this means that from one release to the next is only one commit, I personally don't like it. Usually history (with good commit messages) That's exaggerated: I usually manage to split this into ~10 commits, but they all share the same timestamp. See: http://anonscm.debian.org/cgit/pkg-java/knopflerfish-osgi.git helps a lot with figuring out why what happened and where bugs were introduced. Not only for my own packages, but especially if I look at packages done by others, be it to fix some bug via NMU or because of take over. Basically, if you are only doing one commit, there is hardly any use for the repository, as I could get the same by downloading the packages from snapshot.d.o. Ok. If there is no strong opinion about it, I will choose one method based on personal judgement. Thanks and Best Regareds, -- Felix Natter -- 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/87619dxefp@bitburger.home.felix
Re: Debian git workflow
Felix Natter fnat...@gmx.net writes: hello mentors, Dear mentors, does nobody have an opinion on this? In short: Is it better to have _a lot_ of beta gbp import-origs, commits that are reverted/superceded etc. OR develop on a private repository and copy the debian/* changes to alioth on a release? Thanks and Best Regards, Felix my workflow with more complex packages is that I start early and push the packaging (branching off the current alioth stable version) to github.com/fnatter/foo-debian-unstable, where I import almost every beta, fix the problems that occur and push the result to github. That way, my changes are securely stored and errors are easier to debug because I know which beta caused it (and it is less pressure on me when the actual release happens). However, this means that I copy all the changes to the stable alioth repo when the result happens, and while I try to put issues in separate commits, three issues remain: - all the pieces of work (update dep X, fix man page, bump Standards-Version, fix lintian Y, ...) have (almost) the same timestamp - different changes to one file share a commit (I know there is git functionality to split this, but this has so far been too error-prone for me). - collaboration is made more difficult As an example, see: http://anonscm.debian.org/cgit/pkg-java/knopflerfish-osgi.git The advantage of this approach is that the upstream/master branch does not contain all those unneeded (orig-)imports (which can be ~10 per release).. -- What do you think, which approach is better? Thanks and Best Regards, -- Felix Natter -- Felix Natter -- 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/87384h2omh@bitburger.home.felix
Bug#781763: [Pkg-javascript-devel] Bug#781763: RFS: node-coffeeify/1.0.0-1 [ITP]
Thanks again for another review Bas. On 02/04/15 19:59, Sebastiaan Couwenberg wrote: You may want to consider extending Use_through2.patch to cover all files that use the through module, there are some tests that require it too. Since the test dependencies cannot be satisfied in Debian strictly required. I have fixed (I hope) all the other issues, but have one question before I finish. The package.json file also requires through. Should we leave this pristine so users know what upstream intended to be used (through), or also patch it to show what we used (through2)? Cheers, Ross -- 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/551eb815.2010...@mail.dk
