Bug#994912: RFS: pyupgrade/2.24.0-1 [RFP] -- Tool to automatically upgrade Python 3 syntax for newer versions
On 9/23/21 3:43 AM, Joshua Peisach wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "pyupgrade": > > * Package name : pyupgrade > Version : 2.24.0-1 > Upstream Author : Anthony Sottile > * URL : https://github.com/asottile/pyupgrade > * License : MIT > * Vcs : https://salsa.debian.org/python-team/packages/pyupgrade > Section : devel > > It builds those binary packages: > > pyupgrade - Tool to automatically upgrade Python 3 syntax for newer versions > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/pyupgrade/ > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/p/pyupgrade/pyupgrade_2.24.0-1.dsc > > Changes for the initial release: > > pyupgrade (2.24.0-1) unstable; urgency=medium > . > * Initial packaging > * Fix lintian issues, cleanup and add a few extra essentials > . > * Initial release (Closes: #988658) > > Regards, > -- > Joshua Peisach Hi Joshua, Here's my review. 1/ override_dh_auto_clean Instead of overriding dh_auto_clean, it'd be nicer to add: extend-diff-ignore = "^[^/]*[.]egg-info/" to debian/source/options. In fact, you have it there already, so why attempting to clean the egg-info? 2/ debian/gbp.conf Please remove the file completely. It's annoying to maintain. One can simply use: ignore-branch = True in ~/.gbp.conf instead. 3/ debian/copyright This isn't mandatory, but I strongly advise to use the same license as upstream for your packaging. Is there a good reason why you wrote debian/* in GPL-2+ instead of Expat like upstream? 4/ debian/control Please run "wrap-and-sort -bastk" to clean-up indentation in d/control. The package has, in setup.cfg: install_requires = tokenize-rt>=3.2.0 however, you do not (build-)depends on it. Can you fix this? You probably will have to package it too (since I didn't find it in Debian). 5/ debian/changelog Please only write a single entry there: Initial release (Closes: #988658) and nothing more. Let me know when all of the above is fixed, and I'll review the package again for sponsoring. Thomas Goirand (zigo)
Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool
On 6/15/21 2:37 PM, Tobias Frost wrote: > On Tue, Jun 15, 2021 at 02:12:20PM +0800, clay stan wrote: >> Tobias Frost 于2021年6月9日周三 上午2:03写道： >>> >> Add arm64 now. > > (Well, arm64 is clearly wrong…) > > I'd suggest just to (try) build for "any" architecture. Even if the arch is > not > supported, worst case that build fails. (Which is not a problem at all, > especially > as this package is tiny and almost builds instantly.) > > With your hardcoded list you very likely miss some archs where cpufetch might > work too. > The kfreebsd ports as an example. > > Just don't have artifical limits, please. Yeah, I agree with Tobias. Anyways, the Debian buildd system is capable of coping gracefully with failures on some arch: cpufetch just wont be available where it fails to build. So just let the buildd system do its job... Cheers, Thomas Goirand (zigo)
Bug#951202: RFS review of cglm 0.7.1-1
Hi Leon,
Jordan did detect something was wrong with the doc. Indeed, there's some
issues. It's overall a good review, though missing some advice, which I
intend to give myself here.
1/ Sphinx documentation
Your package must be using:
--with sphinxdoc
and the -doc package must depends on ${sphinxdoc:Depends} so that
everything is handled automatically for you. I also wouldrecommend the
following sequence which I use myself (not mandatory, but nice...):
override_dh_sphinxdoc:
ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
python3 -m sphinx -b html doc/sources \
$(CURDIR)/debian/libcglm-doc/usr/share/doc/libcglm-doc/html
dh_sphinxdoc
endif
then you don't need these:
Package: libcglm-doc
Depends:
fonts-font-awesome,
fonts-lato,
libjs-jquery,
libjs-underscore,
neither you need a debian/libcglm-doc.links file, as dh_sphinxdoc will
do that for you.
2/ copyright
Jordan is right about debian/copyright needing a debian/* section.
Though the license that you're using is "Expat", which is one flavor of
the MIT license (there's multiple MIT licenses, unfortunately, and
Debian recognize this one as "Expat").
3/ Missing hardening options
You may want to add this to your debian/rules:
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
4/ Missing .symbol file
Please read on here:
https://wiki.debian.org/UsingSymbolsFiles
5/ Others
You don't need this file:
debian/libcglm0.dirs
since you're installing things in /usr/lib with debian/libcglm0.install,
then there's no need to re-declare /usr/lib a 2nd time.
Same thing for debian/libcglm-dev.dirs and debian/libcglm-doc.dirs.
6/ General advice
Leon, I strongly recommend that you run Lintian this way on your package
before asking for a review:
lintian -Ii -E --pedantic *.changes
you would have seen the issues, and win time for everyone.
Now, if you come back with a corrected package, maybe Jordan can review
it again. If he does, I agree to do an initial sponsoring of it (though
not the follow-up ones) if Jordan is volunteering for the subsequent
ones. Jordan, just let me know when the package is ok. No need to CC me
or the archive-...@nm.debian.org anymore.
Cheers,
Thomas Goirand (zigo)
On 4/27/20 12:24 PM, Jordan Justen wrote:
> Leon,
>
> I reviewed the 0.7.1-1 packaging you posted on mentors.debian.net. I
> didn't see any major issues, but maybe some suggestions.
>
> The license is MIT, and debian/copyright has it listed properly.
>
> I think packages often will call out the debian directory in
> debian/copyright, even if it matches the upstream license. I don't
> know that this is required, but here's an example:
>
>
https://salsa.debian.org/xorg-team/lib/libglvnd/-/blob/debian-unstable/debian/copyright#L50
>
> You can also move the license text to a separate section if multiple
> sections list the same license. (Like the MIT license in the example
> above.)
>
> I did see that `lintian --display-info` prints some issues relating to
> fonts in the doc package. From `build-rdeps python3-sphinx-rtd-theme`,
> I found the dbus-python package also uses the rtd theme. I notice they
> use dh_sphinxdoc, and I wonder if it could be useful for the cglm
> package. (And, perhaps fix the lintian note.)
>
> lintian --display-info also flags no-symbols-control-file
> usr/lib/x86_64-linux-gnu/libcglm.so.0.0.1. (See dpkg-gensymbols)
>
> lintian --pedantic --display-experimental flags
> debian-watch-does-not-check-gpg-signature, but I see upstream doesn't
> sign the releases. You could ask upstream to do this, and pointing
> them at https://wiki.debian.org/Creating%20signed%20GitHub%20releases
> might make it easier for them.
>
> I don't these the info or experimental lintian items would block the
> package from debian, since they aren't even at the warning level.
>
> One easy cleanup change for the package would be to run wrap-and-sort.
>
> Do you plan to try to maintain the package going forward? (Watch for
> new upstream releases, work on bugs, etc?)
>
> Do you have plans to manage the package files in git, perhaps on
> salsa.debian.net? I'm not sure if it is allowed to start using salsa
> for a project before it makes it into debian. The salsa FAQ is vague
> on this point:
>
> https://wiki.debian.org/Salsa/FAQ#What_can_be_hosted_on_salsa
>
> But I think it is often allowed. I know of at least 2 cases where a
> repo was created for a package before it got included into Debian. I
> expect some basic review of the package is probably good first, and
> perhaps this email can serve for that.
>
> If not salsa.debian.net, you could still host it in a github repo and
> include the links to it in the control file. (And, that could move to
> salsa later too.)
>
> -Jordan
>
> Some more info, mainly for Thomas to know what I checked.
>
> I looked o
Bug#951202: RFS: cglm/0.6.2-1 [ITP] -- Optimized OpenGL Mathematics library for C
On 2/12/20 2:21 PM, Leon Marz wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "cglm" > > * Package name: cglm >Version : 0.6.2-1 >Upstream Author : Recep Aslantas > * URL : https://cglm.readthedocs.io > * License : MIT > * Vcs : https://github.com/recp/cglm >Section : libs > > It builds those binary packages: > > libcglm-doc - Documentation for the cglm library > libcglm-dev - Development files for the cglm library > libcglm0 - Optimized OpenGL Mathematics library for C > > To access further information about this package, please visit the following URL: > > https://mentors.debian.net/package/cglm > > Alternatively, one can download the package with dget using this command: > > dget -x https://mentors.debian.net/debian/pool/main/c/cglm/cglm_0.6.2-1.dsc > > Changes since the last upload: > >* Initial release (Closes: #950988) > > Regards, > > -- > Leon Marz Hi Leon, My applicant (Jordan Justen, to become a DD) will review your package, and hopefully, we'll be able to sponsor the upload at the end of the process, either by an upload from Jordan when he gets his account, or from myself. To other DDs: please do not interfere with this unless you want to add comments to the review from Jordan, or my comments on his comments. Cheers, Thomas Goirand (zigo) signature.asc Description: OpenPGP digital signature
Re: Move packages from alioth to salsa
On 05/14/2018 07:36 PM, Alexander Wirt wrote: > Several of such scripts exist and they should get used, especially the import > feature. > > for example: https://salsa.debian.org/mehdi/salsa-scripts > https://salsa.debian.org/satta/salsa-migration-tools > https://wiki.debian.org/Salsa/AliothMigration#Using_a_single_Python_script > > Alex You can add to the list: https://salsa.debian.org/openstack-team/debian/stuff/tree/master/salsa-scripts Cheers, Thomas Goirand (zigo)
Bug#864428: RFS: bitfield/1.0.0-2 [ITP #864358]
On 07/25/2017 04:05 PM, Roland Fehrenbacher wrote:
> Hi Vitalie,
>
> I pick up the sponsoring process.
>
> V> Thank you very much for your help and comments.
>
>> libbitfield$SOVERSION (shared library)
>> libbitfield-dev (development files)
>
> V> Done. Package name changed from 'bitfield' to 'libbitfield' and
> SOVERSION is set
> V> to 1, so we get:
> V> libbitfield1
> V> libbitfield-dev
>
> This looks good now.
>
>> If you don't have soversioning in place, then it probably means that your
>> software is still too volatile for you to think about a stable ABI /
> API. If
>> that's the case, then it is not a good candidate for packaging in Debian
> just yet.
>
> V> Done. SO-versioning (and versioning policy in general) has been set. ABI
> /API
> V> has been stabilized. Version (1.0.0) has been released.
>
> That's also OK now.
>
> Some further problems with the packaging:
>
> - The link /usr/lib/x86_64-linux-gnu/libbitfield.so should go to
> the libbitfield-dev package.
> - A shared library should have a debian/.symbols file
> (see man dpkg-gensymbols).
> - The standards version should be updated to 4.0.0
> - The files README.{Debian,source} do not provide any real info. They should
> be dropped until they contain something useful.
> - Please also remove the unrelated comments at the end of debian/rules
> and the comments after the DH_VERBOSE line at the beginning.
> - The files debian/*.dirs are unnecessary . Please remove.
>
> Please fix your package and ping me when done, so I can recheck.
>
> Cheers,
>
> Roland
Some other comments.
* The debian/changelog should:
- Contain only the first line.
- Have 1.0.0-1 (and not -3) as Debian release, as no previous version
were uploaded to Debian.
* Is there a reason why you're using debhelper 9 and not 10?
* I would recommend the use of "wrap-and-sort -t -a" (from devscripts)
to make debian/control cleaner.
* Your long description is a bit too short. When searching on a search
engine, I can see there's lots of this type of library. Your long
description doesn't tell where your library differentiate. Also, your
long description for the -dev package is only 2 lines long, which even
triggers a lintian warning that you should have seen. I would recommend
copying the long desc of libbitfield1 on top of the 2 lines of
libbitfield-dev as well.
* There's some lintian errors about spelling in man pages. Please fix them.
* Have you considered using DEB_BUILD_MAINT_OPTIONS=hardening=+all in
your debian/rules ? That's usually a good idea, and lintian also
complains about this.
* The .symbols file contains the debian revision. Typically, this
shouldn't be in, as the symbols are exported from the upstream version,
and wont change on debian revisions.
One last thing: what is your intention about packaging this library? Are
you going to upload a program that will actually use that lib? What is
the point in having it in Debian, and how will it be useful for our users?
I hope this helps.
Cheers,
Thomas Goirand (zigo)
Bug#802536: RFS: python-ncclient/0.4.5-1
On 10/20/2015 10:24 PM, Sebastien Badia wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "python-ncclient" > > * Package name: python-ncclient > Version : 0.4.5-1 > Upstream Author : Leonidas Poulopoulos <leop...@noc.grnet.gr> > * URL : http://ncclient.org/ > * License : Apache-2 > Section : python > > It builds those binary packages: > > python-ncclient - Python library for NETCONF clients > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/python-ncclient > > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/p/python-ncclient/python-ncclient_0.4.5-1.dsc > > Note: This upload introduce the new upstream version 0.4.5 (pre python3.x). > > Thanks in advance, cheers, > > Seb Hi Seb, A quick review then. Both Ubuntu LTS and Debian Stable have version >= 3.3.1 of python-lxml, so you don't need to specify the version in debian/control. Same remark for paramiko. Your package doesn't run any of the upstream tests. Why? Both -lxml and -paramiko could be in build-depends-indep. In the doc's conf.py, there's "sphinx.ext.intersphinx". This is to be patched out, so that the package doesn't do network access during build. Cheers, Thomas Goirand (zigo)
Re: launchpad for debian and autobuilders
On 12/12/2014 06:20 PM, Mattia Rizzolo wrote: On Fri, Dec 12, 2014 at 09:52:37AM +0100, Leopold Palomo-Avellaneda wrote: A Divendres, 12 de desembre de 2014, Paul Wise va escriure: On Fri, Dec 12, 2014 at 4:26 PM, Leopold Palomo-Avellaneda wrote: The Debian autobuild service is here: https://buildd.debian.org/ Yes, but _only_ the debian developers could access there. If I want to test a package, you need an sponsor, and so on. I know the path. ftp masters are also working to have PPA in debian (for DD and DM, if IIUC), but this is a long dream. As much as I know, this process is stalled, because the involved persons are very busy with either paid work or other non-Debian things. So, has to volunteer to work on it if we want this to happen. Thomas -- 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/54956da5.2070...@debian.org
Re: script-with-language-extension
On 03/10/2014 04:49 AM, Salvo Tomaselli wrote: Not sure if fixing it by renaming the files is what you want to do. I have such a warning in xinetd and honestly I just ignore it because I don't think that renaming scripts after they have been there for many years is a good idea. Besides that's the upstream name so that's how they will be probably called in other distributions too I guess. The Debian policy manual don't agree with you, AFAIR. Thomas -- 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/531d6797.7000...@debian.org
Bug#726490: sponsorship-requests: ethstatus/0.4.4 [ITA]
You wrote: * Upstream is the same as Debian maintainer. Therefore, build a native Debian package IMO, that's a very bad idea. this is a pain for downstream Debian derivative who may want to add specific patches. With a native package, it becomes less convenient to add distro-specific patches. Please don't do this and re-upload a version of your package as non-native. Generally, native packages are very Debian specific, like for example apt, dpkg, etc. Unless you develop this kind of tool, IMO, don't use a native package. Thomas Goirand (zigo) P.S: Some other DD may have a different opinion, like for example I know Joey Hess finds it ok and even wrote about it, but I believe a majority of DD will agree with me. -- 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/53132a32.6070...@debian.org
Bug#735772: RFS: sockjs-client/0.3.4-1 [ITP #733821]
On 01/18/2014 03:02 AM, Tonnerre LOMBARD wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package sockjs-client * Package name: sockjs-client Version : 0.3.4-1 Upstream Author : VMware, Inc., Guillermo Rauch guille...@learnboost.com, Julian Aubourg j...@ubourg.net, Douglas Crockford doug...@crockford.com * URL : https://github.com/sockjs/sockjs-client * License : Expat Section : web It builds those binary packages: libjs-sockjs - WebSocket emulation - Javascript client To access further information about this package, please visit the following URL: http://mentors.debian.net/package/sockjs-client Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/sockjs-client/sockjs-client_0.3.4-1.dsc More information about sockjs-client can be obtained from https://github.com/sockjs/sockjs-client Changes since the last upload: * Initial release. Closes: #733821 Regards, Tonnerre Hi, The package seems to be in order, however, you are packaging LICENSE-MIT-SockJS, which you shouldn't. All of the copyright information should be contained in debian/copyright and no other file. If you fix that, I'll upload the package for you. Let me know. Cheers, Thomas Goirand (zigo) -- 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/52d9f327.9040...@debian.org
Re: DFSG package to remove images/documentation
On 01/13/2014 01:21 AM, Paul Tagliamonte wrote: The source seems like it'd be intact; you can just rm and rebuild at build-time or something - might make the `clean' step a little harder since you'll end up with changed binary files, but this isn't an uncommon problem. You don't even have to bother with the clean in this case... Just put this into debian/source/options: extend-diff-ignore = ^.*\.(gif|jpeg)$ and you're fine. Correct me if that's the wrong approach, but in my experience, that's ok. Thomas -- 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/52d6b1cf.70...@debian.org
Re: dch -i injects urgency=medium
On 01/05/2014 04:55 PM, Andreas Tille wrote: Hi, since some days I noticed that a `dch -i` creates an entry with urgency=medium instead of urgency=low. Anybody with the same observation and what might be the reason for this? Kind regards Andreas. That's because it is now the view of the release team that urgency=medium is ok for most uploads, and you should do that as well. I believe it has been announced through the dda list. Cheers, Thomas Goirand (zigo) -- 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/52c920ad.1050...@debian.org
Found a nice tool that needs a maintainer: jq
Hi, I have found a tool called jq, which is a very nice JSON parser for the shell. I know I could simply write an RFP, though these don't get much attention. So, if you feel like you have a bit of time to package it (correctly, not like I did), then you can take this as a starting point: Vcs-Browser: http://anonscm.debian.org/gitweb/?p=openstack/jq.git;a=summary Vcs-Git: git://anonscm.debian.org/openstack/jq.git Please don't comment on this package, it's unfinished, and it's having loads of problems (like, it's not lintian clean, embeds some license files, it doesn't include the doc, etc.). I don't have enough time to maintain this myself, and I maintain already too many things in Debian. So, if anyone without upload rights wants to work on it, I'll sponsor the upload as soon as the above problems are fixed (plus certainly more which I didn't spot yet). Cheers, Thomas Goirand (zigo) -- 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/51f29c41.9060...@debian.org
Re: Twing in Debian (was: Found a nice tool that needs a maintainer: jq)
On 07/27/2013 12:40 AM, Daniel Beyer wrote: Hi Thomas, I would have been interested in doing so, but it seems that jq already found its way into Debian: http://packages.qa.debian.org/j/jq.html But if you like to do some sponsoring, I'm still waiting for someone to sponsor twig (or even give me some feedback regarding the packaging): http://bugs.debian.org/714548 http://mentors.debian.net/package/twig Don't mind, I just thought I'll give that a try, since you maintain quite some php stuff... ;-) Greetings from Swiss Daniel Ok, here my remarks. 1/ Package descptions Your long descriptions are a bit weird. Could you please remove the indentation thing, and replace it with paragraphs instead? I don't really like seeing: For more details about the Twig template engine see the twig package description. please remove that and replace it by a (short) description of twig. Also, the short description of php5-twig-extension is: Twig php5 extension. This doesn't help. Please write things which aren't in the package name already. In fact, you've just copied what's on the home page of http://twig.sensiolabs.org/. That is sometimes a good approach, but not here, IMO. In debian/twig.README.Debian, I can see: Twig is a fast, secure and flexible template engine for php, implementing an own domain specific language which originated from Jinja and Django templates. It optionally can make use of a php5 extension, that enhances its performance. That's much better. Why don't you use that? 2/ debian/copyright There's all sorts of indentation there. Please clean that. 3/ tests The files in /usr/share/php/Twig/Test belong to the doc folder, and IMO, shouldn't be packaged together with the library. This can (potentially) be a security problem, if some of the test scripts are doing nasty things (I didn't check). Putting them in /usr/share/doc can be a solution. 4/ The PHP .so extension I don't really know much about packaging PHP .so libs, so probably someone else will have to look at that. For example, I'm not sure if extensions should be activated by default, unconditionally, on upgrades (what if the admin decided to deactivate it, but leave the package installed, and it gets upgraded?). Can anyone from the team have a look and let Daniel and I know? Is there a document where to read about this? 5/ Team maintenance May I suggest that you team-maintain this package, using Git and git-buildpackage? You may want to read this: http://pkg-php.alioth.debian.org/ It is generally a good idea to ask different teams for sponsoring, and often achieves much better results than just filling a RFS bug or writing to the mentor's list. Cheers, Thomas Goirand (zigo) -- 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/51f2bbd0.8020...@debian.org
Re: O:html2text
On 05/11/2013 05:00 AM, Nathan Owens wrote: I have created a package fixing the build error relating to hardening support http://mentors.debian.net/debian/pool/main/h/html2text/html2text_1.3.2a-16.1.dsc I am not sure if I really want to adopt this package, but this fixes some issues and cleaning of the package and of course the issue I mentioned above. I can't upload it, since I am not a DM but if anybody wants to check it out and upload it, then you are free to do so. This package was once labeled as RFH, so I intended to help, but it seems to be up for adoption at the moment Before doing the NMU, have you contacted Eugene, the current maintainer? Thomas -- 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/518f98e9.7030...@debian.org
Bug#703947: [pkg-php-pear] Bug#703947: RFS: php-archive-tar/1.3.11-1 [ITP] -- Tar file management class
On 03/26/2013 12:19 PM, Prach Pongpanich wrote: php-archive-tar (1.3.11-1) experimental; urgency=low * Initial release. (Closes: #703909) As much as I know, php-archive-tar is included in php-pear, so it's not needed to be packaged. Thomas -- 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/51514685.4090...@goirand.fr
Bug#703751: [pkg-php-pear] Bug#703751: RFS: php-html-template-it/1:1.3.0-1 -- PEAR HTML Isotemplate API
On 03/23/2013 03:28 PM, Prach Pongpanich wrote: dget -x http://mentors.debian.net/debian/pool/main/p/php-html-template-it/php-html-template-it_1.3.0-1.dsc Uplaoded. -- 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/5152853a.1020...@debian.org
Bug#703752: [pkg-php-pear] Bug#703752: RFS: php-net-sieve/1.3.2-2 [ITA] -- net_sieve module for PEAR
On 03/23/2013 03:41 PM, Prach Pongpanich wrote: dget -x http://mentors.debian.net/debian/pool/main/p/php-net-sieve/php-net-sieve_1.3.2-2.dsc Uploaded. -- 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/5152851e.4050...@debian.org
Bug#703473: [pkg-php-pear] Bug#703473: RFS: php-cache-lite/1.7.15-1 [ITA] -- Fast and lite data cache system
On 03/20/2013 12:51 PM, Prach Pongpanich wrote: dget -x http://mentors.debian.net/debian/pool/main/p/php-cache-lite/php-cache-lite_1.7.15-1.dsc Uploaded. Thanks for your contribution! Do you have many more to upload? I wouldn't mind reviewing them all at once (or at least a few of them at once) if you want. Thomas -- 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/5149ccf9.9020...@debian.org
Bug#703394: [pkg-php-pear] Bug#703394: RFS: php-services-weather/1.4.2-4 [ITA] -- acts as an interface to various online weather-services
On 03/19/2013 03:20 PM, Prach Pongpanich wrote: dget -x http://mentors.debian.net/debian/pool/main/p/php-services-weather/php-services-weather_1.4.2-4.dsc Uploaded. Though I have noticed one tiny remaining glitch from the past. debian/control Section: should be updated from web to php (which is the new section for such a package). Thanks for your contribution, salvaging old package like that that fell into the QA team is really appreciated. Cheers, Thomas -- 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/5148ab0d.8040...@debian.org
Bug#703144: [pkg-php-pear] Fwd: Bug#703144: RFS: php-net-dime/1.0.2-1 [ITA] -- PHP implementaion of DIME encoding and decoding
On 03/17/2013 02:36 AM, Prach Pongpanich wrote: Hi Thomas, On Sat, Mar 16, 2013 at 9:34 PM, Thomas Goirand tho...@goirand.fr wrote: Thanks for all these valuable changes. I agree with everything, though please upload your work to the team's git on Alioth instead of Github (you are now a member of the Alioth group, so you can upload your PEAR module package in /git/pkg-php), and change the VCS fields accordingly. Let me know when done, and I'll sponsor your package. I already done. - http://anonscm.debian.org/git/pkg-php/php-net-dime.git Uploaded! Thanks for your good quality contribution. This salvage was much needed. If you wish to do more work in the PKG PEAR group, I'll be happy to continue sponsoring your uploads. It is very nice to see you are using Git, and do exactly how the teams recommends doing packaging. Cheers, Thomas -- 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/5145e7fe.4020...@debian.org
Bug#703144: [pkg-php-pear] Fwd: Bug#703144: RFS: php-net-dime/1.0.2-1 [ITA] -- PHP implementaion of DIME encoding and decoding
On 03/16/2013 04:14 PM, Prach Pongpanich wrote:
Changes since the last upload:
php-net-dime (1.0.2-1) experimental; urgency=low
* New upstream release.
* Switching to 3.0 (quilt) source format.
* Update debian/watch, thanks to Bart Martens.
* Switching to pkg-php-tools and dh 8 sequencer
- Add pkg-php-tools to Build-Depends and drop {dh-make-php,cdbs}.
- Add php-pear in Build-Depends-Indep.
- Add ${misc:Depends} to Depends.
- Rewrite debian/rules.
* Add Vcs-* fields in debian/control.
* Update copyright file to version 1.0 format.
* Add debian/gbp.conf.
* Bump debhelper compat to level 9.
* Update Description field.
* Now using PKG-PHP-PEAR team as maintainer and
add myself as uploader (Closes: #529680).
* Bump Standards-Version: 3.9.4.
Hi,
Thanks for all these valuable changes. I agree with everything, though
please upload your work to the team's git on Alioth instead of Github
(you are now a member of the Alioth group, so you can upload your PEAR
module package in /git/pkg-php), and change the VCS fields accordingly.
Let me know when done, and I'll sponsor your package.
A tiny thing though (not a blocker). I saw you rewrote the short
description, adding PHP in front of it. I don't see the point. The
package is already called php-net-dime. The long description wouldn't
suffer from a rewrite either.
Thanks again for your contribution,
Thomas
--
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/51448312.1040...@goirand.fr
Bug#702849: RFS: php-soap/0.12.0-2.1 [NMU] [RC]
On 03/13/2013 04:12 AM, Adam D. Barratt wrote:
On Tue, 2013-03-12 at 23:28 +0800, Thomas Goirand wrote:
Prach Pongpanich in the mentors list is trying to fix #701134.
He is removing the Pre-Depends which was added for the
release of Squeeze, because of #605867, which I filled, but
can't remember what it was about. The bug report says:
As dicussed with the release team, we need to add a
Pre-Depends because of /usr/share/php/doc.
Does anyone remember off-hand what it was about?
The original issue was #602865, in php-net-smtp, fixed in 1.4.2-{2,3}.
Given that we don't officially support upgrades that skip a stable
release, the packages in wheezy technically don't need to include the
Pre-Depends.
Regards,
Adam
Hi,
That's what I thought as well, but I wanted to check. Thanks Adam for
taking the time to confirm it.
Prach, please change the new path to /usr/share/doc/php-soap, and
I will sponsor the upload.
Cheers,
Thomas
--
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/51401dbf.4050...@debian.org
Bug#702849: RFS: php-soap/0.12.0-2.1 [NMU] [RC]
On 03/13/2013 04:46 PM, Prach Pongpanich wrote: Hi , I'm sorry for noise, and thank you very much for reviews and discussions Prach, please change the new path to /usr/share/doc/php-soap, and I will sponsor the upload. I already done it and upload to mentors.d.n [1] [1] http://mentors.debian.net/debian/pool/main/p/php-soap/php-soap_0.12.0-2.1.dsc Regrads, Prach Uploaded. Do you know how to open an unblock request, so that the release team allows your fix to reach Wheezy? If you don't know, I can: - explain you how - do it for you Thanks for your contribution. Thomas -- 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/5140a26b.5000...@goirand.fr
Bug#702849: RFS: php-soap/0.12.0-2.1 [NMU] [RC]
On 03/12/2013 02:08 PM, Prach Pongpanich wrote: dget -x http://mentors.debian.net/debian/pool/main/p/php-soap/php-soap_0.12.0-2.1.dsc Hi Prach, Thanks a lot for taking care of it. I don't agree with removing the php-pear dependency. php-soap even ships a /usr/share/php/.registry More over, this is an RC fix for the frozen release, so you should only fix the bug, not change anything else, especially if it may create new bugs (which I believe would, in this case). Please remove the removal of the dependency, reupload to mentors, and I will happily sponsor your fixed package. Also, next time, please CC: the PKG-PHP team: Debian PHP PEAR Maintainers pkg-php-p...@lists.alioth.debian.org Debian PHP Maintainers pkg-php-ma...@lists.alioth.debian.org Thanks for your contribution to Debian, Cheers, Thomas Goirand (zigo) -- 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/513ee0e4.7080...@debian.org
Bug#702849: RFS: php-soap/0.12.0-2.1 [NMU] [RC]
On 03/12/2013 02:08 PM, Prach Pongpanich wrote: +- Drop Pre-Depends: php-pear as it's not needed I'm sorry, I missread. Indeed, the pre-depends: (and not depends:, as I wrote earlier) might not be needed. Could you explain a bit more why it appears in your changelog as if it was part of the fix? However, I think it would be nicer to put the docs of php-soap into /usr/share/doc/php-soap rather than in /usr/share/doc/php5-common. Your thoughts? Thomas -- 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/513ee293.5010...@debian.org
Bug#702849: RFS: php-soap/0.12.0-2.1 [NMU] [RC]
To the release team (and Prach): Dear release team, Prach Pongpanich in the mentors list is trying to fix #701134. He is removing the Pre-Depends which was added for the release of Squeeze, because of #605867, which I filled, but can't remember what it was about. The bug report says: As dicussed with the release team, we need to add a Pre-Depends because of /usr/share/php/doc. Does anyone remember off-hand what it was about? Thoughts on this? To Prach: = Please also read above. Appart from that, I insist, Debian's policy is to install documentation of packages under: /usr/share/doc/package-name So I would do that, and not move the doc into: /usr/share/doc/php5-common/PEAR which is not where our Debian users would naturally search. Arguably, php-pear goes together with the php5-common package, so it puts files there. I would however think it's a bug, rather than a feature, and that the docs from the php-pear package really should be under: /usr/share/doc/php-pear To Thierry: === Is it ok if someone NMU the fix? Also, for Jessie, it would be nice to switch php-soap so that it uses pkg-php-tools (so that you can use dh, instead of the old debhelper style). You can have a look at any package which build-depends on pkg-php-tools to find examples. Any plans for that? It's also disappointing to see that version 0.13.0 of php-soap, which was release upstream on the 2012-01-26, isn't in wheezy. This version was a QA release!!! Now, seeing this, I wonder: would you be ok to have this package team maintained in the future, and have it under the pkg-php-pear team, so that others are also allowed to upload it if needed? The team also needs some help to maintain all these PEAR modules, so you would be welcome to join. Cheers, Thomas -- 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/513f4984.8050...@debian.org
Re: Why is it so hard to get sponsors.....?
On 02/26/2013 10:36 PM, Paul Tagliamonte wrote: it is currently during freeze, most DDs are working on RC bugs :) If only this was truth! :) Thomas -- 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/512e669b.4010...@debian.org
Re: Bug#699669: RFS: agar/1.4.1+repack1-1 [ITP] -- toolkit for graphical applications
On 02/04/2013 10:50 PM, Mathieu Malaterre wrote: Package looks pretty good ! Some quick comments: What's with the renaming (Please add a REAMDE.source for explanation thanks) ? $ uscan --verbose --force-download [...] Newest version on remote site is 1.4.1, local version is 1.4.1+repack1 = remote site does not even have current version -- Scan finished Stephen, You need to add the following in your debian/watch file: opts=dversionmangle=s/\+repack\d// \ In other words, your watch file becomes: version=3 opts=dversionmangle=s/\+repack\d// \ http://stable.hypertriton.com/agar/agar-(.*)\.tar.gz If you don't do that, then uscan can't find the correct match between debian and upstream versions. Also, I don't think +repack is very nice. Probably you could use +dfsg instead, which is more the habit in Debian. Thomas -- 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/5115e93e.5080...@debian.org
Re: git-buildpackage: can it recreate the orig.tar.gz without the pristine-tar?
On 12/03/2012 10:30 PM, Antonio Ospite wrote: in debian/gbp.conf there are just these lines: [DEFAULT] debian-branch = debian upstream-branch = master upstream-tag = v%(version)s By just running git buildpackage the package builds fine, and the .orig.tar.gz generated gets generated. In _my_ case having the upstream-tag reflect the format of the tags marking stable release in the upstream-branch branch was the key to make git-buildpackage generate the .orig.tar.gz archives. Regards, Antonio Yeah, we use that with the Openstack packaging. Though it's nicer to use the xz format. Here's what we have in our unified debian/rules included Makefile: DEBVERS ?= $(shell dpkg-parsechangelog | sed -n -e 's/^Version: //p') VERSION ?= $(shell echo '$(DEBVERS)' | sed -e 's/^[[:digit:]]*://' -e 's/[-].*//') DEBFLAVOR ?= $(shell dpkg-parsechangelog | grep -E ^Distribution: | cut -d -f2) DEBPKGNAME ?= $(shell dpkg-parsechangelog | grep -E ^Source: | cut -d -f2) UPSTREAM_GIT?= git://github.com/openstack/$(DEBPKGNAME).git GIT_TAG ?= $(shell echo '$(VERSION)' | sed -e 's/~/_/') # Activate xz compression override_dh_builddeb: dh_builddeb -- -Zxz -z9 get-vcs-source: git remote add upstream $(UPSTREAM_GIT) || true git fetch upstream if [ ! -f ../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ] ; then \ git archive --prefix=$(DEBPKGNAME)-$(GIT_TAG)/ $(GIT_TAG) | xz ../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ; \ fi if ! git checkout master ; then \ echo No upstream branch: checking out ; \ git checkout -b master upstream/master ; \ fi git checkout debian/$(DEBFLAVOR) Whenever upstream releases (which only means, for us, that a new tag is available on github), I just do: git fetch upstream git merge -X theirs upstream-tag dch -i (and edit debian/changelog to match new upstream tag) ./debian/rules get-vcs-source And that's it! Quite strait forward and very convenient. This is also explained here: http://openstack.alioth.debian.org/ Another cool feature is that you can make snapshots of the upstream git repo if you need to do that. You only need to push your own tag to Alioth (and doesn't even need the master branch to be stored there). For example: git checkout master git pull git tag 2013.1_g0.2+36eccfb76a git checkout debian/experimental git push --tags And this explains why I define GIT_TAG with the sed call in debian/rules: git doesn't allow the ~ (eg: tilde), so we use _ (eg: underscore) instead. Then reproduce what's above to create your orig.tar.xz. I hope that helps. Cheers, Thomas -- 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/50bcc42c.8010...@debian.org
Re: jquery.js from Doxygen in documentation, what to do about it
On 11/24/2012 01:54 AM, Gert Wollny wrote: Now I've seen that Doxgen has the jquery-1.3.2.js file in the debian/ directory and in fact with this script the pages display correctly. My question is now, should I also include this source file in the source distribution, or would it suffice to document that the source code to the copressed files can be found with the according doxygen version? Many thanks, Gert In Debian, you should always be able to build from source. So if you could use the original source code, and delete the binary file (eg: the minimized jscript) that would be the best option. There's few compressor available in Debian, like yui-compressor, and the ones from nodejs (but these are only in SID). Cheers, Thomas P.S: The above isn't an approval for embedding yet another version of jquery in your package, I think it should be avoided as well if possible. Probably one of the options is to patch upstream source code so that it can work with the target Debian package and still render well. I have no idea how practical that would be though. -- 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/50afd45b.5030...@debian.org
Bug#684220: RFS: tinysvm/0.09-1 [ITP] -- SVM trainer and classifier toolkit
On 08/08/2012 06:26 AM, Giulio Paci wrote: It builds those binary packages: libtinysvm1 - TinySVM shared library libtinysvm1-dbg - TinySVM debug symbols libtinysvm1-dev - TinySVM development files [...] Hi, Could you *PLEASE* write a short description which gives information that are *not* on the name of the package? Eg: - don't only write these are shared libs - don't only write it's about tinysvm - don't only write -dev is a development lib - don't only write -dbg contains debug symbols Something like this would be much better: libtinysvm1 - implementation of Support Vector Machines (shared libs) libtinysvm1-dbg - implementation of Support Vector Machines (debug symbols) etc. Please note that I don't even know what tinysvm does, nor I am remotely interested in this package, I just wish Debian had more informative descs. Last, the project seems to have no activity since 2002. Are you sure you really want to package something that hasn't been maintained for 10 years? Cheers, Thomas -- 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/508773cf.4040...@debian.org
Bug#680546: RFS: cinnamon/1.6.1-1 [ITP] -- Innovative and comfortable desktop
On 09/28/2012 11:56 PM, Nicolas Bourdaud wrote: retitle 680546 RFS: cinnamon/1.6.1-1 [ITP] thanks Dear mentors, I am looking for a sponsor for my package cinnamon for experimental. This is the desktop environment developed by the Linux Mint team which is basically a fork of gnome-shell in order to have the feeling of GNOME2 while having the modern infrastructure of GNOME3. This package requires its window manager called muffin (that needs to be sponsored as well. see muffin ITP:http://bugs.debian.org/661270 muffin RFS:http://bugs.debian.org/680544) I previously made a sponsorship request concerning an earlier version of cinnamon but it was in the middle of summer so many sponsor were on vacation. I hope to be more successful now and that cinnamon will be uploaded to experimental soon. It has indeed showed quite a lot of interest from various people. * Package name: cinnamon Version : 1.6.1-1 Upstream Author : Linux Mintr...@linuxmint.com * URL :http://cinnamon.linuxmint.com * License : GPL-2+ Section : x11 It builds those binary packages: cinnamon - Innovative and comfortable desktop cinnamon-common - Innovative and comfortable desktop (Common data files) cinnamon-dbg - Innovative and comfortable desktop (Debugging symbols) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/cinnamon Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cinnamon/cinnamon_1.6.1-1.dsc Best regards, Nicolas Bourdaud Hi, Your packaging git is on Github, any reason why you don't use Alioth instead? I've tried it (currently running it on my Wheezy laptop), and I like it! :) Did you take the packaging work directly from Mint? What exactly did you change from them? Cheers, Thomas Goirand (zigo) -- 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/5067ef73.4000...@debian.org
Bug#680546: RFS: cinnamon/1.6.1-1 [ITP] -- Innovative and comfortable desktop
On 09/30/2012 10:29 PM, Nicolas Bourdaud wrote: Do you consider to sponsor it? :-) Well, before considering sponsoring that one, I would first do the sponsoring of muffin, since your package build-depends on it. But anyway, I know nothing about GUI packaging, so I don't think I would be the correct person to ask for such sponsoring. Did you ping the Gnome packaging team? What do they think about this package? Did you try to join their team, or talk to them? Thomas -- 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/50686c30.3010...@debian.org
Re: How to re-add removed packages
On 09/20/2012 04:28 PM, Tz-Huan Huang wrote: Hi Thomas, On Wed, Sep 19, 2012 at 5:57 PM, Thomas Goirandz...@debian.org wrote: Hi, scim-sunpinyin has been removed by its maintainer because it is buggy and crashes. Please don't reintroduce it, there's already ibus-sunpinyin that works perfectly. Thanks for the information. However, I am not sure for this. The sunpinyin project just update their scim support so that the crash is gone. If any further bug is reported, I believe that sunpinyin or scim guys are glad to fix it. I'll consider your suggestion. Thanks, Tz-Huan I happen to know both upstream author and Debian maintainer, I would suggest you to deal with them about it, rather than just discussing it in debian-mentors, and not decide to do anything without them. I Cc:-ed both of them. Thomas Goirand (zigo) -- 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/505adf89.9050...@debian.org
Re: How to re-add removed packages
On 09/19/2012 05:02 PM, Tz-Huan Huang wrote: Hi, I'd like to maintain some packages, which are removed in sid now. (scim-hangul, scim-sunpinyin, scim-pinyin, scim-array). How should I do? Should I send a WNPP bug report as a usual new package, or just package it, change the maintainer to me and upload it to mentors.debian.net to find a sponsor? Thanks! Tz-Huan Hi, scim-sunpinyin has been removed by its maintainer because it is buggy and crashes. Please don't reintroduce it, there's already ibus-sunpinyin that works perfectly. 谢谢, Thomas -- 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/505996f1.20...@debian.org
Re: Rebasing published software and avoid git revert/merge
On 09/05/2012 03:14 PM, Daniel Hartwig wrote: On 5 September 2012 14:55, Florian Schlichting fschl...@zedat.fu-berlin.de wrote: Have you considered keeping branch names as they are, and setting git-debian-branch (and git-upstream-branch) in debian/gbp.conf / .gbp.conf? Yes, but master will never be used again so I'd rather not leave it around. Also then the alternate branch becomes the main master, so is a bit confusing. I never understood why everyone insist in using the default name master. This doesn't express anything at all. Instead, you should be using: - wheezy - sid - experimental then use a debian/gbp.conf as suggested by Florian, and have no branch named master *at all*. Thomas -- 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/504703b5.2010...@debian.org
Re: [Aptitude-devel] Rebasing published software and avoid git revert/merge
On 09/05/2012 04:16 PM, Daniel Hartwig wrote: On 5 September 2012 15:48, Thomas Goirand z...@debian.org wrote: I never understood why everyone insist in using the default name master. This doesn't express anything at all. Instead, you should be using: - wheezy - sid - experimental Right. That has been a sort of long-term goal ;-) For historical reasons, aptitude is a non-native package. In this case, I would do: - debian-squeeze - debian-wheezy - debian-sid - debian-experimental - upstream-squeeze - upstream-wheezy - upstream-sid - upstream-experimental That's what I do with all of my packaging through Git, what is done in the pkg-php team, and in many other teams. If you need to switch the default branch, it's non trivial to do, but it's not hard (though I can't remember what Git commands was involved), so you can later kill the master branch forever. Thomas -- 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/504738b4.60...@debian.org
Re: Bug#685042: ITP: libpam-ssh -- Authenticate using SSH keys
On 08/16/2012 11:42 PM, Antti-Juhani Kaijanaho wrote: On Thu, Aug 16, 2012 at 05:39:50PM +0200, Jerome BENOIT wrote: According to its PTS ( http://packages.qa.debian.org/libp/libpam-ssh.html ): [2011-12-03] libpam-ssh REMOVED from testing (Britney) [2011-12-02] Removed 1.92-14 from unstable (Alexander Reichle-Schmehl) So I guess it must be considered as removed. Yes, you are right. Sorry for my careless reading of that page. In any case, no ambiguity, it seems. I don't think a package's presence in stable or oldstable alone is a problem. On my side, I got fooled by reading too fast: http://packages.debian.org/search?keywords=libpam-sshsearchon=namessuite=allsection=all The package is in SID, but only on few arch. Which makes me wonder: WHY ? How does such things happen? Is this because such ports aren't part of official Debian anymore? Thomas -- 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/502d1aa1.1010...@goirand.fr
Re: RFS: libapache2-mod-socket-policy-server 0.0.7-1 [NEW] -- An Apache2 module for serving Adobe socket policies.
Hi, I'm quite sure I did sponsor this package once. So I looked in it, in order to sponsor again. But it's not in SID. What happened to it? Why it's not in SID anymore? Thomas -- 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/5029eca0.7080...@debian.org
Re: RFS: libapache2-mod-socket-policy-server 0.0.7-1 [NEW] -- An Apache2 module for serving Adobe socket policies.
On Tue Aug 14 2012 02:22:11 PM CST, Patrick Matthäi pmatth...@debian.org wrote: Am 14.08.2012 08:13, schrieb Thomas Goirand: Hi, I'm quite sure I did sponsor this package once. So I looked in it, in order to sponsor again. But it's not in SID. What happened to it? Why it's not in SID anymore? Thomas Rejected? Why didn't you closed the bug then? :) This was a long time ago, before we switched to using bugs for mentoring. No, I don't have the .upload file anymore (I reinstalled my sponsoring VM after I did something wrong). Thomas -- 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/1344936908.2021.2.camel@Nokia-N900-42-11
Re: RFS: libapache2-mod-socket-policy-server 0.0.7-1 [NEW] -- An Apache2 module for serving Adobe socket policies.
On 08/14/2012 05:47 PM, Patrick Matthäi wrote: Ok, could you please go ahead, since you already worked on it? Thanks! Go ahead with what? Uploading? Not before I know what happened to the package I thought I sponsored in SID. Thomas -- 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/502a9026.4070...@debian.org
Bug#673438: RFS: libjs-swfupload/2.2.0.1-1 [ITP]
On 05/22/2012 06:35 PM, Christian Welzel wrote: Hi Thomas, Oh, and besides this, building your package twice fails. Precisely because the swfupload.swf file binary content changes, and dpkg-source can't do its job: Ok, thanks for that hint. I always build my packages with git-buildpackage and a separate build directory. So this is never a problem for me. I made a new package which removes the swfupload.swf and moves its build to a tmp-dir, now rebuilding works flawlessly. http://mentors.debian.net/debian/pool/main/libj/libjs-swfupload/libjs-swfupload_2.2.0.1+ds1-1.dsc Hi, It should be called +dfsg, as in Debian Free Software Guidelines. Calling it +ds doesn't express anything. Also, your debian/changelog shouldn't contain more than: libjs-swfupload (2.2.0.1-1) unstable; urgency=low * Initial release (Closes: #602253, #609110) -- Christian Welzel gaw...@camlann.de Tue, 14 Feb 2012 17:11:09 +0100 You are *not* documenting your work in this file, you are documenting changes in Debian. Since the software has never been in Debian, a single initial entry in your debian/changelog is enough. Cheers, Thomas Goirand (zigo) -- 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/4fbbcbde.2050...@debian.org
Bug#673438: RFS: libjs-swfupload/2.2.0.1-1 [ITP]
On 05/19/2012 02:00 AM, Christian Welzel wrote: dget -x http://mentors.debian.net/debian/pool/main/libj/libjs-swfupload/libjs-swfupload_2.2.0.1-1.dsc Hi, Your package contains a pre-built version of swfupload.swf. Please remove that file from your source package, it should be built from source only. Thomas -- 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/4fb7e2b8.3050...@debian.org
Re: Dependencies for FastCGI
On 04/17/2012 11:43 AM, Stefan Ott wrote: Hey mentors I have a question concerning one of my packages (fookebox). It currently depends on libapache2-mod-wsgi | httpd-wsgi since it's a web application that is typically called through WSGI. As requested in #667838, I now added the configuration files required to get it to run through FastCGI with python-flup. However, I am not entirely sure how to change my dependencies to indicate that this is a possibility. Please don't be so prompt into deciding how a python code will be executed by the web server. I use, and maintain SBOX, which is a cgi wrapper, and which can run python scripts. This doesn't need at all FCGI. I'd be very surprised if WSGI was needed in this case. As I see it, one option would be to say that the package depends on either (libapache2-mod-wsgi | httpd-wsgi) or (libapache2-mod-fastcgi and python-flup). Another option is to not depend on anything, let the admin decide, and just make suggestions in the README.Debian. Another way would be to just use Suggest: or Recommends: (which isn't forcing anyone into doing what it doesn't want). Cheers, Thomas -- 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/4f8ee6c9.8080...@debian.org
Re: Debian-friendly upstream best practices?
On 03/28/2012 05:25 PM, Daniel Pocock wrote: - is it reasonable for the upstream repo to have a Debian branch, inverting the normal use-case of git-buildpackage? e.g gbp.conf: [DEFAULT] upstream-branch=master (not upstream) debian-branch=debian (not master) or possibly: [DEFAULT] upstream-branch=master debian-branch=packaging/debian If you are willing to maintain the packages, then probably, you will want to have also branches for testing and stable. Which is why I use: - debian-sid - upstream-sid - debian-wheezy - upstream-wheezy - debian-squeeze - etc. (for backports and friends too...) Also, I don't think that master is an indication of any sort. I often try to avoid it if possible. Just my 2 cents of advice... Thomas -- 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/4f749da8.3000...@debian.org
Re: Debian-friendly upstream best practices?
When I'm at it, you might want to have a look here: http://wiki.debian.org/GitPackagingWorkflow Cheers, Thomas On 03/28/2012 05:25 PM, Daniel Pocock wrote: I am involved in several projects where I am either the founder of the project (e.g. dynalogin) or a contributor with full access to the repository (e.g. Ganglia, reSIProcate, flactag) There are also a couple of projects where I don't have any role, but I would like to package the code for Debian. I'm just trying to establish the pattern I should be following a) for those projects where I have no role, no commit rights, etc, I presume that I should just use git-buildpackage, create a distinct repository to track debian/ stuff, and follow the normal structure (master and upstream branches) b) however, for the other projects where I can potentially include debian/ stuff in the upstream repo: - Is there any compelling reason to create a separate repo for debianisation? Or it is perfectly fine (in a technical sense) to have the debian branch in the upstream repo if nobody else there has objections? - is it reasonable for the upstream repo to have a Debian branch, inverting the normal use-case of git-buildpackage? e.g gbp.conf: [DEFAULT] upstream-branch=master (not upstream) debian-branch=debian (not master) or possibly: [DEFAULT] upstream-branch=master debian-branch=packaging/debian - in the `normal' git-buildpackage use case, I notice `upstream' branch has one commit for each real release, yet if git-buildpackage is used with a real upstream repo, the `upstream' branch may actually have many small commits that are not releases. Does this cause any problems? - when such a combined repo is used (upstream and debian branches all in the same repo), can tagging be handled automatically? I was thinking that tags should be in some format such as 3.3.5 packaging/debian/3.3.5-1 (or 3.3.5/1 perhaps?) packaging/debian/3.3.5-2 - In that example, the 3.3.5 tag is created by the upstream release process, not by running git-import-orig - will there be any problem if git-import-orig is never run? From reading the man pages, my impression is that I can use a config such as I describe above, and use commands like these: git-buildpackage \ --git-tag --git-debian-tag=packaging/debian/%(version)s \ --git-upstream-branch=master \ --git-upstream-tree=TAG \ --git-debian-branch=packaging/debian git-buildpackage \ --git-tag --git-debian-tag=packaging/debian/%(version)s \ --git-upstream-branch=master \ --git-pristine-tar --git-tarball-dir=/home/daniel/upstream-tarballs/ \ --git-debian-branch=packaging/debian Can anyone make any comments on these questions, how I should proceed, best examples to follow, howtos I should read, etc? -- 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/4f749e8b.4090...@debian.org
Re: [RFR] - Multiple (4) PEAR packages needed by PHPUnit - Was: [RFR] - PHP_Timer (Needed by phpunit)
On 03/27/2012 12:59 AM, Luis Uribe wrote:
Hi Thomas,
It's me again! Trying to upgrade PHPUnit into Debian.
Hi,
Thanks a lot for this effort, I really need it myself for testing my own
(numerous) PEAR packages, and I'm really willing to help here. Are you
ok if we work *together*, meaning, I'd be co-maintaining?
Do you mind if we use Git and Alioth to do these packaging? If you are
ok to do like this, then please checkout the Git repository under
/git/pkg-php/pear-phpunit-channel.git on Alioth. I have added,
accordingly, the Vcs fields:
Vcs-Browser: http://git.debian.org/?p=pkg-php/pear-phpunit-channel.git
Vcs-Git: http://git.debian.org/git/pkg-php/pear-phpunit-channel.git
If it isn't done already, please register to the PKG-PHP Alioth group,
and if you're not a PEAR packager yet, I can give you these rights (I'm
admin of the PKG-PHP group on Alioth). Let me know when done.
After our last [0]email i just [1]ask Mathieu for the best way to install
PEAR packages from a different PEAR channel with pkg-php-tools and i
decided that the best way is to to create a new package:
pear-phpunit-channel, because there are many PEAR packages in that
channel.
I think that this is a good idea and a good approach to the problem.
So i fill an [2]ITP and [3]upload a new native package for
pear-phpunit-channel.
Let me start a quick review of this one, then we'll be able to talk
about the others once this first one will be sponsored.
1/ dh_phppear substitution variables in debian/control
First of all, you are using the things for dh_phppear, with your control
file having:
Depends: ${misc:Depends}, php-pear, ${phppear:Debian-Depends}
Recommends: ${phppear:Debian-Recommends}
Breaks: ${phppear:Debian-Breaks}
But this is *not* a PEAR package that you are packaging here. It's a
single file (eg: the pear.phpunit.de.reg and nothing else, if I
understood correctly your package). So there's no reason at all to use
pkg-php-tools, which by the way, you do not even depend on, even with
the variable substitution above.
2/ The use of dh 8 sequencer
While it's ok to use the dh 8 sequencer, in fact, your package only
needs to install a single unique file. Frankly, that's a bit overkill to
have all these calls for nothing.
3/ Build-Depends: and Depends: on php-pear
I don't think these are even needed. What we are packaging here is a
single file, which doesn't need pear to get installed or run. So why
would we [Build-]Depends on php-pear? To me, it's not needed.
4/ Native package
You decided to use a native package. But how did you get the
pear.phpunit.de.reg file? Isn't it coming from upstream?
I have made corrections for all the above. If you agree with this, then
I'll upload. Let me know if there are some points you do not agree with
(I don't pretend to be the best at everything, and you might have
reasons for things you did...).
Also i create new packages for [4]php-file-iterator,
[5]php-timer, [6]php-text-template and [7]php-token-stream. All of them
depends of pear-phpunit-channel and install their .reg file so PEAR
didn't install a new version of the same package.
Could you (or someone else) take a look at it?
If you don't mind, I'd like to make sure that the pear-phpunit-channel
package is in good shape and uploaded before moving to the others.
Experience showed me that this is the best way to save time.
Thanks for your interest in doing these (very useful) packages,
Thomas Goirand (zigo)
--
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/4f70adb8.9020...@debian.org
Re: A Review Mentor team
On 03/13/2012 06:18 PM, Gergely Nagy wrote: I would also love to see a Review Mentor team, something that could work along and with the NM process, whose task would be to do just what the name suggests: reivew packages, help find a sponsor Oh, *that* is very interesting. And that gives me another idea. You know, I've been reading -mentors for quite some time, because when I was needing sponsorship, I was frustrated as well. Now that I've done few sponsoring, I don't read -mentors too much because there's too much traffic. But for sure, I'd be happy to do few sponsoring for the type of package on my *area of interest* (eg: hosting and servers). But since there's too much traffic and I have a limited time, I don't read much -mentors, and I must have skipped few interesting packages. Now, what I'd be very glad to have would be that Debexpo knows about tags, and that someone needing sponsoring would tag his package once it's uploaded to Debexpo. A sponsor would, on his side, select what type of tags he is interested in. For me for example, I'd be selecting server type of software, so I'd for example select system::server. Then I would receive on my mail all request for sponsoring server related RFS only, saving me the loss of time browsing -mentors which is flooded with X-Window / GUI software that I care less about. Having all this would mean that the following change occurs: 1/ Debexpo would allow sponsoree to edit tags on their software 2/ Debexpo would allow sponsors to register for tags they are interested in, and send RFS depending on matches with 1/ The added benefits would be that: - new software would immediately tagged, and tagging could be reviewed and discussed with sponsors - sponsors wont get flooded with packages they don't care about - sponsors will not miss software they do care about Of course, this is only an idea that I'm throwing, and I'm not raising hand for the implementation, but at the same time, the ones who have worked on tags and debexpo could be in a better position to do it. Thoughts anyone? Thomas Goirand (zigo) P.S: I quite understand that this is off-topic for -vote, but since this is where it started, I'm sending it as a reply to Gergely post anyway. If you follow-up, *PLEASE REMOVE* debian-v...@lists.debian.org (I've set the Reply-To: header, but who knows what broken mailer/habit people have...). Also, I'm adding -mentors to the list, and Enrico (sorry, I can't remember what is the list name on alioth for the tag stuff, feel free to forward this message there...). -- 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/4f622bfb.1020...@debian.org
Re: debian/rules default
On 02/27/2012 05:09 PM, Gergely Nagy wrote: Jerome BENOIT g62993...@rezozer.net writes: Hello List: What should be the default target for debian/rules ? I usually make a help target (or something similar) and make that the default. But now that you reminded me, I always wanted to make it display debian/README.source, so I'll just do that for my packages. Thanks for the reminder! :) That's really a cool idea. I wonder if we could have this as at least a recommendation in our docs. Thomas -- 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/4f4b4c50.8070...@debian.org
Re: RFS: policyd-weight (10th try)
On 02/17/2012 03:13 AM, Werner Detter wrote: Did you ask zigo who sponsored your last upload? sure i did. But he just became a father so he had no time left for uploading the package. Also, I'm busy with other packages, and did that last upload because I thought it was important that someone takes over the package that was orphaned. I never claimed that I'd be the sponsor for the life of the package (which I have no time for ATM, unfortunately). It would really help if someone else could also be the sponsor of this package, and maybe I will be able to help for the next upload, when I get less busy. Thomas -- 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/4f3e35f4.5090...@debian.org
Re: [RFR] - PHP_Timer (Needed by phpunit)
On 01/14/2012 07:29 AM, Luis Uribe wrote: Hi Thomas It's been a few months since i wrote you asking for help with php-timer, well finally i have time to send you a new package with all of your points fixed. I will be happy if you (or someone else) could take a look at it. Thanks. http://mentors.debian.net/debian/pool/main/p/php-timer/php-timer_1.0.2-1.dsc Hi, Let me review it. 1/ debian/README.source This file talks about dpatch, however, you are using quilt. Please fix it, or simply remove the file. 6/ Once installed, your package creates: /usr/share/php/PHP/Timer.php /usr/share/php/PHP/Timer/Autoload.php IMHO, it should rather install: /usr/share/php/Timer/Timer.php /usr/share/php/Timer/Timer/Autoload.php Done, i change the dir's name in override_dh_install because i don't know (and i don't think it's possible) how to represent a new dir in a patch. Let me know if that approach is wrong. I also add override_dh_auto_install because dh_auto_install -O--buildsystem=phppear didn't work when i build it on pbuilder. It seems to happen because php-timer is a PEAR package from another channel, also i'd like to know what do you think about it. I think you should talk about it with Mathieu Parent, who wrote pkg-php-tools. I've put him as Cc: to this mail. 7/ Do you know why your package doesn't build in Squeeze? :) Ehhm ... it is necessary? I always build it on sid. It's not mandatory, but it's better if it does, so that you can eventually write a backport. Never mind, forget it. Cheers, Thomas -- 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/4f112f92.9060...@debian.org
Re: RFS: policyd-weight (3rd)
On 01/06/2012 09:32 PM, wer...@aloah-from-hell.de wrote: Hi Thomas, I've received an email from Debian FTP-Masters with the information that the package got rejected: --- Reject Reasons: policyd-weight_0.1.15.2-1_all.deb: deb contents timestamp check failed [type 'exceptions.NameError': global name 'MTime' is not defined] --- What's wrong? Just my server clock having an issue (it *was* in advance of few hours). As you saw, I re-uploaded and it's ok now. Thomas -- 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/4f0a0677.9040...@debian.org
Re: RFS: policyd-weight (3rd)
On 01/08/2012 10:27 PM, wer...@aloah-from-hell.de wrote: Hi, can anyone re-upload the package ? :) regards, Werner Detter http://qa.debian.org/developer.php?login=wer...@aloah-from-hell.de It's in, as you can see! I don't think re-uploading only for the /etc/default/policyd-weight is worth the trouble. Just keep this in mind (and in your Vcs / workstation) for the next time! Thomas -- 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/4f0a0787.3010...@debian.org
Re: RFS: boot-repair (v3.03)
On 01/08/2012 09:40 AM, yannubu...@gmail.com wrote: Thanks Jakub for your review. I think a single source package with multiple binary packages would make more sense. i agree, but until now i didn't find how to do it Sorry, but that's not an excuse. If you didn't find out, search more, or ask either in this list or on IRC. There's also thousands of example packages in the Debian archive that you can look into. I updated the packages (same download links). Thanks again, i'm learning a lot. I don't want to be rude (no aggressiveness intended), but yourself, you know there's issues remaining (like the one above, and the python one). So why do you bother re-uploading? Please fix all issues first, and if you need help, I'm sure others will give a hand. THEN, when all is fixed, you can upload again and send another RFS. Cheers, Thomas -- 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/4f09071c.9010...@goirand.fr
Re: RFS: policyd-weight (3rd)
On 01/06/2012 01:14 PM, Thomas Goirand wrote: Your debian/init.d script shouldn't set the PATH at all. All the folders it is putting in PATH are already accessible in the default $PATH, so don't change it. FYI, pabs don't agree with me, and think declaring the $PATH is the way to go. So please ignore this. Thomas -- 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/4f06ae90.9060...@debian.org
Re: RFS: policyd-weight (3rd)
On 01/06/2012 07:44 PM, wer...@aloah-from-hell.de wrote: Hi Thomas, thanks for your helpfull comments. What was in /etc/default/policyd-weight? Why aren't you using it anymore? It behaves like the current package in unstable/testing/stable. The file /etc/default/policyd-weight isn't created but the init script takes account of it. /etc/default/policyd-weight is the place to add daemon-options for policyd-weight. What should we do here? Generate the file? Or don't take account of it in the init script? I'd add a file there, with lots of comments, and all the options that you can put in it. It doesn't mater if absolutely every options are commented out, the point is to document what can be done with useful comments. Maybe you can do that on your next upload? The creation of this directory is done by policyd-weight, so no need to create it via the init-script. Policyd-weight uses this directory for saving the PID and furthermore creates some more directories in /var/run/policyd-weight (for caching etc.). It behaves like the current policyd-weight in unstable/testing/stable. Cool ! Since all the points I've asked you about have been addressed, I have uploaded the package. Thanks for your contribution to Debian, and thanks for being patient enough with all my (sometimes silly) questions, and your package polishing. Taking over maintenance of orphan packages is one of the best way to contribute to Debian! Cheers, Thomas Goirand (zigo) -- 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/4f06ef6e.4070...@debian.org
Re: RFS: roxterm 2.4.2-1 (was 2.4.1-1)
On 01/05/2012 01:33 AM, Tony Houghton wrote: Unfortunately I just discovered a bug in the Build-Depends stanza, so please ignore version 2.4.1-1 and upload 2.4.2-1 instead. If that's an issue in the packaging, why did you need to upgrade from 2.4.1 to 2.4.2, and why didn't you just do a 2.4.1-2 instead? It's possible to get this sponsored, even if it wasn't in Debian before, your sponsor would just have to use the -sa flag when building to include the orig.tar.gz in the upload. Cheers, Thomas Goirand (zigo) -- 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/4f055c4f.10...@debian.org
Re: RFS: policyd-weight
On 12/30/2011 05:54 AM, wer...@aloah-from-hell.de wrote: With: # include /usr/share/quilt/quilt.make # clean: unpatch clean: dh_testdir dh_testroot dh_clean build-stamp I get: dpkg-buildpackage: source package policyd-weight dpkg-buildpackage: source version 0.1.15.2-1 dpkg-buildpackage: source changed by Werner Detter wer...@aloah-from-hell.de dpkg-buildpackage: host architecture amd64 dpkg-source --before-build policyd-weight-0.1.15.2 debian/rules clean make: *** No rule to make target `dh_testdir', needed by `clean'. Stop. Regards, Werner Hi ! If you put dh_testdir on the same line as the clean:, then it will *not* be considered as a command, but as a dependency of the clean target. In other words, you should write: clean: dh_testdir and not: clean: dh_testdir I hope that helps, Thomas -- 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/4f0576cb.1060...@debian.org
Re: RFS: policyd-weight
On 12/30/2011 06:30 AM, wer...@aloah-from-hell.de wrote: seems like this entry in debian/rules fixed it :) clean: rm -fr debian/files dh_clean *NO* !!! :) You really need the dh_testdir and dh_testroot calls. Thomas -- 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/4f057727.2010...@debian.org
Re: Advice on packaging a PHP application (ITP for Shaarli)
On 01/06/2012 07:13 AM, Emilien Klein wrote: By default, those directories are created in the same folder as where the application files are (that would mean under /usr/share/shaarli). Would /var/lib/shaarli be a better place to locate these folders? Remember that /usr can be a read-only filesystem if one wants to, and your PHP thing should continue to work. On 01/06/2012 07:13 AM, Emilien Klein wrote: - By creating the Apache configuration file, I force the user to use the /links url. Is there a better way, for instance on defaulting with /links, but giving the option to change that using `dpkg-reconfigure` (which BTW isn't available on my sid install???) Or is there a way to mark this file as a config file, so that the user would be able to edit it and it wouldn't later be overwritten during an upgrade? The /links thing is too generic, and it might clash with other things. I wouldn't use it if I was you. In fact, I see no reason why you would force it at all. Just don't setup anything if possible, and do a README.debian. Just your Directory portion is enough. On 01/06/2012 07:13 AM, Emilien Klein wrote: - Should I handle more than just Apache2 (other webservers)? Nobody can force you to support anything, but *please*, do not force anyone into using Apache by adding dependencies to it. In my environment for example, I can install PHP packages, but no web server (I install things in a chroot...). We have a Recommends: field for things like that... On 01/06/2012 07:13 AM, Emilien Klein wrote: - What about using the debian/postinst (and probably a corresponding debian/postrm)? The Debian New Maintainers' Guide specifically warns new users against using them [0]. It's perfectly fine to use maintainer scripts for reconfiguring your web server, but often, I've seen PHP application maintainers abusing it, and making dangerous assumptions about my hosting environment. Cheers, Thomas -- 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/4f067c30.60...@debian.org
Re: RFS: policyd-weight (3rd)
On 01/06/2012 02:07 AM, wer...@aloah-from-hell.de wrote: Dear mentors, I am looking for a sponsor for my package policyd-weight. * Package name: policyd-weight Version : 0.1.15.2-1 Upstream Author : Robert Felber * URL : www.policyd-weight.org * License : GPL-2+ Section : mail It builds those binary packages: policyd-weight - Perl policy daemon for the Postfix MTA To access further information about this package, please visit the following URL: http://mentors.debian.net/package/policyd-weight Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/policyd-weight/policyd-weight_0.1.15.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Werner Detter Your debian/init.d script shouldn't set the PATH at all. All the folders it is putting in PATH are already accessible in the default $PATH, so don't change it. What was in /etc/default/policyd-weight? Why aren't you using it anymore? Your package seems using /var/run/policyd-weight/, but where exactly is that folder created? Shouldn't an mkdir -p be added to your init.d script? What is the use of /var/run/policyd-weight by the way? Apart from that, I think the package is nicely improved, and would deserve to be uploaded. Thomas -- 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/4f068340.5040...@debian.org
Re: RFS: boot-repair
On 01/02/2012 10:05 AM, yannubu...@gmail.com wrote: Happy new year ! I disabled the update from PPA, removed the setup.py, created the packages.install files, moved data to debian/tmp and changed the rule to %:dh_install --sourcedir=debian/tmp See http://anonscm.debian.org/gitweb/?p=collab-maint/boot-repair.git But now I get this error when i try to package: dpkg-genchanges: error: cannot read files list file: No such file or directory dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2 debuild: fatal error at line 1348: dpkg-buildpackage -rfakeroot -D -us -uc failed any idea? Regards zigo@GPLHost:buzig_ /tmp/boot-repair$ git clone http://anonscm.debian.org/gitweb/?p=collab-maint/boot-repair.git; Cloning into boot-repair... fatal: http://anonscm.debian.org/gitweb/?p=collab-maint/boot-repair.git/info/refs not found: did you run git update-server-info on the server? Please fix it. Thomas -- 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/4f01d061.7030...@goirand.fr
Re: RFS: boot-repair
On 01/02/2012 10:05 AM, yannubu...@gmail.com wrote: Happy new year ! I disabled the update from PPA, removed the setup.py, created the packages.install files, moved data to debian/tmp and changed the rule to %:dh_install --sourcedir=debian/tmp See http://anonscm.debian.org/gitweb/?p=collab-maint/boot-repair.git But now I get this error when i try to package: dpkg-genchanges: error: cannot read files list file: No such file or directory dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2 debuild: fatal error at line 1348: dpkg-buildpackage -rfakeroot -D -us -uc failed any idea? Regards Sorry, ignore my previous message. On your Git repository, there's only one branch called master, containing the debian folder. Please read on how to use git-buildpackage. Just FYI, you should use 2 branches, one for your upstream code, and one containing that + the debian folder, so that one can use git-buildpackage. Cheers, Thomas -- 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/4f01d190.2030...@debian.org
Re: RFS: policyd-weight
Hi, Since I might be interested in using this software, I had a quick look to the packaging. I've noticed some issues that are remaining. Ansgar, feel free to correct me if you don't agree with my remarks! * Please run lintian with the options -Ii -E --pedantic so it will show you more issues (like spelling mistakes in the man pages, etc.). I wont details them here, since Lintian does it better than me! :) * Your debian/copyright doesn't mention yourself, I think you should add yourself in the Files: debian/*. The debian/copyright is also badly formatted, and generally speaking seems to be using a very old definition of the DEP5 specifications. It'd be great if you could update that. * The debian/init.d script doesn't use lsb-base for printing messages. Please switch to it (and depend on lsb-base) and replace the echoes. Also, the set -e should be (IMHO) set earlier in the script. As a bonus point, use the default in /lib/init/vars.sh with something like that: . /lib/init/vars.sh . /lib/lsb/init-functions case $1 in start) [ $VERBOSE != no ] log_daemon_msg Starting $DESC $NAME * debian/postinst does some checkings against version 0.1.14-beta-3, yet, version 0.1.14.17-5 is in ole-stable, meaning that right now, you will always get the same result. It'd be great, IMO, to fix this, and remove the tests and all, since you already know the result of them. By the way, since the package is already in Debian, I think it would be fine to have it uploaded without the above fixes, and fix that on the next upload. I hope that helps, Cheers, Thomas -- 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/4f01daf8.2030...@goirand.fr
Re: RFS: policyd-weight
On 01/03/2012 03:02 AM, wer...@aloah-from-hell.de wrote: Hi, * Your debian/copyright doesn't mention yourself, I think you should add yourself in the Files: debian/*. The debian/copyright is also badly formatted, and generally speaking seems to be using a very old definition of the DEP5 specifications. It'd be great if you could update that. Question: what is the correct Format: entry in debian/copyright? I don't understand what i need to define there. Lintian throws me an error like: P: policyd-weight source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5/ N: N:Format URI of the machine-readable copyright file is not versioned. N: N:Please use N:http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?revision=revisi N:on as the format URI instead. OK, got it *but* what revision do i have to use? http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?revision=? Thanks, Werner As per: http://anonscm.debian.org/viewvc/dep/web/deps/dep5/ the latest revision seem to be 240. Thomas -- 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/4f020f4c.7090...@debian.org
Re: RFS: policyd-weight
On 01/03/2012 03:03 AM, wer...@aloah-from-hell.de wrote: Thanks for the hint. How do you handle spelling errors by the upstream author in the relevant manpages? Should i create patches for it? How's the workflow handling spelling errors by the upstream author? Best is to create a patch, include it in your Debian package, and forward that patch to upstream so he can have his manpage fixed upstream as well (so you will later remove the debian-specific patch). Thomas P.S: I'm registered to the list, no need to Cc: -- 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/4f021834.70...@debian.org
Re: RFS: boot-repair
On 12/31/2011 06:41 PM, yannubu...@gmail.com wrote: Hello Alessio, Currently this is an optional feature: at start-up a window appears asking the user if he wants to update from the PPA . Choice is left to the user (Yes/No buttons). Is this forbidden by Debian policy? if yes, i will deactivate this window. Regards, Yann Yann, I didn't check the Debian policy regarding this issue, but... Just think about it. We already have software in Gnome to let us know when there are updates for any software we use in Debian. Then, why would you need to write something specific to your own software? The functionality is already there for all the OS! Thomas -- 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/4efeee3d.9020...@goirand.fr
Re: RFS: boot-repair
setupOn 12/31/2011 07:21 PM, yannubu...@gmail.com wrote: The setup.py files are not from me, they were automatically created by the tool i use for PPA upload (LaunchBash). My knowledge is null about this subject, i can't answer your questions. So feel free to replace the setup.py files by whatever method you feel more appropriate. I'm afraid that's not the way it works. I don't intend to do the packaging work for you, just review it. You should yourself learn how to do the packaging. Read how dh_install works (read its manpage for example), really, it's easy. Your software is manipulating /etc/apt/sources.list, and then using apt-get install. If your software is in Debian, why would we need you to install your PPA source list in /etc/apt/sources.list? This is unacceptable for Debian. please see my previous email (answer to Alessio). I have read all messages on the thread, yet I don't see what you are point at. Also, you are installing your PPA with names matching Ubuntu releases. This has nothing to do in Debian! because all packages are same for all distros (Debian and Debian derivatives) and versions (Lucid packages = Precise packages) . But i agree this can change some day, so I should create a rep for Unstable. You don't get it: we DO NOT accept that your software silently changes something in the sources.list, unless your software purpose is to do the administration of that file, for example (see what does software center). Don't do that. Whatever the way you put it, I don't see any reason why someone would want to have your PPA added to the sources.list like this. All of your needed dependency should be in Debian, and I don't see why we would need your PPA if it's there. Cheers, Thomas -- 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/4efefb86.3060...@goirand.fr
Re: RFS: boot-repair
On 12/31/2011 09:11 PM, yannubu...@gmail.com wrote: Currently this is an optional feature: at start-up a window appears asking the user if he wants to update from the PPA . Choice is left to the user (Yes/No buttons). Is this forbidden by Debian policy? if yes, i will deactivate this window. Regards, Yann Yann, I didn't check the Debian policy regarding this issue, but... Just think about it. We already have software in Gnome to let us know when there are updates for any software we use in Debian. Please note that Boot-Repair is a special software: - Boot-Repair is mostly used by users who have just tried installing Linux for the first time - Boot-Repair is often a last-chance tool before the user formats everything, or abandons Linux installation to return to Windows... (e.g. when installing Ubuntu breaks Windows boot, or GRUB menu doesn't appear). - Boot-Repair is mostly used in live-CD (when no access to any OS), and the default Update tools will update all packages, which is useless, very long, and even problematic (kernel updates require reboot). - new boot problems appear frequently (especially new PC with UEFI boots... ), so i think it's important to give the user an easy way to update Boot-Repair (i repeat: update is optional and not silent). I repeat i will deactivate it if needed by Debian Policy, i simply hope you understand why i added this update option. Sorry, but even with the above, no, I don't understand why. If you are repairing a broken OS, there's a lot of chances that you wont have even network connectivity. If you are doing that in such a live CD for repairing a broken OS or MBR, then betting on network access is really not something you want to do, IMHO! Thomas -- 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/4eff64f4@goirand.fr
Re: RFS: boot-repair
On 12/31/2011 08:10 PM, Jakub Wilk wrote: AFAICS the package has nothing to do with Python, except that is uses distutils as a build system. Agreed, and I think it should be removed, especially when what's intended is installing a single bash script (in some cases), and when the packages are natives. When building, I got a bunch of the below output, and this for all dh_helper called by the dh 8 sequencer: Unknown option: buildsystem So your thing here doesn't work: export DH_OPTIONS=--buildsystem=python_distutils It does work well (though it does cause warnings, and it'll break in compat =8). Oh, that's why then. The packages have compatibility level 7 IRRC. Thomas -- 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/4eff65b1.9050...@debian.org
Re: RFS: boot-repair
description of clean-ubiquity (why do you split each line as if it was paragraphs?). As a general remark, your long descriptions aren't good enough, by reading them I don't understand what your software is doing. They should use better wording. Let me give an example: Package: boot-repair Description: Simple tool to repair frequent boot problems In some situation, you might do explain-what and then you may run into explain-what-problem. Boot-Repair is a graphical tool which will repair these problems by explain what it does, which then restores access to the operating systems you had installed before the issue. . Also, boot-repair has advanced options for reinstalling GRUB, restoring an MBR restore, or repair a broken filesystem. I can also restore the original bootsector if it has been saved previously by clean-ubiquity. When writing long descriptions, imagine that you are the reader, and that you are discovering something new. The long description should be enough to give you a rough idea why you may use the described software. I hope this helps. Please fix the above in all packages, then come back to ask on the debian-mentors list. Happy new year, Thomas Goirand -- 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/4efee61c.6030...@goirand.fr
Re: uscan, watch files, and gihub tags
On 12/19/2011 03:15 PM, Thomas Goirand wrote: I tried to poke with opts=uversionmangle=s/^master\/// to remove master/ from the version of upstream git repo, but no luck... Seems this works for me now: version=3 https://github.com/jonludlam/xen-api/tags /jonludlam/xen-api/tarball/master/(.+) Cheers, Thomas -- 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/4eef27f1.7080...@debian.org
Re: uscan, watch files, and gihub tags
On 12/19/2011 01:55 PM, Scott Howard wrote: Since your title said github tags, I think you're looking for: http://githubredir.debian.net/ The source code is there if you're not on github. Cheers, Scott Hi Scott, thanks for your quick answer. I'm now cross-posting in -mentors. In my case, upstream tagged master/1.3, and I'm getting issues still, with uscan. zigo@node4407:~/sources/xen-api/xen-api$ cat debian/watch version=3 http://githubredir.debian.net/github/jonludlam/xen-api (.*).tar.gz but then, I have the following error: zigo@node4407:~/sources/xen-api/xen-api$ uscan --verbose --report -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: http://githubredir.debian.net/github/jonludlam/xen-api (.*).tar.gz -- Found the following matching hrefs: /github/jonludlam/xen-api/0~master.tar.gz /github/jonludlam/xen-api/master/1.3.tar.gz dpkg: warning: version '/master/1.3' has bad syntax: version number does not start with digit Newest version on remote site is /master/1.3, local version is 1.3 dpkg: warning: version '/master/1.3' has bad syntax: version number does not start with digit = Newer version available from http://githubredir.debian.net/github/jonludlam/xen-api/master/1.3.tar.gz -- Scan finished FYI, I really am packaging version 1.3, so uscan should find out that I'm up-to-date. I tried to poke with opts=uversionmangle=s/^master\/// to remove master/ from the version of upstream git repo, but no luck... Upstream is friendly, so I can ask to remove the annoying bits of the versions, but there's already 9 packages involved, so I'd be glad to find a solution keeping upstream scheme, that would be less work and forcing git push/pull --force --tags to everyone working on the project is annoying. Cheers, Thomas Goirand (zigo) -- 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/449f.2090...@debian.org
Re: RFS: php-xml-beautifier
On 12/15/2011 06:50 PM, Mathias Ertl wrote: My previous join-request was completely ignored. All-in-all http://php.debian.net seems pretty broken and dead and the mailinglists are predominantely used to redistribute spam. I haven't seen you sending any email to the list for PHP: pkg-php-ma...@lists.alioth.debian.org you should do so if you want to join the pkg-php group. Don't expect that any random request to join will be approved. You got to ask and tell who you are on the list. I think that's truth for every lists in Debian (I'd like to have other project admin's opinions about this). I hope the package is now fit for debian sid! I'm downloading and checking again. Thomas -- 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/4eea05bd.4000...@debian.org
Re: RFS: php-xml-beautifier
On 12/15/2011 07:44 AM, Mathias Ertl wrote:
[...] I am still looking for a
sponsor of the package. For easy reference, here is the git-repo:
https://git.fsinf.at/apt/php-xml-beautifier
... here is the package on mentors:
http://mentors.debian.net/package/php-xml-beautifier
and you can check it out with this command:
dget -x http://mentors.debian.net/debian/pool/main/p/php-xml-
beautifier/php-xml-beautifier_1.2.2-1.dsc
greetings, Mati
Hi Mati,
I'll go ahead and sponsor the upload of php-xml-beautifier if you
correct what's below.
1/ pkg-php-tools and missing php-xml-util depends
It's good you've switched to pkg-php-tools, but you've missed something
important:
Depends: ${phppear:Debian-Depends}
Because of this, you've missed the Depends: php-xml-util which is found
automatically by pkg-php-tools if you put the above substitution
variable. I know that as a fact, because I tried myself! :)
2/ debian/copyright
The copyright notice for GPL-3+ is missing important bits that, unless
I'm mistaking, should be there. Other packages I've seen carrying the
GPL3 have a no warranty disclaimer and the address of the FSF. I
believe it should be in your debian/copyright too.
The rest of the packaging, to me seems into shape for an upload in SID,
but the above 2 things are blockers.
3/ Using Git for packaging
It'd be great if you were using git-buildpackage and storing your
packaging into Git. A majority of PEAR packages are using it, and most
are stored in /git/pkg-php. Would you care for joining the Alioth group
and maintain this way? (it's not mandatory to team maintain, but I
really recommend it)
Thomas Goirand (zigo)
--
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/4ee97dbf.9020...@goirand.fr
Re: RFS: php-xml-beautifier
On 12/09/2011 08:46 PM, Mathias Ertl wrote: I already joined the mailinglist there and enjoy the spam that comes in there every day ;-). I did however file a join-request on their Alioth homepage. I can only hope they approve the request. I'd suggest sending a private mail to the admins of the project. Last, why did you choose GPL-3+ for your packaging work, when upstream has chosen a more relaxed BSD 2 clause? Because I think its a good license. Is that a problem? I am happy to choose something different or the same as the package, if there are any customs or conventions I am not aware about. There's no problems per say, I believe everyone is free to release the work it does in Debian in the license of its choice if it's DFSG free, but I just feel weird to have just a few files needed for the packaging to be more restrictive than the ones from the original authors itself. Said in another way: your choice of licensing is legally valid inside Debian, but it wouldn't be mine. I'd adopt the license of upstream, especially if it's the BSD license. IMHO, software with multiple licenses are a pain when writing debian/copyright files. That being said, I still look for a sponsor for that package! ;-) Please ping me in few days if I didn't get time to review again and nobody else stood up (I'm going to sleep now, I'm too tired to start packaging reviews ...). Thomas -- 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/4ee26c7a.8070...@goirand.fr
Re: RFS: php-xml-beautifier
On 12/08/2011 08:18 PM, Mathias Ertl wrote:
Dear mentors,
I am looking for a sponsor for my package php-xml-beautifier. This package
contains a class to format and beautify XML docuemtents (for example add
linebreaks, format comments, etc.). Several other PEAR packages depend on it
(see homepage: http://pear.php.net/package/XML_Beautifier/ ).
* Package name: php-xml-beautifier
Version : 1.2.2-1
Upstream Author : Chuck Burgess ashn...@php.net
* URL : http://pear.php.net/package/XML_Beautifier/
* License : BSD-2-clause
Section : web
It builds those binary packages:
php-xml-beautifier - Class to format XML documents
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/php-xml-beautifier
Alternatively, one can download the package with dget using this command:
dget -x http://mentors.debian.net/debian/pool/main/p/php-xml-beautifier/php-
xml-beautifier_1.2.2-1.dsc
I would be glad if someone uploaded this package for me.
Kind regards,
Mathias Ertl
Hi Matias,
Please use pkg-php-tools for your package, so that it can use variable
substitutions, so that you can later use:
Recommends: ${phppear:Debian-Recommends}
Breaks: ${phppear:Breaks}
Description: ${phppear:summary}
${phppear:description}
Then in your debian/rules file, you can use:
#!/usr/bin/make -f
%:
dh $@ --buildsystem=phppear --with phppear
in your control file. Of course, you need to build-depends on it.
Also, it'd be great if you were trying to have your package team-maintained.
Please join the PHP PKG team and help, rather than working on your side
only,
and have your PEAR package sent to the Git repository on Alioth (in
/git/pkg-php there's already quite a bunch of PEAR modules...).
Besides that, I don't think you need debian/dirs, and debian/README.Debian
doesn't document anything useful.
Last, why did you choose GPL-3+ for your packaging work, when upstream has
chosen a more relaxed BSD 2 clause?
Cheers,
Thomas Goirand (zigo)
--
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/4ee1187c.3090...@debian.org
Using /lib/init/vars.sh and its VERBOSE variable in init.d scripts
Hi, I've seen a package which I want to sponsor using: # Load the VERBOSE setting and other rcS variables . /lib/init/vars.sh [...] case $1 in start) [ $VERBOSE != no ] log_daemon_msg Starting $DESC $NAME but in Debian, /lib/init/vars.sh contains VERBOSE=no by default, so the init.d script isn't producing outputs when I call it. I have to admit I'm quite surprised, and don't know how to handle this. Is this normal? Should I revert this, or supposedly, should I implement this in my own scripts? Cheers, Thomas -- 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/4ee1a18c.4030...@debian.org
Re: RFS: python-libmemcached (3rd try)
On 12/07/2011 02:47 PM, Shell Xu wrote: Dear mentors, I am looking for a sponsor for my package python-libmemcached. * Package name: python-libmemcached Version : 0.40-1 Upstream Author : hongqn hon...@gmail.com mailto:hon...@gmail.com * URL : http://code.google.com/p/python-libmemcached/ * License : Apache License 2.0 Section : python It builds those binary packages: python-libmemcached - Python wrapper for libmemcached To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-libmemcached Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-libmemcached/python-libmemcached_0.40-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Shell Xu Hi Shell! :) I'm happy you're doing even more Debian packaging work, but feel sorry that it's your 3rd try. So let me help with a quick review. I didn't find much issues, but I believe I have still few remarks that might help. Feel free to discuss what I say, if you don't agree with some of the points (I don't pretend to know everything or to be always right...) 1/ debian/changelog You wrote: * Initial release (Closes: 647579) But you really want it to be (notice the sharp: * Initial release (Closes: #647579) As I'm not sure if just (Closes: 647579) without the # will really close the ITP once the package is uploaded (I never tried, but I suspect it would just fail). 2/ debian/control You wrote: Build-Depends: debhelper (= 8.0.0) Just (= 8) is enough, = 8 is the same as = 8.0.0 In the long description, just completely remove A few notes on its design:, and replace it with: Some of the features include: * Support large item (=1M), auto splitting and merging. * [ ... ] eg, no need to add an empty line before the least of features. Can you also please explain this: The original project offered 3 patches for libmemcached 0.40, but not work with libmemcached 0.41 or upper. So it's not patched to package libmemcached or upstream yet. This may lead to some bugs. This really seems suspicious, it shouldn't be in a package description (IMHO). If you have an issue with your package, just fix it, don't write it in the package description. Or maybe, write about it in a README.Debian or something. This isn't describing the package... 3/ debian/copyright I don't think you got the Apache-2.0 license thing correct. At least, your copyright file should have something like: In Debian systems, a full copy of the Apache-2.0 license may be found at: /usr/share/common-licenses/Apache-2.0 4/ You are packaging the readme in debian/docs which contains: 1.It needs libmemcached 0.40, patched with fail_over.patch, empty_string.patch, buffer_request.patch 2.If you use the python whose version is 2.5, you should modify the Py_ssize_t definition. * It's up to you to ensure that the dependencies for your package are correct in Debian (eg: libmemcached should contain the needed patches for your software if it needs it), so 1. shouldn't be there. * Debian SID is using python 2.7 As a consequence, we don't need this readme to be packaged in Debian, so just delete debian/docs 5/ Please clean all comments in debian/rules. We don't need them to stay, it's just there for you to read the sample template, but it adds nothing to your packaging at all (IMHO). 6/ lintian You should be running Lintian with the flags -Ii -E --pedantic. I've found that one when using --pedantic: P: python-libmemcached source: source-contains-svn-commit-file svn-commit.tmp N: N:The upstream source contains an svn-commit(.NNN).tmp, almost certainly a N:left-over from a failed Subversion commit. You may want to report this N:as an upstream bug. N: N:Severity: pedantic, Certainty: certain N: That's it for today, I hope to see you tomorrow at the weekly Shanghai Linux User Group meeting my friend! Cheers, Thomas Goirand (zigo) -- 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/4edf8e5f.4060...@debian.org
Re: RFS: python-libmemcached (3rd try)
On 12/07/2011 02:47 PM, Shell Xu wrote: Dear mentors, I am looking for a sponsor for my package python-libmemcached. * Package name: python-libmemcached Version : 0.40-1 Upstream Author : hongqn hon...@gmail.com mailto:hon...@gmail.com * URL : http://code.google.com/p/python-libmemcached/ * License : Apache License 2.0 Section : python It builds those binary packages: python-libmemcached - Python wrapper for libmemcached To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-libmemcached Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-libmemcached/python-libmemcached_0.40-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Shell Xu I forgot something. Since you're using dh_python2 (which is a good thing), you need to: Build-Depends: python-all 2.6.6-3~ as per: http://wiki.debian.org/Python/TransitionToDHPython2 Reread /usr/share/doc/python/changelog.Debian.gz for that... Thomas -- 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/4edf9512.9020...@debian.org
Having mentors.d.n aware of packaging teams
Hi, Numerous times, I've seen people post their RFS requests for software that should be looked over by some packaging teams. Fore example, PHP or PEAR modules, python libraries, etc. It'd be really great if mentors.d.n was aware of the different packaging team, and was kindly telling about it when uploading a new package. For example, debExpo could look at the proposed package name, and be smart enough to tell that an RFS for a php-* package should be directed to the PKG-PHP team, a python-* to the python team, etc. I wouldn't have the time to implement it, but that would really be a great feature! What are the opinions of other DDs? Cheers, Thomas Goirand (zigo) -- 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/4ecd0c94.6010...@goirand.fr
Re: RFS: php-pecl-http - extended HTTP support for php5
On 11/11/2011 05:53 AM, Peter Pentchev wrote: Dear mentors, I am looking for a sponsor for my new package php-pecl-http. * Package name: php-pecl-http Version : 1.7.1+dfsg.1-1 Upstream Author : Michael Wallner m...@php.net * URL : http://pecl.php.net/package/pecl_http * License : BSD-2 Section : web Language: C It builds a single binary package: php5-pecl-http - extended HTTP support for php5 Hi there! I would advise you to send your ITP also to the PHP maintainer list: pkg-php-ma...@lists.alioth.debian.org Also, since we try to maintain everything as a team when it comes to PHP packages, I would advise that this package is also sent to the pkg-php git repository. That means that you should join the Alioth project for it, and do your packaging using Git. If you do the above effort, and nobody steps in (maybe Ondrej or Sean has enough time to check on it? You guys might have a better level than me for such PECL modules...), I'll review it and sponsor it (if of course, it's good enough). But before I do that, could you please explain a bit more what it does, and why php5-pecl-http is useful? Thanks for your packaging effort, Thomas Goirand (zigo) -- 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/4eca9598.6040...@debian.org
Re: start mysqld from debian/rules?
On 10/31/2011 08:54 AM, Paul Wise wrote:
On Mon, Oct 31, 2011 at 6:04 AM, Cédric Boutillier wrote:
I was wondering what would be the best way to start (and possibly stop)
the mysql server from the debian/rules makefile. Could anyone help me on
this?
Run mysqld from debian/rules
Hi,
We've done that in the libdbi-drivers package. The way to do it is like
this:
-- SCRIPT START --
#!/bin/sh
MYTEMP_DIR=`mktemp -d`
ME=`whoami`
mysql_install_db --no-defaults --datadir=${MYTEMP_DIR} --force
--skip-name-resolve --user=${ME}
/usr/sbin/mysqld --no-defaults --skip-grant --user=${ME}
--socket=${MYTEMP_DIR}/mysql.sock --datadir=${MYTEMP_DIR}
--skip-networking
export MYSQL_UNIX_PORT=${MYTEMP_DIR}/mysql.sock
echo -n pinging mysqld.
attempts=0
while ! /usr/bin/mysqladmin --socket=${MYTEMP_DIR}/mysql.sock ping ; do
sleep 3
attempts=$((attempts+1))
if [ ${attempts} -gt 10 ] ; then
echo skipping test, mysql server could not be contacted
after 30 seconds
exit 0
fi
done
... DO_YOUR_TESTS_HERE ...
/usr/bin/mysqladmin --socket=${MYTEMP_DIR}/mysql.sock shutdown
rm -rf ${MYTEMP_DIR}
-- SCRIPT END --
Note that by default, you'll have login root with empty password
available, and it's up to you to create users if you need.
Also, remember to use the BUILD_OPTIONS to have the test suite
be disabled in case we don't want to run them. That's a Debian
policy requirement. So you'll also need something like that in
your debian/rules:
ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
override_dh_auto_test:
./run_tests.sh
endif
Good luck,
Thomas
--
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/4eae2a23.2070...@debian.org
Re: RFS: php-db-dataobject
On 10/23/2011 03:11 AM, David Hannequin wrote: dget -x http://mentors.debian.net/debian/pool/main/p/php-db-dataobject/php-db-dataobject_1.9.6-1.dsc Hi, What are your motivations for having this package in the archive? Also, next time you have a PEAR package, please Cc: the Debian PHP PEAR Maintainers pkg-php-p...@lists.alioth.debian.org. Also, PEAR package are team maintained, it'd be great if you join the packaging project on Alioth, and set the Maintainer: field as the list (and you just as Uploaders:). 1/ debian/compat Please use compatibility level 7 at least, and probably 8 would be even better, since the package has never been in Debian. 2/ CDBS Could you please switch your package to use the dh 8 short style, and pkg-php-tools instead of CDBS? 3/ debian/copyright Your copyright file is completely wrong. That alone is enough to reject your package, unfortunately. First of all, you should put the full of the PHP license 3.01 in it. Second, it'd be great if you could use the DEP5 format: dep.debian.net/deps/dep5/ I didn't check your other package, since I am guessing it will have the same issues. Please let us review one package at a time, and once that one is ok, we can move to the 2nd one. 4/ debian/control There's no home page field. Section should be php, not web Also, your package creates an empty /usr/bin folder (as reported by lintian) as well as usr/share/php/.registry/.channel.doc.php.net/. Thomas Goirand (zigo) -- 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/4ea78886.4010...@debian.org
Re: git-buildpackage and tarballs
On 10/22/2011 07:41 PM, Charles Plessy wrote: Le Sat, Oct 22, 2011 at 01:29:57PM +0200, Jakub Wilk a écrit : Just because some developers choose to abuse native source format, doesn't mean it's something that should be advocated to newcomers. So please stop. Thanks. Apart from the point I raised about translations (for which I never read a complain from the translators themselves), what would be the problems ? Using a ‘native’ format when there is no upstream tarball looks very appropriate to me. Cheers, If there's no upstream tarball, just create one. Using the native format is *very* annoying for derivative distributions, please don't do that unless you *know* that there is *absolutely no chance* that your package will migrate to a derivative distribution like Ubuntu or others. On 10/22/2011 09:59 PM, Charles Plessy wrote: This is excactly why I am limiting my recommendation to the case where there is no upstream release as tarball. In that sense, a new source package is still a downstream event that is not indicative of an upstream release. This isn't the reason to choose a native format. See above. I am not sure that it is a situation that is to be avoided by newcomers. Newcomers tend to work on new software, and new software tends to be distributed on source hubs, increasingly without tarballs, instead of source forges with tarballs. This isn't the reason to choose a native format. See above. Thomas -- 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/4ea3974e.9090...@debian.org
Re: git-buildpackage and tarballs
On 10/23/2011 11:37 AM, Charles Plessy wrote: Hi Russ, I think that we are discussing two separate questions: whether a maintainer of his own software in Debian should release a new upstream version when updating the Debian package If the change in the software isn't located in the packaging, then answer is yes. Otherwise, just increase the debian specific release number and don't re-upload the orig.tar.gz. and whether the the maintainer of a Debian package for which there is no upstream tarball can use a native format or not. That's *never* the reason to choose the native format. There is no need to trigger update on other systems when the changes only affect Debian. But note that it is difficult to draw a line anyway. Why is it difficult? If you think it is (I don't think it is), then just increase always the upstream version, if that is more easy for you to do like this. That's what I do in all software that I maintain in Debian and for which I'm also upstream. It always works. But anyway, this has nothing to do with using the native format or not. Among the packages I maintain, some show new upstream releases in my radar, which fix Windows or Mac OS issues only. Some other project I maintain has a friedly version scheme, where the most minor number indicates changed relevant to the MinGW port only. All of this is upstream decisions on which we can not give more than opinion and guidance. Of course you can voice your opinion to upstream! And guess what? Most of the time, they are very distribution friendly, and will accept to change the way they use version numbers! :) The point that I would like to make, is that when there is no upstream tarball, whatever the reason, the dpkg native format is a natural choice for a Debian package. NO! Let's say you have a package with an init script. In Ubuntu, they will want to remove that debian/init script, and write an upstart script instead. In their case, they just keep your orig.tar.gz file, and just change a tiny bit of Debian packaging each time they import your package. By choosing to use a native format, you are forcing them to do ugly things with the version numbers that they could avoid otherwise. And an init.d script is only one out of many examples which you have as a difference in packaging a package for Debian or for Ubuntu. I could also have talked about: - differences in dependencies - differences in the maintainer field - differences in release names in the debian/changelog - differences in user/group names And there's even more reasons, like allowing all DDs to do an NMU in a normal way to correct an RC bug during the distribution freeze (or a bug squashing party), for example, but not willing to touch your upstream code or version, etc... So your point about upstream not doing a tarball isn't the reason to choose the native format. Just forget it! I am aware of Develpers Reference's §6.7.8.1.2, but I do not think it is widely followed IT IS followed whenever possible. In rare cases, when upstream really does silly things with his original tarball, then you have to recreate the tar.gz, but that's pretty rare. If there's no upstream tarball, and just a VCS, then you should do something like this: example-software_0.1.2+20111023.git.orig.tar.gz You are free to use another scheme, like using the SVN checkout number, or use tag names if you see fit, but adding the date and the CVS name is a commonly accepted naming scheme for such case. Thomas Goirand (zigo) -- 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/4ea39d42.5070...@debian.org
Re: berlios closing; where should my projects escape to?
On 10/18/2011 11:44 PM, Barry Warsaw wrote: On Oct 18, 2011, at 12:00 PM, Boris Pek wrote: Of course, I'll disagree about Bazaar there. I think it's actually the most user friendly of the bunch, and totally up to the task of hosting your projects. I use it for almost all of mine. I also think that it has workflows and command lines that will feel fairly natural and similar to you as a Subversion user. Don't dismiss it out of hand. (It also has a bzr-svn plugin for bridging between the two vcs's.) I am most definitely *not* interested in getting into a flame war about version control systems. If you don't like Bazaar, fine, YMMV. If you have technical questions, I'm happy to answer them as best I can, or point you to other forums that can help you. Cheers, -Barry Not getting into any war, but it seems 90% of everyone thinks Git is a way better than BZR, and that the 10% that remains are BZR extremists. Since VCS is all about sharing your sources (unless you don't care about others and sees it as only a history/backup of your work), you'd better not be too annoying for the vast majority of your VCS users. Thomas -- 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/4e9fa30c.3070...@debian.org
Re: [RFR] - PHP_Timer (Needed by phpunit)
On 10/17/2011 05:57 AM, Luis Uribe wrote: Hi Thomas, Do you remember me? I'm the one trying to package phpunit and all of it's dependences. The work has been stopped for a few months but now i have time again and i want to finish it. Currently i made a [1] package for PHP_Timer http://lists.debian.org/debian-mentors/2011/10/msg00093.html Since upstream is not the official PEAR channel, i have to do some things on debian/rules: set the config and php dir of PEAR with config-set, install the channel manually and install the package. I'd like to ask for your review of the package, i just send an email to debian-mentors but no one answer yet. JUst need to be sure that my approach is correct before i upload the rest of the packages. I would appreciate your help and advices about packaging those PEAR modules (and sponsoring too, obviously). Thanks Hi, 1/ Please use the DEP5 format for your debian/copyright. You don't have to, but it's a way better with it IMHO. [0] 2/ Please use php-pkg-tools, depend on it and on debhelper 8, and have your debian/control variables set to use it. I'm slowly converting all my PEAR packages to it myself. You can have a look into php-html-common which I maintain to see how to modify your debian/rules and debian/control to take advantage of pkg-php-tools. You don't have to use all of its features, but I would strongly recommend to use at least some of it (you don't have to use the dh 8 short style if it doesn't fit the type of package you are doing, but most of the time, it's best to do so. See php-image-barcode to see how to override dh_install and use pear to manually install stuff in a dh 8 short style makefile for PEAR packages). 3/ Please also update your Maintainer field to Debian PHP PEAR Maintainers pkg-php-p...@lists.alioth.debian.org (I mean, please use the PEAR maintainers and not just the PHP maintainers). 4/ Your long description is too short, please describe better what the package does. I'm sure you can do better! :) 5/ Are you sure you want to put your packaging work in a license more restrictive than upstream author? (it's allowed, but I wouldn't personally recommend it. If upstream uses a BSD license, what pushes you to use GPL-2?) 6/ Once installed, your package creates: /usr/share/php/PHP/Timer.php /usr/share/php/PHP/Timer/Autoload.php IMHO, it should rather install: /usr/share/php/Timer/Timer.php /usr/share/php/Timer/Timer/Autoload.php 7/ Do you know why your package doesn't build in Squeeze? :) 8/ php-timer doesn't seem to be in Debian (SID or otherwise), so please clean your debian/changelog which should be only: php-timer (1.0.2-1) unstable; urgency=low * Initial release (Closes: #611767) -- Luis Uribe a...@eviled.org Thu, 06 Oct 2011 07:37:03 -0500 That's it for the moment, please correct your package, reply to this email point by point, then I'll review your package again. [0] dep.debian.net/deps/dep5/ -- 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/4e9d13da.1040...@debian.org
Re: What version of debian to develop debian packages?
On 09/29/2011 03:51 PM, Rustom Mody wrote: Any further tips pointers on this? There seem to be a lot of virtual machine options nowadays... Whatever hypervisor you like, it doesn't mater much. If you do Desktop development, then Virtualbox is quite convenient (especially mouse pointer handling), but if you do server oriented things, then Xen or KVM might be good too. All of these have a kind of snapshot functionality. Thomas -- 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/4e846b9b.9060...@debian.org
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/25/2011 08:15 AM, Daniel Kauffman wrote: Then I'd prefer if another DD that did some apache module packaging had a last look before I sponsor the package for you (because I may well have missed something). Sounds good, extra eyes are always appreciated, especially when dealing with network services. I think your package is now up to shape, the only thing I think is a bit over-engineer is your debian/rules. Don't you think that override_dh_auto_install could be replaced by a debian/install file? Not a big deal anyway. If you find a 2nd person to review the package, even a non-DD, I'll sponsor it. Thomas -- 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/4e82b37c.7060...@debian.org
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/23/2011 03:54 AM, Daniel Kauffman wrote:
On 09/22/2011 02:38 AM, Thomas Goirand wrote:
On 09/22/2011 03:32 PM, Daniel Kauffman wrote:
I didn't see a reference to quilt in the Debian Policy Manual and the
Debian New Maintainers' Guide section 2.9 seems to suggest that a
native package is ok where there is no upstream.
No. It's ok to do so when the software is intended only for
Debian (like, the Debian installer for example... I'm not even
sure that's the case, just an example), which isn't your case.
Thanks for the clarification regarding native vs. quilt, rebuilt using
quilt. The updated package can be downloaded from:
http://socketpolicyserver.com
Hi Daniel,
Since I reviewed once your package, I feel like I have to do it again,
and continue the mentoring process. So let me do again, this time
more deeply.
1/ debian/changelog
Since your package has never reached Debian yet, your changelog
should be only:
libapache2-mod-socket-policy-server (0.0.1) unstable; urgency=low
* Initial release. (Closes: #642282)
-- Debian Packaging Team
debian-packaging-t...@socketpolicyserver.com Tue, 20 Sep 2011
21:25:00 -0800
So please remove all other entries.
We don't really care what upstream version you use, so it could be
0.0.4-1 if you feel like it, and if it's more convenient for you to not
downgrade in your repository.
Also, it seems that your /changelog is the same as what's in the
debian/changelog, and you are packaging it twice!!! My advice
here: write things in /changelog that are only for upstream code,
and in debian/changelog only things that concerns the packaging
itself and nothing else.
2/ debian/copyright
It's basically not respecting the specifications. It should be
something like:
header paragraph
files paragraph
[license paragraph]
Your copyright file doesn't have a header. Also, I think that
something like this:
License: Other
For alternate licensing arrangments, please contact:
.
licens...@rocksolidinnovations.com -OR- sa...@rocksolidsolutions.org
isn't appropriate and doesn't fit the spirit of DFSG (I may be wrong
here, I have never been really good with licenses, but I just feel
it isn't right). Especially, on the Apache 2.0 license, it says:
THIS SOFTWARE MAY NOT BE USED EXCEPT UNDER LICENSE,
then just later, you are writing that alternate licensing arrangments
could be made...
Just leaving the Apache 2.0 license, which give a
very big amount of freedom, seems enough to me. I fail to see
how it could be more free than with the Apache 2.0 license! :)
3/ debian/patches/debian-changes
Don't you think that a Debian specific patch could be avoided?
Basically, there's only 2 things that are done in the debian-specific
Makefile: build and install. These could easily be put in your
debian/rules by overriding the dh install and build target (namely,
if I'm not mistaking, dh_auto_install and dh_auto_build). That
would be a lot more simple than having to manage a patch like this.
Not that this is just a suggestion, what you did works also, I just
think it's a bit over-engineered, and that overriding the dh rules
targets would be more simple to maintain.
4/ debian/postinst
While it's fine to automatically install a site in sites-available,
and install and activate a .load Apache module, actually activating
the default vhost that you created might not be appropriate,
especially since what you are doing is activating a policy with
site-control permitted-cross-domain-policies=none / in it.
Am I right that basically, it will do the same as if nothing was
done at all, and make it completely restrictive?
5/ Your package doesn't build twice
That's the worst issue of your package. Running dpkg-buildpackage
twice in a raw fails with some error: cannot represent change.
This most of the time happens when the clean target is wrong.
Please fix this.
6/ debian/watch file
Please add a watch file. It would be quite easy to write, since
you are using Apache directory listing. Something like this
will do the trick:
version=3
http://socketpolicyserver.com/downloads/libapache2-mod-socket-policy-server_(.*).orig.tar.gz
7/ debian/control
Are you sure that this is accurate:
Maintainer: Debian Packaging Team
debian-packaging-t...@socketpolicyserver.com
And don't you think that just:
Daniel Kauffman debian-packaging-t...@socketpolicyserver.com
wouldn't be better? I mean, is there really a team behind this
Debian packaging? I'm not saying this is bad to write what you
did, just that it's always better to have something that reflects
reality (and this is just a suggestion, nothing really bad).
I can read:
Depends: ${misc:Depends}, ${shlibs:Depends}, apache2 | apache2-mpm,
apache2.2-common
But apache2 depends on apache2.2-common, and so are all
the apache2.2-mpm-* packages that are providing apache2.2-mpm,
so I guess that depending on apache2.2-common is useless here
(if you don't think so, feel free to correct me).
I think that's it for the moment. Let me know when you've
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/22/2011 03:32 PM, Daniel Kauffman wrote: Adobe Flash Player (since version 9.0.124.0) will not open a socket connection to a server unless the server first authorizes the connection via an Adobe socket policy. This module serves these policies. (Adobe uses a non-standard protocol for serving these policies, hence the existence of this module.) Adobe socket policies are configured using XML. This is exactly what should be in your long description!!! There is no upstream, so it seemed appropriate to create a native package... is that incorrect? What do you mean no upstream ? You mean that you are BOTH upstream and maintainer? I didn't see a reference to quilt in the Debian Policy Manual and the Debian New Maintainers' Guide section 2.9 seems to suggest that a native package is ok where there is no upstream. No. It's ok to do so when the software is intended only for Debian (like, the Debian installer for example... I'm not even sure that's the case, just an example), which isn't your case. The native format seems a little simpler. But if I'm missing something, and the quilt format is preferable, I can switch to that. The native format has nothing to do with quilt / source format 1.0 vs 3.0. Unless you are doing something specific to Debian. And it seems that building against the threaded headers results in a module that works with both threaded and non-threaded versions of apache2. Ok, cool then! Thomas -- 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/4e7b021...@debian.org
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/21/2011 12:49 PM, Daniel Kauffman wrote: ... for serving Adobe socket policy files. What's that? How do you make them? The package is ready for sponsorship and can be downloaded from: http://socketpolicyserver.com 1/ The package is a native package, which isn't required for an Apache module IMO. Please read about it in the Debian policy manual. 2/ The package has apache2-threaded-dev as Build-Depends, any reason why it wouldn't work with apache2-prefork-dev also? Also, having a binary package with apache2 | apache2-mpm seems strange to me. 3/ It'd be nice to use the DEP5 format for debian/copyright. Please see http://dep.debian.net/deps/dep5/. It's still a candidate, so it's not a requirement though. 4/ Your Standards-Version: isn't up-to-date. Did you build the package in SID and ran lintian there? Also: I: libapache2-mod-socket-policy-server: extended-description-is-probably-too-short You don't need the last dot at the end, but you do need a longer extended description. Lintian complains with less than 2 lines, but I think at least 10 lines sounds reasonable. By reading what you wrote, I still don't understand what your package is doing. :) 5/ Your debian/README explains how to use apt-get, that we can edit the config file of the module, and how to restart apache. I don't think you should do that, it's not helpful, but there might be other things you want to document (like what to put in the socket policy file for example?). 6/ Your package configures a VirtualHost in a /etc/apache2/conf.d file, don't you think it would be nicer in /etc/apache2/sites-available? If not, please explain here why. I hope the above helps, Thanks for your will to contribute to Debian, Thomas -- 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/4e7a3068.5070...@debian.org
Re: RFS: flare
On 08/22/2011 07:47 PM, Jan-Hendrik (hennr) Peters wrote: Dear mentors, I am looking for a sponsor for my package flare. It's a diablo like rpg game with complete free art and code. This is my first package, hope it's ok ;) See details: * Package name: flare Version : 0.14.1-1 Upstream Author : Clint Bellanger * URL : http://clintbellanger.net/rpg/ * License : GPL and CC-BY-SA Section : games To access further information about this package, please visit the following URL: http://mentors.debian.net/package/flare Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/f/flare/flare_0.14.1-1.dsc Hi, I have no intention of sponsoring this game, I think it's best if I leave this task to people from the Game team, however, I had a quick look out of curiosity. I wanted to know what type of game it was, but ... I couldn't tell by just reading the description. Description: FOSS single-player 2D action RPG engine First, in your short description, remove FOSS. OF COURSE this is a free and open source software, absolutely all software in Debian are, but we don't write FOSS in all short descriptions of all packages. Then, your long description reads: snip Flare is not a reimplementation of an existing game or engine. It is a tribute to and exploration of the action RPG genre. . Rather than building a very abstract, robust game engine, the goal of this project is to build several real games and harvest an engine from the common, reusable code. The first game, in progress, is a fantasy dungeon crawl. . Flare uses simple file formats (INI style config files) for most of the game data, allowing anyone to easily modify game contents. Open formats are preferred (png, ogg). The game code is C++ and is released under the GPL v3; the game art is CC-BY-SA 3.0 /snap Your long description doesn't tell at all what type of game it is. It tells about the engine which is used, what type of config files the project users, and what license the software is being released in. Is this a game??? Now that I read the long description, I have doubts. So, please rewrite completely the short and long description take care of the following: - do not tell about any copyright thing, everything about that should be written in debian/copyright, that's the only place where it belongs - write it for people like me: who don't know anything about the project, or any other types of games. I might well not know what RPG means, but I should still be able to understand what I'm going to download. Please do not write a Diablo like game, because people (like me) might not know Diablo (in fact, that's why I was curious: I wanted to know what Diablo was...). - by reading the long desc. I should be able to know a lot already about what my gaming experience with flare, and what to expect. - do not write about the config files, that's something that should go into the README.Debian or something similar (somewhere in /usr/share/doc/flare, in the manpage, or something like that...). Also, in your debian/copyright, you attempted to use the DEP5 format, and you did a good formatting for the GPL-3.0+ license. I guess you took that from another package, right? But later, on your CC-BY-SA-3.0 license is not well formatted, it goes below the 80th column, has blank lines, etc. It would be also great to mention http://clintbellanger.net/contact.php, which is the way to contact the author. There might be other issues, I didn't look further. Thanks for your contribution to Debian, Thomas Goirand (zigo) -- 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/4e7847b4.7050...@debian.org
Re: RFS: decibel-audio-player (Adoption, new upstream release)
On 09/20/2011 06:26 AM, Leonardo Marín wrote: Hi, This was what I did, ljmarin@LM trunk $ svn diff Index: debian/control === --- debian/control(revisión: 7520) +++ debian/control(copia de trabajo) @@ -4,11 +4,12 @@ Maintainer: Leonardo Marín leojma...@gmail.com Uploaders: Python Applications Packaging Team python-apps-t...@lists.alioth.debian.org Build-Depends: debhelper (= 8.0.0) -Build-Depends-Indep: python (=2.4), python-support +Build-Depends-Indep: python (= 2.6.6-3~) For what reason do you need that exact specific version of Python? Cheers, Thomas -- 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/4e788a8e.3040...@debian.org
Re: RFS: decibel-audio-player (Adoption, new upstream release)
On 09/20/2011 09:13 PM, Piotr Ożarowski wrote: python binary package provides dh_python2 helper and that's why Leonardo bumped minimum required python version. See also http://wiki.debian.org/Python/TransitionToDHPython2 Thanks for the pointer. However, I don't understand this: All packages that use the same namespace have to be converted at the same time. Be sure to use Breaks or Depends relationships to ensure you cannot mix installation of python-support-based packages with dh_python2-based ones. Can you explain, or even better, enhance the wiki so that you wont have to explain to another person? Cheers, Thomas -- 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/4e78de1d.7080...@goirand.fr
Re: RFS: sxiv
On 09/08/2011 12:44 PM, Daniel Echeverry wrote: Hi, 2011/9/7 Jakub Wilk jw...@debian.org mailto:jw...@debian.org * Daniel Echeverry epsilo...@gmail.com mailto:epsilo...@gmail.com, 2011-09-07, 16:15: http://mentors.debian.net/debian/pool/main/s/sxiv/sxiv_0.9-1.dsc I tried to build the package with DEB_BUILD_OPTIONS=noopt, but -O2 was used as optimization anyway. Could you please fix that? -- Jakub Wilk Fixed. Please check out: http://mentors.debian.net/debian/pool/main/s/sxiv/sxiv_0.9-1.dsc Thank you! Hi, We have already quite a large amount of image viewers in Debian. Can you explain why we need that one too? Thomas -- 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/4e68769d.1050...@goirand.fr
Re: PmWiki
On 08/26/2011 03:41 AM, Strobl, Robert wrote:
Hi Thomas,
your referred package is not the one I am maintaining.
Mine can be found at http://share.gloriabyte.de/pmwiki/ and is
lintian clean.
Best regards,
Robert
Hi Robert,
here's my review. The package is generally in a very good shape. I would
have upload it if there wasn't an issue with your debian/copyright.
However, I think there is room for improvement.
1/ Your debian/copyright is wrong. You can't just write:
License: GPL-3
see /usr/share/common-licenses/GPL-3.
you need to put a copyright notice for the GPL-3 as well. Also, it's ok
to use the license you like for the packaging, but generally, it's best
to use a license at least not more restrictive than the upstream one,
and even better if you use the same license as upstream. That's just a
suggestion though, but I would simply use GPL-2 like the upstream
license. What do you think?
2/ In your postinst, you are doing:
ln -s /var/lib/pmwiki /usr/share/pmwiki/wiki.d
ln -s /etc/pmwiki /usr/share/pmwiki/local
Why don't you just use dh_link and ship the symlinks in your package
directly? That would also avoid the need of doing:
rm -rf /usr/share/pmwiki/
in your postrm.
3/ rm -rf /etc/pmwiki/ in your postrm is a bad idea. What if a user
wants to writes notes in /etc/pmwiki/my-nice-notes? You'd be deleting it
on the purge target, which the user didn't want.
I would also suggest that you write a very documented
/etc/pmwiki/config.php with in it things like:
?php if (!defined('PmWiki')) exit();
# Define here the title of your wiki
#$WikiTitle = Example title;
# path to your logo
#$PageLogoUrl = /path/to/logo.gif;
# URL of your wiki
#$ScriptUrl = http://pmwiki.example.com;;
# Password for the admin
#$DefaultPasswords['admin'] = crypt('');
# Set to 1 to enable uploads
##$EnableUpload = 1;
# Define a password for the uploads
#$DefaultPasswords['upload'] = crypt('');
# Name of your skin, corresponding to the folder inside pub/skins
#$Skin = 'gplhost';
# Set the timezone format
#putenv(TZ=UTC);
#$TimeFmt = '%B %d, %Y, at %I:%M %p EST';
# Use Clean URLs.
#$EnablePathInfo = 1;
I know the above isn't mandatory, but it would help A LOT to have it.
You could also copy the sample-config.php into /etc/pmwiki/config.php if
you see that the file doesn't exist (and delete it in case of a purge of
course). Best would be to use ucf, but that might be a bit
over-engineered ... I'll leave that choice to you.
Also, have you considered a strategy to package the myriads of modules
and extensions to pmwiki? I do use myself:
- The captcha thing
- The internationalization modules
- The URL approve script
4/ While checking for your watch file, I saw there's a new version
upstream. I understand that the issue is because of me taking too much
time to review your package, but it'd be nice that on your next upload,
you'd be upgrading.
uscan --verbose --report
Newest version on remote site is 2.2.30, local version is 2.2.29
5/ Is that one needed?
I: pmwiki: package-contains-empty-directory usr/share/pmwiki/pub/css/
6/ Instead of your debian/patches, I would suggest to override the
dh_install target and do something like:
find cookbook local scripts wikilib.d pmwiki.php -exec \
install -D -m 0662 {} debian/pmwiki/usr/share/pmwiki/{} \;
and ship your index.php inside the debian folder instead of a patch. Of
course, you'll have to also do that for the docs folder. That way, you'd
get totally rid of the debian/patches folder.
I know I might have tell you to create that Makefile (if that was the
case, sorry for the bad advice), but on the 2nd though, I think it's
better as above, directly in debian/rules.
7/ Last thing, it'd be cool to use a VCS for your packaging. If you use
collab-maint and Git on Alioth, I might well also help for the
packaging, since I think that pmwiki is a cool software and I use it as
well.
Cheers, and thanks a lot for your packaging effort,
Thomas goirand (zigo)
--
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/4e5763b1.2060...@goirand.fr
