Bug#684220: RFS: tinysvm/0.09-1 [ITP] -- SVM trainer and classifier toolkit
Il 04/11/2012 20:14, Jakub Wilk ha scritto: > * Giulio Paci , 2012-10-27, 18:28: I finally decided to repackage the tarball with files generated by more recent versions of swig. I used an interface file downloaded from https://github.com/shogo82148/TinySVM/. >>> The binding should be regenerated at build time. But... are they currently >>> used at all? If not, it might be simpler just to strip them out completely. >> I do not know any user of the bindings, but I would prefer to keep at least >> their sources in the package (I have to repackage the tarball anyway and the >> bindings sources >> do not introduce a large overhead), if it is not a problem to leave the >> source there and not compiling them. > > If the idea is to leave out all the generated files, but keep the SWIG > interface file, then yes, it should be fine. Fine, so I will re-package it leaving out the automatically generated files. The idea is to remove problematic files and add these files (6270 bytes) from https://github.com/shogo82148/TinySVM/: java/test.java java/Makefile.in python/setup.py python/README swig/TinySVM.i swig/Makefile Is this ok? >>> In any case, please provide a get-orig-source target. >> I have no experience with this target. > > Very well! That means you'll learn something new. ;) > >> I read the description on this page >> (http://www.debian.org/doc/debian-policy/ch-source.html), but I did not >> understood what I am supposed to do. >> As far as I understood, this target should provide a way to get the sources >> for the patched upstream tarball. >> Anyway the description reports that the target should: >> 1) download the original source file; >> 2) recreate the patched source; >> 3) tar the patched source. >> >> It is possible to implement these steps, but I need some software to do that >> (e.g., something to retrieve files from upstream and from >> https://github.com/shogo82148/TinySVM/ and the same version of swig that I >> used to recreate the bindings file). >> How should I handle these additional dependencies? > > There's no standardized way to declare which packages are needed for > get-orig-source. This is not a problem in practice, as this target is run > only by humans, who are > usually smart enough to figure out what's needed. :) As long as you use tools > that a typical developer is more or less familiar with, you should be fine. I can do everything using uscan, tar, sed and wget, so I think this is not a problem. During the process I need to create a temporary directory. Should I delete it at the end of get-orig-source? Should I delete it in clean? How should I call the final package? Bests, Giulio. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50972151.5090...@gmail.com
Bug#683184: RFS: suckless-tools/39-1 [ITA]
* Vasudev Kamath , 2012-10-30, 20:32: .hg_archival.txt is no longer in sprop tarball, so it should be removed from the repository, too. Done and changes back in the git. I don't see any relevant changes in the repository… -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121104193305.ga3...@jwilk.net
Bug#684220: RFS: tinysvm/0.09-1 [ITP] -- SVM trainer and classifier toolkit
* Giulio Paci , 2012-10-27, 18:28: I finally decided to repackage the tarball with files generated by more recent versions of swig. I used an interface file downloaded from https://github.com/shogo82148/TinySVM/. The binding should be regenerated at build time. But... are they currently used at all? If not, it might be simpler just to strip them out completely. I do not know any user of the bindings, but I would prefer to keep at least their sources in the package (I have to repackage the tarball anyway and the bindings sources do not introduce a large overhead), if it is not a problem to leave the source there and not compiling them. If the idea is to leave out all the generated files, but keep the SWIG interface file, then yes, it should be fine. In any case, please provide a get-orig-source target. I have no experience with this target. Very well! That means you'll learn something new. ;) I read the description on this page (http://www.debian.org/doc/debian-policy/ch-source.html), but I did not understood what I am supposed to do. As far as I understood, this target should provide a way to get the sources for the patched upstream tarball. Anyway the description reports that the target should: 1) download the original source file; 2) recreate the patched source; 3) tar the patched source. It is possible to implement these steps, but I need some software to do that (e.g., something to retrieve files from upstream and from https://github.com/shogo82148/TinySVM/ and the same version of swig that I used to recreate the bindings file). How should I handle these additional dependencies? There's no standardized way to declare which packages are needed for get-orig-source. This is not a problem in practice, as this target is run only by humans, who are usually smart enough to figure out what's needed. :) As long as you use tools that a typical developer is more or less familiar with, you should be fine. On the other hand I am storing the tarball in a git repository using pristine-tar, so it would be easier to get files from git and pristine-tar (I just need to publish the git repository somewhere). Can I rely on git and pristine-tar to implement this target (this will provide patched sources in a more reliable way)? That would be cheating, sorry. :P I guess that the three steps above are suggested because they suppose that newer versions of the upstream tarball will continue to pose the same problem. Are those three steps mandatory? Re get-orig-source, it is not not required by Policy. However, _I_ do require from packages I sponsor that I can recreate .orig.tar, either semi-automatically or at the very least using only documentation included in the source package. That is: - either .orig.tar can be downloaded with uscan; - or get-orig-source exist; - or README.source explaining how to recreate .orig.tar exist (see Policy §4.14, point 4). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121104191416.gb9...@jwilk.net
Bug#692260: marked as done (RFS: capi4hylafax/1:01.03.00.99.svn.300-18 [RC] -- Faxing over CAPI 2.0 device)
Your message dated Sun, 04 Nov 2012 12:06:12 -0400 with message-id <50969274.9060...@debian.org> and subject line Re: Bug#692260: RFS: capi4hylafax/1:01.03.00.99.svn.300-18 [RC] -- Faxing over CAPI 2.0 device has caused the Debian Bug report #692260, regarding RFS: capi4hylafax/1:01.03.00.99.svn.300-18 [RC] -- Faxing over CAPI 2.0 device 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.) -- 692260: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692260 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "capi4hylafax" * Package name: capi4hylafax Version : 1:01.03.00.99.svn.300-18 Upstream Author : AVM GmbH * URL : ftp://ftp.avm.de/tools/capi4hylafax.linux * License : GPL-2.0+ Section : comm It builds those binary packages: capi4hylafax - Faxing over CAPI 2.0 device The package appears to be lintian clean. The upload would fix these RC bugs: #682135 #691863 To access further information about this package, please visit the following URL: http://mentors.debian.net/package/capi4hylafax Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/capi4hylafax/capi4hylafax_01.03.00.99.svn.300-18.dsc Changes since the last upload: capi4hylafax (1:01.03.00.99.svn.300-18) unstable; urgency=low * Only suggest package isdnactivecards. Closes: #682135, #691863. -- Joachim Wiedorn Sat, 03 Nov 2012 22:03:33 +0100 Details see in the appended diff file. Regards, Joachim Wiedorn all-changes-18.diff.gz Description: GNU Zip compressed data --- End Message --- --- Begin Message --- Hi, Le 04/11/2012 06:33, Joachim Wiedorn a écrit : > I am looking for a sponsor for my package "capi4hylafax" Uploaded, thanks. Better document all changes next time (i.e. something like “Update README.Debian accordingly” too), and closing two bugs that are already merged is a bit overkill ;). Regards David signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#691893: RFS: roundup/1.4.20-2 [RC]
* Kai Storbeck , 2012-10-30, 23:18: http://mentors.debian.net/debian/pool/main/r/roundup/roundup_1.4.20-2.dsc I don't intend to sponsor this, but here's my review: + * Remove conffiles only on purge. I don't see this change in the debdiff... + * do not remove roundup user on purge, due to possible dataloss A pointer to the discussion why removing users on purge is a bad idea (e.g. to bug #621833) would be helpful. But as above, I don't see any changes to the maintainer scripts. + * cleanup postrm and postinstall to use #DEBHELPER# tags I don't see this change in the debdiff... -Build-Depends-Indep: python (>= 2.6.6-3~), debhelper (>= 7.4) +Build-Depends-Indep: debhelper (>= 7.4), + python (>= 2.6.6-3~), + python-setuptools, + python-sphinx (>= 1.0.7+dfsg) What is the build-dependency on python-setuptools for? This addition is not documented in the changelog. At least debhelper, python, and python-sphinx are needed in the clean target, to they should be in Build-Depends, not Build-Depends-Indep. Please try avoiding reordering fields in debian/control; it makes reviewing debdiff harder than necessary. -Description: an issue-tracking system +Description: Issue-tracking system in python There's no reason for "I" to be uppercase. The addition of "in python" is not documented in the changelog? Why is it important that it's in Python (not "python"), BTW? +Document: roundup +Title: Roundup documentation +Author: Roundup developers +Abstract: This manual describes Roundup, the issue tracker. +Section: Project Management + +Format: HTML +Index: /usr/share/doc/roundup/html/index.html +Files: /usr/share/doc/roundup/html/* This change is not is not documented in the changelog. + status) + status_of_proc $EXECUTABLE $BINFILE && exit 0 || exit $? + ;; Ditto. +/usr/share/javascript/jquery/jquery.js /usr/share/roundup/_static/jquery.js I'm confused. Shouldn't that be /usr/share/roundup/_static/doc/jquery.js (note missing /doc/ compontent)? But in this case, dh_sphinxdoc already takes care of symlinking the file... PACKAGE=roundup -UPSTREAM_VERSION=1.4.20 DEB_SRCDIR=$(CURDIR) ROOT=$(DEB_SRCDIR)/debian/$(PACKAGE) DEB_BUILDDIR=debian/$(PACKAGE) -DOC=$(DEB_SRCDIR)/debian/$(PACKAGE)/usr/share/doc/$(PACKAGE) This change is not is not documented in the changelog. +override_dh_auto_build: + python setup.py build If you called "dh_auto_build" here instead of "python setup.py build" it would be more obvious that the change is correct. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121104135018.ga7...@jwilk.net
Re: supertransball2 at mentors 2012-11-01 16:38
Hi Bart, Thank you for reviewing supertransball2. On 03.11.2012 20:52, Bart Martens wrote: > I read that the license is GPL 2, but I don't read "or (at your option) any > later version". Where did you read that ? The author of supertransball2 himself speaks simply of "GPL license" in the readme.txt file and at his homepage. http://www.braingames.getput.com/stransball2/ Thus the old debian copyright file also talks about "GNU GPL" and links to /usr/share/common-licenses/GPL where you can find the GPL-3 today. In addition he also put a new file called license.txt, the GPL-3, into the last source package at his homepage which was created in 2009. The source code is identical to the one shipped with Debian hence i concluded the original intention back in 2005 was to let the users decide if they prefer GPL-2 or any later version of the license. Thus i think GPL-2+ is the appropriate license. > Why experimental and not unstable ? I started a thread on debian-devel-games about the games i intend to adopt. http://lists.debian.org/debian-devel-games/2012/10/msg00063.html Then Paul Wise asked me to target them at experimental because of the freeze. http://lists.debian.org/debian-devel-games/2012/10/msg00066.html > I'm not sure about "merge the old patches into one". Are you sure that this > is > an improvement ? Bluntly spoken, yes, although it might be just a matter of taste. My reasoning is: There were 4 patches whereas patch 2-4 dealt with the same path issue and patch 1 modified the Makefile. So they could have been already combined. If upstream was still active today i would prefer multiple patches true to the motto "One issue, one patch". In reality there haven't been any signs of upstream development for seven years now, so it's reasonable to conclude the patches are not upstreamable. They simply represent the delta to the original sources. I'm also using git + git-buildpackage for the packaging and keeping all the changes in one patch by creating a patch-queue branch, commiting and using gbp-export is the most efficient way for me and saves time. > Why base the debian/watch file on stransball2-v15-windows.zip and not on > stransball2-v15-source.zip ? stransball2-v15-windows.zip is the last available archive at the homepage which also includes the sources. All other links including stransball2-v15-source.zip are broken. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#692263: RFS: compton/0.0.1+20121102.git239796ab-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "compton" Package name: compton Version : 0.0.1+20121102.git239796ab-1 Upstream Author : Christopher Jeffrey URL : https://github.com/chjj/compton License : X/MIT Section : x11 It builds those binary packages: compton- Compositor for X11, based on xcompmgr To access further information about this package, please visit the following URL: http://mentors.debian.net/package/compton Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/compton/compton_0.0.1+20121102.git239796ab-1.dsc Changes since the last upload: compton (0.0.1+20121102.git239796ab-1) unstable; urgency=low * Initial release (Closes: #679551) -- Scott Leggett Sat, 03 Nov 2012 02:20:30 +1100 -- Regards, Scott. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5096496e.30...@sl.id.au
Bug#691907: RFS: ovito/1.1.0-1
On Sun, Nov 04, 2012 at 11:38:57AM +0100, Jakub Wilk wrote: > * Bart Martens , 2012-11-04, 05:07: > >>That should have been s/Tags/Usertags/, I guess? It it's not for > >>wheezy, then distribution in the changelog should be set to > >>experimental rather than unstable. > >The freeze policy does not forbid that this package is uploaded to > >unstable even if it is not for wheezy. > > Well, of course it does not. But that doesn't make uploading to > unstable a good idea. > > "Please also note that since many updates (hopefully, the vast > majority) will still be going in through unstable, major changes in > unstable right now can disrupt efforts to get RC bugs fixed. We > don't ask you not to make changes in unstable, but we do ask that > you be aware of the effects your changes can have -- especially if > you maintain a library. Please continue to keep disruptive changes > out of unstable and continue making use of experimental where > appropriate. Note that you can stage NEW uploads in experimental to > avoid disruption in unstable." So why would uploading this package to unstable not be a good idea ? Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121104112014.ga6...@master.debian.org
Bug#691907: RFS: ovito/1.1.0-1
* Bart Martens , 2012-11-04, 05:07: That should have been s/Tags/Usertags/, I guess? It it's not for wheezy, then distribution in the changelog should be set to experimental rather than unstable. The freeze policy does not forbid that this package is uploaded to unstable even if it is not for wheezy. Well, of course it does not. But that doesn't make uploading to unstable a good idea. "Please also note that since many updates (hopefully, the vast majority) will still be going in through unstable, major changes in unstable right now can disrupt efforts to get RC bugs fixed. We don't ask you not to make changes in unstable, but we do ask that you be aware of the effects your changes can have -- especially if you maintain a library. Please continue to keep disruptive changes out of unstable and continue making use of experimental where appropriate. Note that you can stage NEW uploads in experimental to avoid disruption in unstable." Changes since the last upload: * New upstream release. AFAICS upstream does not offer source tarball for downloads. (Ugh!) How was the .orig.tar.xz created then? http://www.ovito.org/manual/installation.getting_the_source.html https://ovito.svn.sourceforge.net/svnroot/ovito/tags/release-1.1.0/ Yes, I've seen these, which I why concluded that upstream doesn't provide tarballs. Just to clarify, my question would be ideally answered in one of the following forms: - by updating debian/watch (in case I'm wrong and tarballs are downloadable from somewhere); - by providing README.source (see policy §4.14, point 4); - by adding get-orig-source target to debian/rules (see policy §4.9). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121104103857.ga4...@jwilk.net
Bug#692260: RFS: capi4hylafax/1:01.03.00.99.svn.300-18 [RC] -- Faxing over CAPI 2.0 device
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "capi4hylafax" * Package name: capi4hylafax Version : 1:01.03.00.99.svn.300-18 Upstream Author : AVM GmbH * URL : ftp://ftp.avm.de/tools/capi4hylafax.linux * License : GPL-2.0+ Section : comm It builds those binary packages: capi4hylafax - Faxing over CAPI 2.0 device The package appears to be lintian clean. The upload would fix these RC bugs: #682135 #691863 To access further information about this package, please visit the following URL: http://mentors.debian.net/package/capi4hylafax Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/capi4hylafax/capi4hylafax_01.03.00.99.svn.300-18.dsc Changes since the last upload: capi4hylafax (1:01.03.00.99.svn.300-18) unstable; urgency=low * Only suggest package isdnactivecards. Closes: #682135, #691863. -- Joachim Wiedorn Sat, 03 Nov 2012 22:03:33 +0100 Details see in the appended diff file. Regards, Joachim Wiedorn all-changes-18.diff.gz Description: GNU Zip compressed data
