RFS: replaceit (#490695)
Dear mentors, I am looking for a sponsor for my package "replaceit", closing ITP #490695. * Package name: replaceit Version : 1.0.0-1.1 Upstream Author : Paul L Daniels <[EMAIL PROTECTED]> * URL : http://pldaniels.com/replaceit/ * License : BSD Section : utils Further description (from upstream): ReplaceIt was written as a quick, light and effective replacement to the combination of sed/awk/grep/head/tail and other such shell utilities, as well as being quicker in startup (at least) than an equivilant Perl solution. ReplaceIt has various rules which can be used to enhance its abilities when negotiating tricky sections of text, whilst searching for the right one to replace, these include [ on same line ] string inclusion dependence, exclusion dependence, pre-existance, post-existance. This is my first Debian package as part of my intent to become a New Maintainer. It appears to be lintian clean but I would appreciate any feedback which would be valuable. The version has been incremented because I added a watch file after initial upload. I have been in touch with upstream and Paul Daniels is happy for it to be included in Debian. I have modified the makefile slightly to comply with policy and written and included a man page. This is a single binary package. It builds these binary packages: replaceit - A quick, light and effective text replacement tool The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/replaceit - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/replaceit/replaceit_1.0.0-1.1.dsc I would be grateful if someone uploaded this package for me and would consider sponsoring me though the new maintainers process. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: replaceit (#490695)
On Sat, Aug 23, 2008 at 10:28:47PM +0300, George Danchev wrote: > I can't figure out why you want to NMU your own package, perhaps there > might > be some reason I can't think of right now or it is just an unintentional > blunder. Could you clarify NMU? > Also, you can use the most recent 3.8.0 standards version, and as I > can see there are no changes needed to the package, but anyway you can check > that with: /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. > I will update to 3.8.0, I hadn't changed that from dh_make. > Sponsoring would be best performed by your Application Manager, but sure in > case s/he is MIA, I will try to review and upload that package for you. At > least it doesn't seem to be beyond my grasp, and I can't promise I would > upload large and complex stuff which I don't personally use and > understand ;-). However, posting to -mentors mailing list is always a better > idea, since you get more peer review. As this is my first package I don't yet have a sponsor, and I understood from the New Maintainers pages that I should already be involved before applying. If this is incorrect should I apply for maintainers status and get into the system first before sending an RFS? Thanks -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: replaceit (#490695)
On Sun, Aug 24, 2008 at 12:28:46AM +0300, George Danchev wrote: > > > Also, you can use the most recent 3.8.0 standards version, and as I > > > can see there are no changes needed to the package, but anyway you can > > > check that with: /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. > > > > I will update to 3.8.0, I hadn't changed that from dh_make. > > I see, lintian is here to warn. It didn't say anything, is it an optional preference? > > > Sponsoring would be best performed by your Application Manager, but sure > > > in case s/he is MIA, I will try to review and upload that package for > > > you. At least it doesn't seem to be beyond my grasp, and I can't promise > > > I would upload large and complex stuff which I don't personally use and > > > understand ;-). However, posting to -mentors mailing list is always a > > > better idea, since you get more peer review. > > > > As this is my first package I don't yet have a sponsor, and I > > understood from the New Maintainers pages that I should already be > > involved before applying. > > You are correct. It is best to be involved before applying. So, correct the > standards version and debian revision and I will sponsor. Excellent, thank you. It is correct now (there were no changed to be made to get to standards version 3.8) and is available at http://mentors.debian.net/debian/pool/main/r/replaceit/replaceit_1.0.0-1.2.dsc > > If this is incorrect should I apply for > > maintainers status and get into the system first before sending an RFS? > > Anyone can send an RFS and gets eventually sponsored, but it is always better > if they intend to enter NM (New Maintainers) queue, pass it successfully and > take responsibility of their packages at some future point. Perhaps I have just confused myself, but http://www.debian.org/devel/join/nm-checklist says this: "For the NM process to be the most efficient, Applicants should have already contributed significantly to Debian. This can be done through packaging, documentation, Quality Assurance, ..." which implies to me that I should already have worked on a few packages and had them sponsored before applying. If I've just got in a muddle do please correct me :-) I really appreciate your help, sorry if these are really newbie questions. Cheers -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: replaceit (#490695)
On Sat, Aug 23, 2008 at 10:59:00PM +0100, Jonathan Wiltshire wrote: > Perhaps I have just confused myself, but > http://www.debian.org/devel/join/nm-checklist says this: > > "For the NM process to be the most efficient, Applicants should have > already contributed significantly to Debian. This can be done through > packaging, documentation, Quality Assurance, ..." > > which implies to me that I should already have worked on a few packages > and had them sponsored before applying. If I've just got in a muddle > do please correct me :-) > I've just read your mail again and realised that's exactly what you said. Sorry! -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: replaceit (#490695)
On Sun, Aug 24, 2008 at 05:16:12AM +0300, George Danchev wrote: > perform build/lint/fix/install/deinstall/fix cycles at will. Using a clean > chrooted system also brings the benefit that unsatisfied build depends are > easily caught, and you are sure that your binaries will not link with any > obscure library files laying around you might happen to have locally > installed (in /usr/local for example). This is just for future reference, you > have nothing to fix now in your package with regard to a clean chroot > environment. I'll investigate cowbuilder, thanks for the tip. > Probably I wasn't clear enough with my previous message, but I now see that I > wrote "1.0.0-2 or 1.0.0-1 in your debian/changelog". So, in a package version > like A.B.C-X.Y, in the second part (the debian revision) `.Y' is reserved > for NMU's, so you want a non-NMU version like A.B.C-X or replaceit_1.0.0-2. It's now correct (I think) and available at http://mentors.debian.net/debian/pool/main/r/replaceit/replaceit_1.0.0-2.dsc. I think I worked out what happened: I don't have the correct email in DEBEMAIL so dch used my local address, and I didn't spot it. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: replaceit (#490695)
On Sun, Aug 24, 2008 at 08:49:21PM +0300, George Danchev wrote: > Okay, uploaded, thanks for your patience. This will go through Debian NEW > queue [1] which will take some time. Cool, thanks :) > > I dared to change your last debian/changelog entry (I hope it is ok with you) > from: > * Incremented version correctly (no longer NMU) > to: > * Incremented version correctly (no longer non-maintainer version) > > since lintian was trying to be too smart, but was wrong to complain for: > > W: replaceit source: changelog-should-not-mention-nmu Fine by me. I agree, the warning is useful in the right context, but not in this case. I've never reached this stage, obviously - what happens to the package now that it's in the new queue? I notice also that it doesn't have my ITP bug number listed under 'Closes', is that something I haven't done correctly? Thanks -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: replaceit (#490695)
On Sun, Aug 24, 2008 at 09:37:01PM +0300, George Danchev wrote: > option to dpkg-buildpackage giving it the first package version found in the > changelog (1.0.0-1) in order to include all the entries in the changes file, > but in fact it appeared to just start from that version on, not including it. > So, we should close that ITP manually after the package gets approved and > enters unstable (sid) via BTS (Bug Tracking System) email interface. So, if > you prefer to gain some BTS experience then please do close it for me, > otherwise I'll do it for you ;-) > No, that's fine. I'll close it when it goes in (presumably I'll get a mail when it does?) I have another package that's almost ready for feedback. Woud you prefer to see it or should I advertise an RFS? Not sure what the protocol is here. Cheers -- Jonathan Wiltshire signature.asc Description: Digital signature
RFS: adtool -- a command-line utility for Active Directory administration
Dear mentors, I have adopted this packge and brought it up to standards 3.8.0.0, and now need a sponsor to check it over and upload for me. As I intend to eventually apply for NM status, any feedback you can give will be appreciated. It was previously maintained by Hilko Bengen and the description reads: "adtool is a unix command line utility for Active Directory administration. Features include user and group creation, deletion, modification, password setting and directory query and search capabilities." The package appears to be lintian clean and is available at: http://mentors.debian.net/debian/pool/main/a/adtool The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/a/adtool/adtool_1.3-4.dsc There are a couple of dependencies that are not strictly neccessary, but I intend to use the BTS for those after upload so that upstream are made aware of them. If this is incorrect please tell me and I will correct them first. Thanks for taking the time to have a look. It is not a huge package so I hope it won't take too long to check over. -- Jonathan Wiltshire signature.asc Description: Digital signature
RFS: copher
Dear mentors, I am looking for a sponsor for my package "copher". It is *very* simplistic and will take you only a few minutes to check, I am sure. All your feedback is appreciated. Copher is a tool for automating the process of a Sourceforge release, by providing parameters and files such as the changelog, release notes etc. It is written in perl. * Package name: copher Version : 0.1.2-1 Upstream Author : Peter Lunicks <[EMAIL PROTECTED]> * URL : http://copher.sourceforge.net/ * License : GPLv2 Section : devel It builds these binary packages: copher - automatically make a SourceForge release The package appears to be lintian clean. The upload would fix these bugs: 492665 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/copher - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/copher/copher_0.1.2-1.dsc Thank you for taking the time to consider sponsoring me. -- Jonathan Wiltshire signature.asc Description: Digital signature
RFS: gxemul -- machine emulator for multiple architectures
Dear mentors, I have adopted this package and I am now looking for a sponsor for version 0.4.6.5-1. It has been orphaned under bug number 482067 and I believe this upload will close it. There are various enhancements including an new upstream release. It appears to be lintian clean. I plan to adopt a number of packages with an eventual view to starting the New Maintainers process, so all your feedback is appreciated even if you don't wish to sponsor directly. It builds these binary packages: gxemul - machine emulator for multiple architectures gxemul-doc - gxemul documentation The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gxemul - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.6.5-1.dsc Thanks. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: gxemul -- machine emulator for multiple architectures
On Mon, Aug 25, 2008 at 09:51:34PM +0300, George Danchev wrote: > The rest of the package looks fine to me. So, complete that, and I will > sponsor. It is corrected and up at http://mentors.debian.net/debian/pool/main/g/gxemul http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.6.5-2.dsc > anyway;-). Do in mind that you might happen to spend significant amounts of > time while dealing with package's regular problems, which includes BTS (bug > tracking system) interaction, discussing possible bugs with your users and > dealing with alone or together with the upstream developers. This package is > complicated enough and I saw that you have prepared two more packages whos > RFS flew by -mentors, so make sure not to exceed your human limits ;-) > Another good idea is working in teams (i.e find co-maintainers) which brings > natural manpower backup and redundancy, as well as additional skills and > expertise. Point taken. There are one or two others on the list that I have an interest in, but that's about it. As you say, I don't want to overdo it. Cheers -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: gxemul -- machine emulator for multiple architectures
On Mon, Aug 25, 2008 at 04:08:09PM -0300, Maximiliano Curia wrote: > > There is a change in the diff file that modifies the source code. Most > probably > an auto-generated file, anyway, try to avoid such a change. > It's not something I've touched, I think it's an artifact of upstream's build process. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: copher
On Mon, Sep 01, 2008 at 07:33:44PM -0500, Raphael Geissert wrote:
>
> Makefile:
> This file is useless, you don't need it, you should drop it.
Removed, all the logic is moved to debian/rules
> debian/watch:
> > http://qa.debian.org/watch/sf.php/copher copher-(.*).tar.gz debian
> Did you know that the first part can be written as http://sf.net/copher ?
I get a 404. I was under the impression that the URL I have used was
required to allow for SF's load-balancing redirections.
> Also note that the unquoted dots after the closing parenthesis is actually
> interpreted as part of the regex and could actually match anything?
Fixed.
> debian/control:
> > Priority: extra
> why?
http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html states:
"Extra: packages that either conflict with others with higher
priorities, are only likely to be useful if you already know what they
are [...]"
Perhaps I'm being a newbie, but this sounds a good fit. One would
probably already know of copher if one was going to use it; should it
be in Optional instead?
> > Architecture: any
> > Depends: libwww-mechanize-perl, ${shlibs:Depends}
> The perl script is architecture-dependent, isn't it?
Set architecture to 'all', removed shlibs placeholder.
> > Copher makes a SourceForge release automatically. It is useful as part
> > of a build and release system.
>
> This doesn't really tell me much about Copher; I am the admin of a project
> at sf.net and that description doesn't tell me it could be useful to me.
>
> > of a build and release system. Support for other GForge-based sites is
> > in development.
>
> SF.net is not 'GForge-based', that sentence should be rephrased.
This originally came from the RFP; I have rewritten it into something
more useful.
> debian/copher.1:
Same here, and removed the manpage boilerplate that I overlooked.
> debian/rules:
> debian/compat:
> debian/control:
> You build-depend on debhelper 7 but use none of its features? you
> should/could use a lower compat level such as 5 instead.
Set to 5. Is there anywhere that details the feature in each
compatibility level for future reference?
> debian/dirs:
> file is useless, remove it
>
> $ xlintian -I -E copher*changes
> W: copher: extra-license-file usr/share/doc/copher/COPYING.gz
> I: copher: package-contains-empty-directory usr/sbin/
Gone.
The updated package can be found at:
http://mentors.debian.net/debian/pool/main/c/copher
Thanks for your time and feedbacki.
--
Jonathan Wiltshire
signature.asc
Description: Digital signature
Re: RFS: copher
On Fri, Sep 05, 2008 at 06:08:14PM +0100, Daniel Watkins wrote: > http://sf.net is expanded to the full SF URL by tools that use watch > files and, I presume, will be updated if SF ever changes its URL schema. Ah, that makes more sense, thanks. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: wallpaper-tray (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Sep 27, 2008 at 08:54:16PM +0200, Guido Loupias wrote: > I just uploaded a new version of the package. Although I didn't change > the version number from the previous version because I figured it > wouldn't really matter since the previous package never went into the > repository. See below for more details. It's good practice to increment your versions for each mentors upload too, so that mentors can easily tell the new version of your package even if it didn't go into the main repository. - -- Jonathan Wiltshire -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjevWIACgkQymvqPtuAC1IhMACfUjGfBYExjX1QXWDhdD1d62FJ lxwAnAyoPJ1rSXecCZeTSfOdZXy22+JB =YnWf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: new upstream of gxemul 0.4.4.6-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am looking for a sponsor for the new version 0.4.6.6-1 of my package "gxemul". This is a minor new upstream version, the packaging has basically not changed. It builds these binary packages: gxemul - machine emulator for multiple architectures gxemul-doc - gxemul documentation The package appears to be lintian clean. The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/g/gxemul - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.6.6-1.dsc I would be glad if someone uploaded this package for me. Thanks - -- Jonathan Wiltshire -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkgXVIACgkQymvqPtuAC1It5ACfef2KU6BoanzBNsKkq+LDZSDZ 5HoAn05KYg0aAVE03+joCrr/MqwmlKkr =WOMS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: copher (2nd try)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package "copher". * Package name: copher Version : 0.1.2-3 Upstream Author : Peter Lunicks <[EMAIL PROTECTED]> * URL : http://copher.sourceforge.net/ * License : GPL Section : devel It builds these binary packages: copher - automatically create and upload a SourceForge release The package appears to be lintian clean. The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/c/copher - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/c/copher/copher_0.1.2-3.dsc I would be glad if someone uploaded this package for me. - -- Jonathan Wiltshire -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkgX/kACgkQymvqPtuAC1IbCwCeI2Nz9AfkcqvA1wnXraUEFgej gNAAmQHRefqeiWInEMeVWZOWVrZq2unB =R/gy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: copher (2nd try)
On Mon, Nov 17, 2008 at 03:33:35PM +0900, Paul Wise wrote:
> Standards-Version doesn't need the final .0, 3.8.0.X versions are compatible.
Removed the tailing .0
> Depends should have ${misc:Depends} in it.
Ah, this fixes a query I had from long ago: I had ${misc:Depends} in
the build dependencies and it broke things, now that it's in Depends
everything is as expected.
What does this substitution get expanded to and by what? Since taking
it out made the package build without errors, I didn't take much notice
of it.
> README.Debian doesn't look especially useful.
Agreed, gone.
> Don't forget to send the manual page upstream if you haven't already.
>
> debian/watch looks broken, please see the uscan manual page for the
> correct syntax for magic sf.net support.
Yep, missed this one again! Fixed now, hopefully that's the end of this
bug.
Thanks for you feedback. The updated package is at
http://mentors.debian.net/debian/pool/main/c/copher/copher_0.1.2-4.dsc
if you'd like to have another check.
Cheers
--
Jonathan Wiltshire
signature.asc
Description: Digital signature
Re: RFS: copher (2nd try)
Uploaded an updated package to http://mentors.debian.net/debian/pool/main/c/copher/copher_0.1.2-4.dsc Thanks in advance for your feedback. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: new upstream of gxemul 0.4.4.6-1
On Mon, Nov 17, 2008 at 08:42:43PM +0200, George Danchev wrote: > * slight regression: dpatch was introduced in that revision, but the > 01_manhyphens_patch.dpatch is not applied during build. Basically you don't > need to call dpatch but include /usr/share/dpatch/dpatch.make > instead and call patch and unpatch targets it provides for you. If in doubt > you can check with poco source package for example and use it as a reference. > > * slight improvement: while we are at it, you ca upgrade to debhelper v5 or > better yet use v7 and its wonderful command sequencer called dh(1) in order > to shorten your debian/rules. I don't insist on v7 though, so use it at your > convenience. I /believe/, after a lot of headaches, that this is done now :) I have taken all the cruft out of debian/rules and replaced it with a configure target and calls to the patch and unpatch targets, and it builds now including the patch. If you could take a look and consider sponsoring, the updated dsc is at: http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.6.6-2.dsc Thanks! -- Jonathan Wiltshire signature.asc Description: Digital signature
Bug reports in Ubuntu
Dear mentors I had a quick look in the list archives but couldn't find an answer, so perhaps you can help. My adopted package gxemul has a bug in Ubuntu[1] (seg fault on command line parameters) which reproduces in the current Debian package. It has been fixed recently in upstream's CVS so I plan to add a patch for the time being, pending an upstream release. 1) is this the right approach or can you suggest better? 2) should I open a similar Debian bug for this in the normal way, or just respond to the Ubuntu bug, or some other course of action? If a seperate bug, should I interact with Ubuntu's at all or leave them to it? What's the protocol in this situation? Thanks -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: new upstream of gxemul 0.4.4.6-1
On Mon, Nov 24, 2008 at 07:11:02AM +0200, George Danchev wrote: > Ah, causing headaches was not my intention, indeed ;-) so I'd generally like > to know about the troubles you have faced. Mostly that it was supposed to be the weekend :-) but I struggled to find a good, clear tutorial for converting an existing debian/rules with patches (though Sandro's helped a lot). If there isn't one already I will try to find time to write one. >Now, the package looks well done to me. Thanks. I'm aware that checkins upstream are quite frequent so I'll keep an eye on it. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: Bug reports in Ubuntu
On Mon, Nov 24, 2008 at 06:13:23PM +0900, Paul Wise wrote: > Sounds fine. Be sure to prepare an upload for testing-proposed-updates > if you want to add the patch to lenny and the release team are likely > to approve the patch, since your package is not in sync between lenny > & sid. Can you advise further or point me to somewhere to find out more? I've never used testing-proposed-updates, but it would be a good thing to learn about. Cheers -- Jonathan Wiltshire signature.asc Description: Digital signature
RFS: gxemul segfault bugfix
Dear mentors, I am seeking a sponsor for a bugfix in gxemul, George Danchev kindly sposored last time. This is a patch taken from upstream's CVS pending it being included in a release, and fixes a segmentation fault if gxemul is started with invalid parameters. Change: added patch 05_segfault_params.dpatch and included it in 00list. Closes: LP #301041 Available from: http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.6.6-3.dsc I will package seperately for testing-proposed-updates since lenny and sid are out of sync. My upload last night is still building, so I don't know if that causes any problems with uploading this fix. Thank you in advance. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: Bug reports in Ubuntu
On Mon, Nov 24, 2008 at 08:07:45PM +0900, Paul Wise wrote: > http://www.debian.org/doc/developers-reference/pkgs.html#t-p-u [1] > http://lists.debian.org/debian-devel-announce/2008/09/msg0.html [2] Ok, I understand the theory according to [1]. But [2] states that bugs should be at severity critical, grave or serious, and I'm not convinced this bug merits being above normal, in the context of [3]. It doesn't really have a major effect on usability, it's just really ugly. However, [2] also says that uploads will also be considered for bugs in packages of priority optional or extra when this can be done via unstable. Can you explain this a little more clearly? I don't /think/ it applies, because my testing and unstable packages are dissimilar, but it's not easy to tell. Do you think it is severe enough to be put forward for lenny? Cheers [3] http://www.debian.org/Bugs/Developer#severities -- Jonathan Wiltshire signature.asc Description: Digital signature
RFS: webcpp (adoption, bugfix and standards/dh7)
Dear mentors, I am seeking a sponsor for my package webcpp. This is an adoption of Roberto Sanchez's package and includes these changes: * patch that has been in BTS for a while * standards version 3.8.0 * debhelper v7 and all that it entails The upload fixes these bugs: 493131, 483485. It is lintian clean except for a warning 'ancient-libtool admin/ltconfig'. The package dsc can be found at http://mentors.debian.net/debian/pool/main/w/webcpp/webcpp_0.8.4-6.dsc Even if you are unable to sponsor, I would appreciate your feedback as I'm trying to learn to produce really solid packages. Thanks in advance. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: webcpp (adoption, bugfix and standards/dh7)
On Wed, Nov 26, 2008 at 11:00:52AM +0100, Sandro Tosi wrote: > debian/compat > - has 5 while you declare versioned build-dep on debhelper >=7 > debian/rules > - don't export DH_VERBOSE > - you can remove the commented header Fixed > - no need to "[ ! -f configure-stamp ] || ..." since -stamp targets > are only executed is -stamp file is missing > - -stamp file are sually touched with "touch $@" (less spelling > problem and chars to digit ;) ) Aha, still learning about dh7! > - instead of "ln -s" you can use dh_link and its file to create symlinks > - you may "play" a bit with Makefile (patching it) instead of install > doc.html in a dir and then move it into Debian right place I've patched it in 05_makefile_docdir > debian/README.source > - it's missing, but it's needed by 3.8.0, to explain that you're using > a patch system. Ok, written and included. The dsc is at: http://mentors.debian.net/debian/pool/main/w/webcpp/webcpp_0.8.4-7.dsc Thanks for your comments. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: webcpp (adoption, bugfix and standards/dh7)
Hi Sandro On Wed, Nov 26, 2008 at 05:33:57PM +0100, Sandro Tosi wrote: > ehm, I personally like to have all the changes in the revision = > "current revision in debian"+1, so -6, and you have the opportunity to > "fix" this since your package FTBFS if build twice in a row. what > does this mean? take your source pacakge and uncompress it, then exec > "debuild -us -uc && debuild -us -uc", the second execution will fail > with > (snip) Hmm, I was encouraged before to ensure each upload is unique, but I guess it's preference. (A direct upload to ftp-master requires uniqueness, doesn't it?) I think it failed to build twice in a row because the paches were removed before distclean was called, but correct me if I'm wrong. I've changed it in debian/rules and it seems to be ok now. Diff attached. Combined changelog entries and updated the timestamp. Uploaded to http://mentors.debian.net/debian/pool/main/w/webcpp/webcpp_0.8.4-6.dsc, if you have chance to take a look. Cheers -- Jonathan Wiltshire --- rules~ 2008-11-26 20:21:13.0 + +++ rules 2008-11-26 19:40:18.0 + @@ -31,7 +31,8 @@ dh build touch $@ -clean: unpatch +distclean: unpatch +clean: -rm -f config.sub config.guess [ ! -f Makefile ] || $(MAKE) distclean dh $@ signature.asc Description: Digital signature
Re: RFS: webcpp (adoption, bugfix and standards/dh7)
On Thu, Nov 27, 2008 at 04:59:56PM +0100, Sandro Tosi wrote: > When you upload a package to ftp-master, there are 2 possibilities, > it's ACCEPTED (hence included in the debian archive) or it's REJECTED. > In the latter case, you can reupload the same revision, since from > archice POV that revision never existed, so it's ok. Ok, that makes sense :) > mh, distclean is not a target of debian/rules; what I suggest is using > something like > > clean: clean-patched unpatch > clean-patched: patch-stamp > > dh clean Actually that's exactly what I did earlier while thinking about this anyway; also stopped it from configuring twice during build. So uploaded to the same location on mentors for your review. > After this fast fix, all should be ok; sorry if it takes another > iteration, because I make it not clear enough from the beginning. It's fine, I'd rather take the time and learn much more this way than just pushing it straight to archive and not doing. Cheers Jonathan -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: webcpp (adoption, bugfix and standards/dh7)
> there is a config.log file left in diff.gz, please remove it in the > next upload (probably before the 'rm' in config), but apart from that > the package looks fine so I uploaded it. I spotted that in lintian, but as far as I could find out it's normal if the file gets removed in the clean target - does that sound right? -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: webcpp (adoption, bugfix and standards/dh7)
> No, it's not normal: if that files was removed in clean target, then > it would never have come out in .diff.gz; moreover, config.log is not > removed in clean, but in build-stamp target. My bad; I'll fix it in next package. Thanks for the upload! > > -- > Sandro Tosi (aka morph, Morpheus, matrixhasu) > My website: http://matrixhasu.altervista.org/ > Me at Debian: http://wiki.debian.org/SandroTosi > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: webcpp (adoption, bugfix and standards/dh7)
Hi Sandro > >> there is a config.log file left in diff.gz, please remove it in the > >> next upload (probably before the 'rm' in config), but apart from that > >> the package looks fine so I uploaded it. Fixed this in 0.8.4-7, if you have a moment perhaps you could take a look? (there's no hurry) Change: move the rm command to clean instead of configure. dsc: http://mentors.debian.net/debian/pool/main/w/webcpp/webcpp_0.8.4-7.dsc Cheers Jonathan -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: gxemul segfault bugfix
On Sat, Nov 29, 2008 at 02:32:22PM +, James Westby wrote: > Just to note that the above doesn't quite match the syntax required > to auto-close the bug, it needs a colon after the "LP". For those that > read perl the expression is In the changelog the syntax was correct and the bug has been closed. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: copher (2nd try)
Hi Paul
On Sun, Nov 23, 2008 at 12:01:43PM +0900, Paul Wise wrote:
> It is best not to speculate about future features in the package
> description, please remove the last line.
>
> Uhhh, Depends: is a header for binary packages, not source packages.
> You put ${misc:Depends} in the wrong section:
Done, and misc:Depends - yeh, it was late :)
> The upstream code does not contain any copyright information, please
> ask upstream to fix it (add add your manual page at the same time).
>
> Please also ask upstream to add the standard GPL license grant to the
> script so that there can be no confusion about which version of the
> GPL is to be used.
I spoke to Peter Lunix and he has done both these in CVS, and I've sent
him my man page too. He's not made a release for them yet though,
because there is some other stuff he wants to do first, so I have
checked out the CVS and (I think correctly) compressed it into an
orig.tar.gz, and build the package around that with an epoch.
Also took the opportunity to do some cleaning up, use dh7, etc, so it's
changed quite a bit but I hope for the better. Would you like a
combined changelog or one entry per attempt?
The dsc is at
http://mentors.debian.net/debian/pool/main/c/copher/copher_0.1.2+20081201.dsc,
if there are other points to fix just let me know.
Cheers
Jonathan
>
> --
> bye,
> pabs
>
--
Jonathan Wiltshire
signature.asc
Description: Digital signature
Re: RFS: copher (2nd try)
On Tue, Dec 02, 2008 at 02:07:24PM +0900, Paul Wise wrote: > A few comments: > > Your package version does not include a Debian revision number. My bad, fixed. > I would use a phrase other than 'project management' in the > descriptions, perhaps 'release management'? > > debian/copyright: You might want to replace "GPL, see above" with "GNU > General Public License version 2 or later, see above". > copher.docs should probably be renamed to copher.examples. I agree, also fixed. > I doubt you need the configure target in debian/rules. Odd, pdebuild whinged at me when I took it out before, but doesn't now. Must have been something else that changed since. > debian/rules doesn't seem to have a .PHONY line, why is that? An oversight. > You got the architecture wrong in debian/control. You want all rather than > any. Fixed. Uploaded to http://mentors.debian.net/debian/pool/main/c/copher/copher_0.1.2+20081201-1.dsc if you have a chance to look. Cheers Jonathan > > -- > bye, > pabs > -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: copher (2nd try)
On Tue, Dec 02, 2008 at 08:16:49PM +0900, Paul Wise wrote: > I just noticed that releaseforge already exists in Debian. From the > description it sounds like it does the same thing as copher. Is it > still nessecary to add copher to Debian? Copher is command line base rather than a GUI, is platform independent, and works with other -forge-like sites (ex. Rubyforge) and protocols. So I think it's not a replacement, but complimentary to releaseforge. > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: copher (2nd try)
On Wed, Dec 03, 2008 at 07:06:54PM +0900, Paul Wise wrote: > Package uploaded. > > Please mail this list for future uploads and I will upload if I can. Excellent, cheers :-) Jonathan -- Jonathan Wiltshire signature.asc Description: Digital signature
RFS: whohas
Dear mentors, I am looking for a sponsor for my package "whohas". * Package name: whohas Version : 0.21-1 Upstream Author : Philipp Wesche <[EMAIL PROTECTED]> * URL : http://www.philippwesche.org/200811/whohas/intro.html * License : GPL Section : utils It builds these binary packages: whohas - query multiple distributions' package archives The package appears to be lintian clean and would fix 507938 (ITP) whohas is a command line tool for finding similar packages in many distributions. It is written in Perl and multi-threaded for speed, though this can be disabled as a parameter. I believe it would aid developers finding similar packages and tracing their packages through other archives (for example Ubuntu, FreeBSD) and for users finding similar packages on perhaps other distributions they manage. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/w/whohas - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/w/whohas/whohas_0.21-1.dsc Even if you are unable to sponsor I would appreciate a review. Thanks in advance -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: whohas
On Tue, Dec 09, 2008 at 12:29:21PM +0900, Paul Wise wrote:
> Why do you have Vcs-Browser, but not Vcs-Git?
I wasn't happy that git:// was working properly on that machine, but it
seems to be fine so included the field.
> ${shlibs:Depends} isn't needed because whohas is a perl script.
Removed.
> For the manual page you might want to point users at
> intro.html/intro.txt in a "SEE ALSO" section.
>
> The "FILES" section in the manual page should talk about ~/.whohas
> rather than the script filename.
Added both these and (hopefully) described them nicely.
> Will upload once these issues are fixed.
Uploaded to
http://mentors.debian.net/debian/pool/main/w/whohas/whohas_0.21-2.dsc
Cheers
--
Jonathan Wiltshire
signature.asc
Description: Digital signature
Re: RFS: whohas
On Tue, Dec 09, 2008 at 07:37:44PM +0900, Paul Wise wrote: > Uploaded. Thanks! > In the next upload, please remove the duplicate space in the last > paragraph of the description. Will do. > Why was your orig.tar.gz not the same as upstream's? Please always use > the upstream tarball unless it has been repacked due to DFSG/other > issues. I used the upstream tarball instead of the one you uploaded to > mentors. Odd, I haven't intentionally touched it. I'll diff them but could it be cruft from git-buildpackage? -- Jonathan Wiltshire signature.asc Description: Digital signature
RFS: replaceit
Dear mentors, I am seeking a sponsor for my updated package replaceit (George Danchev kindly sponsored previously). This upload: * fixes bug 506767, and also * migrated into a git repository with public access * makes proper use of debhelper 7. Even if you're unable to sponsor, a review would be appreciated. The dsc file can be found at http://mentors.debian.net/debian/pool/main/r/replaceit/replaceit_1.0.0-4.dsc Thanks in advance, -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: replaceit
On Tue, Dec 09, 2008 at 06:33:24PM +0200, George Danchev wrote: > Uploaded Thanks, that was quick! > One minor thing I'm not too concerned about is that diff.gz directly patches > the Makefile [1]. In fact the change is so innocent that using a patch system > could be considered an overkill, but anyway you could: This was I think the first package I ever wrote and I remember being mislead by the New Maintainer's Guide [1] where source modification is encouraged, so I expect that's where it's come from. I'll patch it properly in due course but I'm not inclined to hurry :-) [1] http://www.debian.org/doc/maint-guide/ch-modify.en.html > as could be seen at http://patch-tracking.debian.net/package/replaceit > /* that is an extremely great resource ! */ That is very helpful - wish I'd know about that before. Thanks for your sponsorship -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
RFS: webcpp
Dear mentors, I am seeking a sponsor for my updated package webcpp (Sandro Tosi kindly sponsored previously). This upload adds the VCS-* fields to debian/control and fixes some minor lintian warnings. The dsc is at http://mentors.debian.net/debian/pool/main/w/webcpp/webcpp_0.8.4-8.dsc If you're unable to sponsor I would still appreciate a review. Thanks in advance -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: Uploads to experimental instead of unstable (was RFS: vbetool (QA upload))
On Thu, Dec 11, 2008 at 10:08:32AM +, Neil Williams wrote: > > Unstable has had to be all-but-closed as a technical step to solve a > social problem. Uploads should not be targeted at unstable simply I was not aware of this, where can I find more info about it? -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: Someone to 'proofread' a .deb please
On Thu, Dec 11, 2008 at 09:23:53PM +, Andy Hawkins wrote: > I'll look at getting it packaged up tomorrow and uploaded to 'mentors'. Is > the request for sponsorship automatic? Or is there an 'approved' format? You need to file an Intent to Package [1] if you haven't already. Then when you upload to mentors.d.n, you have the opportunity to log in and get a template Request for Sponsorship (RFS) which you can post to this list. If a DD thinks it worthy, they will help you get it into proper shape and then upload it for you. [1] http://www.debian.org/devel/wnpp/#l1 Note: the template is just that - you need to flesh it out a lot. Your RFS is an advert to prospective sponsors, so you should try to capture their interest. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: webcpp
On Thu, Dec 11, 2008 at 04:39:04PM -0600, Raphael Geissert wrote: > The only reason why I would recommend to wait is because the package currently > in sid should probably be unblocked. Then the new upload could be made. > OR > The new package could be uploaded and the RT contacted so that it gets > unblocked > once the 10 days delay is over. In this case should I apply for an unblock to allow one or the other into lenny? I hadn't thought it major enough but I'm not experienced in this bit, would appreciate your guidance. > Cheers, > -- > Raphael Geissert - Debian Maintainer > www.debian.org - get.debian.net > > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: webcpp
On Thu, Dec 11, 2008 at 11:55:35PM +0100, Cyril Brulebois wrote: > No need to generate buildd, mirror, and upgrade noise only to fix some > lintian warnings with no real bug IMHO. FWIW the version curently in sid fixes a fairly nasty bug, but it doesn't cause data loss or anything so I don't know if it should qualify as an RC bug. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
RFS: backintime (new)
Dear mentors, I am looking for a sponsor for my package 'backintime', a simple backup/snapshot system for GNOME. This is a new package for unstable. The long description: Back In Time is a GNOME front-end to rsync, diff and cron for the purpose of taking snapshots and backups of specified folders. It minimizes disk space use by taking a snapshot only if the directory has been changed, and hard links for unmodified files if it has. The user can schedule regular backups into cron, and can integrate Back In Time with Nautilus for context menus. This upload would close ITP bug #508407 and the .dsc is at http://mentors.debian.net/debian/pool/main/b/backintime/backintime_0.8.16-1.dsc In particular I'd appreciate feedback on the copyright file, which I think I have written to the new proposed specification - but it's the first time I've done this. As usual even if you can't upload I'd appreciate any review. Thanks in advance -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: flactag
On Tue, Dec 16, 2008 at 12:47:44PM +, Andy Hawkins wrote: > * Package name: flactag > Version : 1.1-1 > Upstream Author : Andy Hawkins > * URL : http://software.gently.org.uk/flactag > * License : GPL > Section : sound IANADD and can't upload for you, but some things to consider: debian/changelog: * you can't target stable, you probably want unstable or perhaps experimental * have you split the changelog entry into two lines for a reason? Don't say bug#, just "Closes: #n" with your bug number debian/control: * if you are standards version 3.8.0, you need a Homepage field * a full stop at the end of your description would be nice :-) Your main binary doesn't have a man page. debian/dirs: * the only directory in here is created by the Makefile anyway, so get rid of the file debian/docs: * you already turn flactag.1.txt into a man page and install it in your Makefile, so you don't need this. debian/flactag-doc.*: * you don't have a binary package by this name, get rid of these too debian/README.Debian: * empty file, get it of it You might consider using debhelper 7 and its beautiful rules automation. Since your upstream build process is very straightforward, you rules file might look like this: #!/usr/bin/make -f %: dh $@ See [1] for more detail. Lose the comments and cruft while you're at it, to make it easier to review. debian/copyright: * you need to acknowledge copyrights in base64.* * most of your files are LGPL, with the exception of flactag.1.txt, is there any reason for this? You need to mention the difference in license. * it's a lot easier if the packaging is licensed the same way as upstream (LGPL, presumably, though your ITP claims GPL.) You need a debian/watch file to comply with policy. It's used by uscan [2]. Good start, have a go at fixing these and then upload to mentors again. Some sponsors prefer you to increment your version every review [3], some prefer you to increment for an actual archive upload. For now I would increment, you can always squash them down later if your sponsor prefers it. [1] http://manpages.ubuntu.com/manpages/intrepid/man1/dh.html [2] man uscan [3] dch -i -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: flactag
On Tue, Dec 16, 2008 at 03:26:10PM +, Jonathan Wiltshire wrote: > Your main binary doesn't have a man page. I meant to remove that line, sorry. It does. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: flactag
On Tue, Dec 16, 2008 at 04:08:27PM +, Andy Hawkins wrote: > > Your main binary doesn't have a man page. > > Umm...it certainly should have! You mention it below. Yeh, I botched that. Sorry. > > debian/copyright: > > * you need to acknowledge copyrights in base64.* > > Ok. I think I've done this, not entirely sure on what the 'style' is though. > Can you give any references? What you've already got is OK, you just need to repeat the License section for each type of license, including the standard grant header like at the bottom of ./COPYING, and the files that the section applies to. See [1] for the policy, but it's a free-form file basically. There is a current proposal to make this machine-readable, so you might want to make the effort with that now and not rewrite it later, you should just be able to tweak it. See [2]. [1] http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile [2] http://wiki.debian.org/Proposals/CopyrightFormat > > You need a debian/watch file to comply with policy. It's used by uscan [2]. > > Done, but I'm not sure it'll work as I doubt the web server allows for > directory listings. Use the example in uscan's manpage uscan(1) for "This is a variant HTTP format which allows direct specification of the homepage". This gets the homepage you specify and screen-scrapes it for the pattern specified to find the download location. > I'm about to upload a new version with the version number incremented. I'll > send another RFS for that. You probably don't need to bother with a whole RFS, just reply to the list with the location of your uploaded files. It keeps the discussion threaded so potential sponsors can see how your package has progressed. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: ganttpv
On Wed, Dec 17, 2008 at 05:12:38PM -0700, Brian C. Christensen wrote: > I am looking for a sponsor for my package "ganttpv". > > * Package name: ganttpv > Version : 0.11a-1 > Upstream Author : Brian C. Christensen > * URL : http://www.pureviolet.net/ganttpv/ > * License : GPL version 2 > Section : office IANADD and can't upload for you, but some review: debian/changelog: two problems - set your real name, not 'user', and replace # with the bug number of your ITP. Take out the boilerplate text between '<>'. This appears to be a debian-native package (is it?) because the debian directory is included in the upstream source, so you should drop the debian revision from your version number to just leave ganttpv-0.11a (no -1). 'office' is not a valid section, you will be targetting sid so choose a section from the list at [1]. [1] http://packages.debian.org/sid/ debian/control: you should be working to standards verion 3.8.0, and all that it entails. See /usr/share/doc/debian-policy/upgrading-checklist.txt. Remove the 1 extra space at the beginning of each line of the long description. debian/copyright: you need to specify your name and a valid URL to download the original source from. Remove the boilerplate text that is there to tell you what you should be putting in. debian/docs: if you don't intend to put anything in this, remove it. debian/rules: take out the sample cruft and commented out line to make it easier to read. You can move probably most of your install rules into debian/dirs and debian/ganttpv.install, see dh_install's man page for more information. The readme and documentation stuff can happen in debian/docs instead, and then your rules file is much neater and simpler. In fact, you could simplify it even further using debhelper version 7 [2]. [2] http://manpages.ubuntu.com/manpages/intrepid/man1/dh.html There is no manual page for usr/bin/ganttpv, write one and include it. Remove in upstream the .DS_STORE. rubbish that has been left over by OSX. Lintian returns many warnings and an error about some of the upstream source. Review these and correct them. What's the difference between ganttpv and pureviolet in some of the installation paths? Unless there's a good reason you should probably merge them, it will help users find the right documentation for example when they go looking for it. I suggest you just install to usr/share/doc/ganttpv and usr/share/ganttpv respectively. Your _how_to_build files etc and your readme.txt should be usr/share/doc/*, not usr/share/pureviolet/ganttpv. You _really_ _really_ shouldn't be installing files like 'debian mentor login and password' and 'good build ready to go'. Have a look at fixing these and upload again to mentors. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: gxemul segfault bugfix
Hi George On Mon, Nov 24, 2008 at 09:31:27PM +0200, George Danchev wrote: > > I will package seperately for testing-proposed-updates since lenny and > > sid are out of sync. > > I'll be offline next 48-72 hours (unexpected mountaineering ;) and I would be > thankful if anyone takes care of uploading package to t-p-u, otherwise I will > upload it once get back. Meantime, could you please ask Debian Release Team > (debian-release at lists.debian.org) for approval showing them the debdiff > for the package found in lenny ? As I see it, if in doubt pointers given by > Pabs should help, otherwise please ask for help ;-) Release have approved the debdiff and asked for the upload; it's on mentors at [1] if you have a chance. Cheers :-) [1] http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.6.3-1+lenny1.dsc -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: gxemul segfault bugfix
On Thu, Dec 18, 2008 at 12:31:12PM +0100, Cyril Brulebois wrote: > I can do the upload if you like, unless you have a preference for > George's doing it. Ping on IRC is OK too. No problem by me :-) Thanks! -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: gxemul segfault bugfix
On Thu, Dec 18, 2008 at 04:21:22PM +0100, Cyril Brulebois wrote: > Uploaded as is. I'm assuming you know about lintian and possible > enhancements for this package (and that you already fixed that in > unstable), and that you chose the minimalist approach for this tpu > upload. :) Exactly, unstable is in much better shape. Release team are aware that this one throws nasty lintian stuff out :-) -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: php-nexista
On Sun, Dec 21, 2008 at 05:42:52PM -0500, Albert Lash wrote: > I've just uploaded the latest version (0.2.4) of php-nexista, a sponsor > would be great! Any feedback would be appreciated as well. How about a link to the dsc? > This packaging was done with dh-make-php, which is a terrific tool. I > originally made a pear package, so making a debian package was a piece of > cake. Is this a new package needing a new sponsor or an updated package, in which case asking your original sponsor first is good manners? -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: php-nexista
On Sun, Dec 21, 2008 at 05:42:52PM -0500, Albert Lash wrote: > I've just uploaded the latest version (0.2.4) of php-nexista, a sponsor > would be great! Any feedback would be appreciated as well. IANADD and can't upload for you, but I can give you some feedback to get it into shape for a sponsor. At the moment there are some severe problems with it: You have three lintian warnings because you haven't used your full name as the maintainer and in the changelog, and because your tag line in the changelog doesn't match your name and email in your debian/control file. You haven't specified your ITP bug number in debian/changelog. debian/control: you should be working to standards version 3.8.0. See [1] for a checklist. You should use your full name in debian/copyright (just as if you were making a legal assertion to it). debian/README.Debian: again, use your full name. debian/rules: get rid of comment cruft, like the fact that this is a sample script. Your watch file doesn't work [2]. These are fundamental problems and need fixing before a sponsor will consider your package. If you need help, you're welcome to ask for it. [1] /usr/share/doc/debian-policy/upgrading-checklist.txt [2] man uscan -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: backintime (new)
Dear mentors, I am still seeking a sponsor for backintime, but in the meantime I have also updated to the new upstream version. You can find the new dsc at [1], all the other details are as in my original mail. Thanks in advance. [1] http://mentors.debian.net/debian/pool/main/b/backintime/backintime_0.8.18-2.dsc -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: furl
On Fri, Dec 26, 2008 at 11:29:29AM -0500, Weboide wrote: > > I am looking for a sponsor for my package "furl". > IANADD and can't upload for you, sorry. But some comments for your review: In your packaging you have a compat level of 7 but don't use debhelper 7 to its potential; you should take as much cruft out of debian/rules as possible to make it easy for sponsors to review your package and dh7 helps enourmously with this. The example comments and other stuff can come out too to make it easy to read. There are three lintian warnings for you to clean up: W: furl: binary-without-manpage usr/bin/furl - you can fix this with a debian/manpages file W: furl: copyright-lists-upstream-authors-with-dh_make-boilerplate - make it either "Upstream Author:" or "Upstream Authors:" W: furl: copyright-has-url-from-dh_make-boilerplate - replace the example url with a real one It's not clear why you remove config.sub and config.guess from upstream's source during clean, and copy them during configure. If there's a good reason, you should probably document it in debian/README.Debian. Your clean target does not remove all stamp files, so a subsequent build does not get a reconfigure. If you were to run a build, then change your configure target, and then build again, you won't see the changes second time around. If you were to use debhelper 7 to its potential, you wouldn't have to worry about such things. More fundamentally: What does furl do that other packages can't? We already have curl, lynx, wget and even telnet can be used to dump headers. Can you justify having this package in the archive? If you can, and you iron out these few wrinkles in your otherwise good package, I'm sure a sponsor will be along soon to upload for you. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: furl
On Fri, Dec 26, 2008 at 10:37:37PM +, Neil Williams wrote: > > What if not? They stay open till someone else > > tries to package it and gets rejected? > > If there is no good reason to turn an RFP into an ITP and thence into > an upload, there is no reason to leave the RFP open. I think perhaps the question was as much 'who should check the list and close useless ones', and whilst there isn't neccessarily anyone who _should_ be doing it, there's no reason prospective developers _can't_ do it. Just make sure you annotate your closure with some reasoning, so that the requestor doesn't just re-open the RFP. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: Re: RFS: furl
On Sat, Dec 27, 2008 at 09:03:36AM -0500, Weboide wrote: > Thanks everyone for your replies, this helped me understand more about > the maintainer job. I will pay more attention to total duplicate > programs before maintaining them. > I'll stop maintaining furl. If it's much consolation your packaging was basically sound, just a few bits you need to address. So hopefully you have something useful for next time. You could still use your package yourself (dpkg -i <.deb>), it just isn't a cadidate for the general archive. Next time it is wise to retitle your chosen RFP into an ITP (intent to package), which means developers can give you some immediate feedback about its suitability before you even start work. I hope this hasn't put you off packaging something else instead! -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
RFS: adtool (adoption)
Dear mentors, I am seeking a sponsor for my adoption of the package 'adtool' (1.3-2). adtool is a command line tool for administering Active Directory ldap databases. This upload closes #465678 and includes packaging with debhelper 7 and standards version 3.8.0. The dsc can be found at: http://mentors.debian.net/debian/pool/main/a/adtool/adtool_1.3-2.dsc Thanks in advance, -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: adtool (adoption)
On Sat, Dec 27, 2008 at 07:19:08PM +0100, Cyril Brulebois wrote:
> So, here it goes:
> - there were some changes to upstream sources in the previous revision,
>they went away but you're not mentioning it anywhere. Did you lost
>them or did you trash them on purpose?
> | $ lsdiff -z ../adtool_1.3-1.diff.gz|grep -v /debian/|grep -v config
> | adtool-1.3/src/tools/adtool.c
> | adtool-1.3/src/etc/adtool.cfg.dist
> | adtool-1.3/src/lib/active_directory.c
> - config.{guess,sub} are no longer updated during the build, I suggest
>you copy them from the autotools-dev package, before the build, and
>trash them in the clean target. Note that I'm not familiar with dh 7
>yet, but maybe there's a nice way to do that.
> - debian/dirs is only needed when the build system doesn't create those
>directories, and that's almost never needed when autotools are used.
Ok, I'll address those now - would you like a version bump?
> - not directly related to your packaging, it looks like CSS are missing
>on your gitweb.
It's the stock debian package, so I'll look into that when I have time
:-)
Cheers
--
Jonathan Wiltshire
PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
Sending of encrypted mail is encouraged
signature.asc
Description: Digital signature
Re: RFS: adtool (adoption)
On Sat, Dec 27, 2008 at 07:19:08PM +0100, Cyril Brulebois wrote:
> So, here it goes:
> - there were some changes to upstream sources in the previous revision,
>they went away but you're not mentioning it anywhere. Did you lost
>them or did you trash them on purpose?
I've used a clean source because there were previously direct changes,
which I'm not a fan of:
> | $ lsdiff -z ../adtool_1.3-1.diff.gz|grep -v /debian/|grep -v config
> | adtool-1.3/src/tools/adtool.c
For some unknown reason, the version number in this was directly changed
to 1.2, I think probably unintentionally. So clean source fixes this.
> | adtool-1.3/src/etc/adtool.cfg.dist
As in 1.3-1 it is moved to etc/adtool.cfg during installation
> | adtool-1.3/src/lib/active_directory.c
My fault. I had moved the fix that was included directly into a patch,
but then didn't include the patch.
> - config.{guess,sub} are no longer updated during the build, I suggest
>you copy them from the autotools-dev package, before the build, and
>trash them in the clean target. Note that I'm not familiar with dh 7
>yet, but maybe there's a nice way to do that.
They are now :-) I don't know if there is a particularly dh7y way of
doing this, but I'm doing it as you suggest.
> - debian/dirs is only needed when the build system doesn't create those
>directories, and that's almost never needed when autotools are used.
Gone
Same package version is on mentors, if you've time to take a look.
Cheers
--
Jonathan Wiltshire
PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
Sending of encrypted mail is encouraged
signature.asc
Description: Digital signature
RFS: whohas (bug fixes)
Hi Paul (and mentors) I've uploaded whohas/0.21-3 to m.d.n which has patches to close bugs 5099975, 510019 and 509981. They have gone upstream for his next release. If you have a moment to take a look and upload sometime I'd appreciate it. The dsc is at http://mentors.debian.net/debian/pool/main/w/whohas/whohas_0.21-3.dsc Cheers -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: whohas (bug fixes)
On Tue, Dec 30, 2008 at 10:59:44AM +0900, Paul Wise wrote:
>
> Next time, please depend on ${DPATCH_STAMPFN} instead of patch-stamp
> in debian/rules.
Done.
> For the manual page change, once the manual page is accepted upstream,
> I would suggest a sed command in debian/rules install or binary rather
> than a patch. The file in question will be uncompressed on most
> systems and compressed on Debian, so upstream's manual page should
> just refer to uncompressed intro.txt and Debian should modify it at
> install time. See the nsis package for an (ugly) example of how to do
> this. This way you won't have to refresh the patch every time upstream
> modifies the manual page around the change.
That makes sense; I'll set it up once the manual goes into upstream.
> In future, it is a good idea to document the status of patches
> upstream in the patch header/description.
Done for all existing and new patches.
> PS: I prefer not to be CCed on RFS mails. If have time I'll upload, if
> not someone else will.
Ok, sorry for the noise. I wasn't sure how closely you were watching
-mentors.
I've uploaded 0.21-4 to m.d.n which closes bugs 510189, 510231, 510259,
510152 and 510203. If you've time to take a look and upload that would
be great, I've also sent all the bugs and patches upstream.
I wondered, with this many bugs opened so soon, if whohas wouldn't be
better suited in experimental, but then again most of them have been
because of incorrect urls in the various package searchers, so perhaps
not. Do you have any thoughts?
TIA.
Jonathan
--
Jonathan Wiltshire
PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
Sending of encrypted mail is encouraged
signature.asc
Description: Digital signature
RFS: gxemul (new upstream)
Hi George (and others) gxemul/0.4.7-1 is a new upstream, and I've also taken the opportunity to fix some minor lintian warnings and improve the packaging. It's now lintian clean including info tags and builds nicely in a chroot. If you have time to take a look that would be great, but there's no hurry. The dsc is at http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.7-1.dsc Cheers Jonathan -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: gxemul (new upstream)
On Sat, Jan 03, 2009 at 09:46:55AM +0200, George Danchev wrote: > > I just saw a few minor leftovers you probably want to correct: > > * compat reads 4, while control claims dh 7. Didn't spot that one, fixed. > * README.Debian could be dropped, it talks about gxemul-doc, while > control:gxemul has it listed in recommends, which will do the job. Ok, dropped it. > * if you push 01_manhyphens_patch.dpatch upstream, you can further drop > dpatch It's gone upstream, but hasn't gone into the source yet. But when it does, it will indeed be nice to lose dpatch now it has done its job :-) I've also now published the git repository and added Vcs-* fields to debian/control. Uploaded as before (let me know if you'd prefer a version bump). Thanks for the quick reply! Jonathan -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
RFS: rednotebook (NEW)
Dear mentors, I am seeking a sponsor for my package rednotebook, a daily journal with calendar, templates and keyword searching. Version:0.4.0 Upstream author:Jendrik Seipp URL:http://rednotebook.sf.net/ License:GPLv2 Language: Python The full description reads: RedNotebook is a graphical diary and journal to keep track of notes and thoughts throughout the day. It includes a calendar navigation, customisable templates for each day, and a keywork search and cloud. This upload closes ITP bug 507939. I believe the package is in good shape (it is certainly lintian clean) and is not complex, so even if you are unable to upload I would appreciate any comments. It includes a simple man page that I have sent upstream already. The dsc is available on mentors.d.n at: http://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_0.4.0-1.dsc Thanks in advance, -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: whohas (bug fixes)
Hi Paul On Wed, Dec 31, 2008 at 11:51:26AM +0900, Paul Wise wrote: > It might be a good idea to allow some kind of config file to override > the URLs/regexes, this would be useful for when the external websites > change and the package has not been updated yet. Could you suggest > this upstream? Yes, it had already occurred to me and I'll suggest it to Philipp upstream. > I'd like to wait a few more days before uploading - see how many more > bugs testers can shake out. If there are no more changes by Sunday, > I'll upload then. I've added another patch to the version on m.d.n under the same number, but thankfully it's been much quieter the last few days :-) Cheers Jonathan -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: rednotebook (NEW)
On Sun, Jan 04, 2009 at 01:30:20AM +0100, Sandro Tosi wrote: > > Did you consider joining the Python Application Packaging Team[1]? you > can reach us even on IRC at #debian-python (a communication medium > usually faster for the first release of a package). I hadn't; I'll investigate it when I have some time and in the meantime, sending the RFS to -python. Thanks for the tip! -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: lottanzb
Hi Severin
On Mon, Jan 05, 2009 at 10:25:46PM +0100, Severin Heiniger wrote:
> I am looking for a sponsor for my package "lottanzb".
IANADD and can't upload for you, sorry. But some general bits you could
improve:
Lintian generates a minor and some wishlist, full texts attached:
I: lottanzb source: debian-watch-file-is-missing
I: lottanzb source: build-depends-without-arch-dep python-kiwi
I: lottanzb: package-contains-empty-directory
usr/share/icons/hicolor/scalable/apps/
I: lottanzb: copyright-with-old-dh-make-debian-copyright
You don't need debian/dirs; setup.py will create usr/bin for you.
Don't include all of upstream's changes in your changelog, and you don't
need to include your previous versions if they were never in the Debian
archive. Just mark this version as 'Initial release' and close your ITP
on it.
You do need to install upstream's changelog into
usr/share/doc/lottanzb/changelog, I'm not familiar with CDBS but with
Debhelper dh_installchangelogs will take care of this automatically for
you.
(In fact you could use debhelper 7 and its tiny rules file, instead of
the overhead of including CDBS at all, because upstream's install
process is just fine. See [1], [2].)
In debian/control you don't need to depend on ${shlibs:Depends} as this
is a binary-independent package. Standards version 3.8 also recommends a
Homepage field. You have a version dependency on python-kiwi in the
binary depends, but not for build-depends, is there any reason for this?
Your manual page has something wrong with the line breaks in the author
section. Use "man -l debian/lottanzb.1" to preview it and you'll see
the paragraph is all run together with "br." in between sentences.
You might want to revise your short description a bit and make it clear
that this is for downloading newsbins, not reading newsgroups.
Just little things, but that will make your package all the more ready
for a sponsor to upload.
[1] http://manpage.fr/man1/dh
[2] /usr/share/doc/debhelper/examples/rules.tiny
--
Jonathan Wiltshire
PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
Sending of encrypted mail is encouraged
I: lottanzb source: debian-watch-file-is-missing
N:
N:This source package is not Debian-native but it does not have a
N:debian/watch file. This file is used for automatic detection of new
N:upstream versions by the Debian External Health Status project and other
N:project infrastructure. If this package is maintained upstream, please
N:consider adding a debian/watch file to detect new releases.
N:
N:If the package is not maintained upstream or if upstream uses a
N:distribution mechanism that cannot be meaningfully monitored by uscan
N:and the Debian External Health Status project, please consider adding a
N:debian/watch file containing only comments documenting the situation.
N:
N:Refer to Debian Policy Manual section 4.11 (Optional upstream source
N:location: debian/watch) and the uscan(1) manual page for details.
N:
N:Severity: wishlist; Certainty: certain
N:
I: lottanzb source: build-depends-without-arch-dep python-kiwi
N:
N:The control file lists the given package in Build-Depends, but no
N:architecture-dependent packages are built. If all the packages built are
N:architecture-independent, the only packages that should be listed in
N:Build-Depends are those required to run the clean target (such as
N:debhelper if you use dh_clean). Other build dependencies should be
N:listed in Build-Depends-Indep instead.
N:
N:Refer to Debian Policy Manual section 7.7 (Relationships between source
N:and binary packages - Build-Depends, Build-Depends-Indep,
N:Build-Conflicts, Build-Conflicts-Indep) for details.
N:
N:Severity: minor; Certainty: possible
N:
I: lottanzb: package-contains-empty-directory
usr/share/icons/hicolor/scalable/apps/
N:
N:This package installs an empty directory. This might be intentional but
N:it's normally a mistake. If it is intentional, add a lintian override.
N:
N:If a package ships with or installs empty directories, you can remove
N:them in debian/rules by calling:
N:
N: $ find path/to/base/dir -type d -empty -delete
N:
N:Severity: wishlist; Certainty: certain
N:
I: lottanzb: copyright-with-old-dh-make-debian-copyright
N:
N:The copyright file contains the incomplete Debian packaging copyright
N:boilerplate from older versions of dh_make. (C) is not considered as a
N:valid way to express the copyright ownership. The word Copyright or the
N:© symbol should be used instead or in addition to (C).
N:
N:Severity: wishlist; Certainty: certain
N:
signature.asc
Description: Digital signature
Re: RFS: lottanzb
On Tue, Jan 06, 2009 at 02:45:36PM +0100, Severin Heiniger wrote: > > thanks a lot for your helpful comments! I tried to do my best to fix > the issues listed in your message. It's in much better shape now :-) though an experienced DD might know things I've missed. > All mentioned things that could > keep a sponsor from uploading it should be gone by now. Just one thing I didn't remember: this isn't a Debian native package, so your version number in your changelog should have a debian revision - in this case, 0.4.0-1. Your next upload would be 0.4.0-2, etc. When upstream make a release, increment their bit to whatever they choose, and reset yours back to -1 (for example, 0.5.0-1). Good luck finding a sponsor! As it's a python package, you might consider joining the Python Applications Packaging Team [1] where sponsorship is sometimes quicker. [1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
RFS: whohas (new upstream)
Hi Paul I have uploaded whohas 0.22-1 to m.d.n, which is a new upstream integrating a lot of the bugs, and some tweaks to the packaging because of his changes. I've also included a NEWS file detailing the patches that are still active. Lintian -iI seems to be clean, and I have tested each of the integrated bugs to make sure there are no regressions, and it seems fine. Upstream has copied the manual verbatim, because I forgot to warn him about the compressed file intro.txt.gz. I will mail him now and let him know about it for another release, so you will see that there is no sed command in debian/rules for it yet. If you wouldn't mind taking a look when you have chance, the dsc is http://mentors.debian.net/debian/pool/main/w/whohas/whohas_0.22-1.dsc Cheers Jonathan -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: whohas (new upstream)
On Thu, Jan 08, 2009 at 11:00:23AM +0100, Thijs Kinkhorst wrote: > Great. As I think this can be very useful to Debian developers, I have > added a news item to the DeveloperNews queue, which will be posted to > debian-devel-annnounce sometime in the near future: > http://wiki.debian.org/DeveloperNews > Feel free to update/change it. Good idea, thanks. Should it mention that whohas is still <1.0 and being heavily developed though? Or is the BTS mention enough? -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: whohas (new upstream)
On Thu, Jan 08, 2009 at 03:26:45PM +0900, Paul Wise wrote: > > I've also included a NEWS file detailing the patches > > that are still active. > > I don't think that is an appropriate use of NEWS.Debian, documenting > them in the patch headers should be enough. You might want to check > policy/devref about this though. I searched through policy and couldn't find mention of how to handle this situation, where the user should care about Debian-specific patches because they change the application's behaviour. Pretty trivially in this case, but I still think it's important to be able to find this information without needing to get the package source and understand how it goes together. Devref mentions NEWS.Debian as a changelog supplement: "This is the preferred means to let the user know [...] changes in a package" [1]. I didn't use README.Debian as the same paragraph seems to discourage this, but if you think it would be better I will change it. Clarification of these files would be appreciated :-) [1] http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-news-debian > Some other things: > > You install intro.html but not the css/images in html_assets/. Yes, you caught me. Fixed. > Might want to ask upstream to fix install.sh a bit so you can use it: I had thought about this after uploading, I think I will suggest a makefile with an install target which will be good practice for me too. > You don't specify which version of the GPL the packaging is under. Fixed (has some guidance on this changed since last time? if so I missed it, sorry). > Listing all the distros supported may not be a good idea because this > will change over time and thus add work for those translating Debian > package descriptions. With my user's hat on again, I'd really like to know what it supports while looking at the package prospectively, but I agree I don't know how often the list might change. Can you suggest a better place (I thought maybe README|NEWS.Debian), or would it be sufficient to just make it clear that this list might be slightly out of date? > Please add some debtags: > Please also add a screenshot of 0.22-1 (make sure to put in the right version) Will do. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: whohas (new upstream)
On Thu, Jan 08, 2009 at 07:37:52PM +0900, Paul Wise wrote: > > I interpret that as being the changes since earlier versions of the > package, rather than changes to the upstream source code. Ok, if you think README.Debian is acceptable I will move the notes to there. Would you like a version bump when I upload? -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: whohas (new upstream)
On Thu, Jan 08, 2009 at 07:52:37PM +0900, Paul Wise wrote: > Either is fine, slight leaning towards no need for a bump (so I don't > have to remember to use debuild -v...). NP, uploaded to the same location. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFH: dupload outguess.
On Thu, Jan 08, 2009 at 01:18:26PM +0100, Anthony Gasperin wrote:
> I have problems for the dupload, introduction's page at
> mentors.debian.netgive a configuration for "dupload" to
> the root of "ftp://mentors.debian.net"; but it seems it is not the right
> place ! I am wondering where should I
Here's the relevant section of my /etc/dupload.conf:
# Mentors upload queue, see
# http://mentors.debian.net/cgi-bin/maintainer-intro
$cfg{'mentors'} = {
fqdn=>'mentors.debian.net',
incoming=>'/',
dinstall_runs => 1,
passive => 1,
};
Set passive appropriately, then use "dupload -t mentors " to
upload your package.
--
Jonathan Wiltshire
PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
signature.asc
Description: Digital signature
Re: RFS: whohas (new upstream)
On Fri, Jan 09, 2009 at 09:38:33AM +0200, George Danchev wrote: > > I'd appreciate if someone else could sponsor this for now; my > > internets are slow ATM. > > whohas 0.22-1 uploaded. Cheers! Jonathan -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: RFS: Sabacc
Hi Joel On Tue, Jan 13, 2009 at 07:33:13PM -0600, Joel Cross wrote: > I am looking for a sponsor for my package "sabacc". IANADD and can't upload for you, but while you're looking for a sponsor you need to address these problems with your package: Your version number will cause you problems later on - presumably at some point 1.0-beta1-1 will become 1.0-1, but as far as dpkg is concerned this is lower and it will whinge. As you are also upstream this is less of a problem, because you can change the upstream number yourself, to 1.0~beta1 (so then your Debian version becomes 1.0~beta1-1). Lintian is quite vocal too: I: sabacc source: debian-watch-file-is-missing W: sabacc source: out-of-date-standards-version 3.7.3 (current is 3.8.0) E: sabacc source: missing-python-build-dependency I: sabacc source: build-depends-without-arch-dep python-lxml W: sabacc: extra-license-file usr/share/doc/sabacc/COPYING.gz W: sabacc: package-contains-upstream-install-documentation usr/share/doc/sabacc/INSTALL E: sabacc: package-section-games-but-contains-no-game I: sabacc: desktop-entry-contains-encoding-key /usr/share/applications/sabacc.desktop:2 Encoding W: sabacc: new-package-should-close-itp-bug W: sabacc: wrong-bug-number-in-closes l3:# Full lintian output is attached. I haven't looked in much more details, have a go at these and if you need help ask, and we can see what kind of shape it's in after that. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 I: sabacc source: debian-watch-file-is-missing N: N: This source package is not Debian-native but it does not have a N: debian/watch file. This file is used for automatic detection of new N: upstream versions by the Debian External Health Status project and N: other project infrastructure. If this package is maintained upstream, N: please consider adding a debian/watch file to detect new releases. N: N: If the package is not maintained upstream or if upstream uses a N: distribution mechanism that cannot be meaningfully monitored by uscan N: and the Debian External Health Status project, please consider adding N: a debian/watch file containing only comments documenting the N: situation. N: N: Refer to Policy Manual, section 4.11 and the uscan(1) manual page for N: details. N: W: sabacc source: out-of-date-standards-version 3.7.3 (current is 3.8.0) N: N: The source package refers to a Standards-Version older than the one N: that was current at the time the package was created (according to the N: timestamp of the latest debian/changelog entry). Please consider N: updating the package to current Policy and setting this control field N: appropriately. N: N: If the package is already compliant with the current standards, you N: don't have to re-upload the package just to adjust the N: Standards-Version control field. However, please remember to update N: this field next time you upload the package. N: E: sabacc source: missing-python-build-dependency N: N: The package appears to use Python as part of its build process in N: debian/rules but doesn't depend on Python. N: N: Normally, packages that use Python as part of the build process should N: build-depend on one of python, python-all, python-dev, or N: python-all-dev depending on whether they support multiple versions of N: Python and whether they're building modules or only using Python as N: part of the package build process. Packages that depend on a specific N: version of Python may build-depend on the appropriate pythonX.Y or N: pythonX.Y-dev package instead. N: N: Refer to Policy Manual, section 4.2 for details. N: I: sabacc source: build-depends-without-arch-dep python-lxml N: N: The control file lists the given package in Build-Depends, but no N: architecture-dependent packages are built. If all the packages built N: are architecture-independent, the only packages that should be listed N: in Build-Depends are those required to run the clean target (such as N: debhelper if you use dh_clean). Other build dependencies should be N: listed in Build-Depends-Indep instead. N: N: Refer to Policy Manual, section 7.7 for details. N: W: sabacc: extra-license-file usr/share/doc/sabacc/COPYING.gz N: N: All license information should be collected in the debian/copyright N: file. This usually makes it unnecessary for the package to install N: this information in other places as well. N: N: Refer to Policy Manual, section 12.5 for details. N: W: sabacc: package-contains-upstream-install-documentation usr/share/doc/sabacc/INSTALL N: N: Binary packages do not need to contain the instructions for building N: and installing the package as this info is not needed by package N: users. If the info contained is important for configuration perhaps it N: could be summarized in README.Debian, otherwise an override may
RFS: adtool (bugfix)
Hi Cyril adtool/1.3-3 fixes a FTBFS error for porters to GNU/k*BSD as reported in bug #511424, and a tiny fix in debian/rules. I've also added DM-Upload-Allowed to debian/rules too, in advance of applying for DM status, unless you want it missed out for now. The dsc is on mentors as usual, at: http://mentors.debian.net/debian/pool/main/a/adtool/adtool_1.3-3.dsc If you can take a look sometime that would be great. Cheers -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
RFS: webcpp (bug fix)
Hi Sandro webcpp/0.8.4-9 (and -8) is a FTBFS bugfix for porting to kFreeBSD and would close #511427. I've also improved the packaging in -8 and a little further in -9. The updated libtools are a dpatch rather than direct changes, since it's silly to mix the two, but that means its pretty big. It updates the files in the ./admin/ directory with more recent versions from KDE's CVS, as suggested by the reporter. To allow the clean target to work, the second part (make -f ./admin/Makefile.common) is part of the configure target. The other packaging changes are mostly cosmetic, but I have also taken the opportunity to add DM-Upload-Allowed to the control file. If you want that out, by all means say so. The dsc is on mentors at http://mentors.debian.net/debian/pool/main/w/webcpp/webcpp_0.8.4-9.dsc Thanks in advance -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: dicomscope: open tasks
On Wed, Jan 21, 2009 at 05:59:38PM +0100, Mathieu Malaterre wrote: > Could someone please let me know: > 1. What this means ? > 2. What am I supposed to do to fix that issue. It means your package provides a shared library, but you haven't provided the ./debian/shlibs file that describes it to dpkg. See the policy manual [1], section 8.6.3 (like the lintian message advised you to do). [1] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > > thanks ! > > -- > Mathieu > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: RFS: adtool (bugfix)
On Tue, Jan 20, 2009 at 06:16:45AM +0100, Cyril Brulebois wrote: > I'll be taking a look later today. Did you get a chance yet? :-) Cheers -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: RFS: blimp
On Sat, Jan 24, 2009 at 10:57:53PM +0100, Knut Arild Erstad wrote: > Dear mentors, > > I am looking for a sponsor for my package "blimp". > IANADD, but some general comments until a sponsor comes along. You don't seem to have an Intent to Package filed. ITPs prevent code duplication, unneccessary packages and other problems. It should be closed in your changelog. [1] debian/changelog: You can squash your entry for 1.0-1, because it was never in the archive. Close your ITP as above. debian/copyright: you should acknowlege the copyright of the additional resources you include (jiu). On a related note, you should also check whether jiu is already in the archive and depend on it, instead of including it. The short description isn't very good; on seeing that, what makes me want to install it? Seems you build blimp, dcraw and some java classes all in the same package. IMO, you should split these so that either blimp becomes a multiple binary package, building seperate binary packages and having appropriate dependencies, or dcraw, for example, might be useful to other maintainers and should be a completely new source package. Later, when you or another maintainer wants to use these components for something else, it is trivial. Finally you should get rid of cruft and comments in debian/rules, to make it easy to read. You could also investigate debhelper 7, which makes this a lot easier. [1] http://debian.org/doc/developers-reference/pkgs.html#newpackage Hope that helps, -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
RFS: whohas (bugfix)
Hi Paul (and others) whohas/0.22-2 closes two bugs which have gone to upstream, but he is too busy to take of them for the time being so they are stil dpatches. They are quite small patches so hopefully should be a simple review. If you've time to take a look the dsc is at http://mentors.debian.net/debian/pool/main/w/whohas/whohas_0.22-2.dsc I haven't added DM-Upload-Allowed but if you're happy to, please go ahead. Or I'll prepare another upload if you'd prefer that. Cheers Jonathan -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: [uploaded] Re: RFS: whohas (bugfix)
On Mon, Jan 26, 2009 at 10:04:58PM +0200, George Danchev wrote: > > Why do you think the information in README.Debian is relevant to anyone > > installing the package? > > > > Also, some typos in README.Debian: > > Intrebid > > wih > > upsream > > Sure, that particular README.Debian is somehow superfluous here (and could be > removed in the next release, Jonathan: hint, hint, but no rush or you will > need some jumbo sponsors ;-), since it duplicates descriptions given in the > patches' headers. Debian.source (to be refered for package-specific practices > when someone intends to NMU your package) and REAME.Debian-source (dfsg > repackaged source) are not relevant also. I lobbied hard for keeping README.Debian in last time but I can see my inexperience showing again :-) On review you are right, it duplicates the patch headers - my aim was to keep the user informed, who will never see them, but there isn't any real need. Taking it out will also fix the typos elegantly ;-) but no, it's not worth another upload, so it can wait until next time. > I also had a look at 10-debian-versions-511364.dpatch and > 15-honour-proxy-512902.dpatch which are fine. Thanks. Uploaded. Great, thanks! -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: RFS: blimp
On Mon, Jan 26, 2009 at 12:14:05AM +0100, Knut Arild Erstad wrote: > I found an ITP for it it (java-imaging-utilities, #431907). If a JIU > package becomes available in the future, I will update blimp to depend > on it. Better: get in touch with the owner of the ITP and work with him/her to get JIU into the archive, and save yourself the effort changing blimp later. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: What to do if the original tarball contains a debian subdirectory
On Wed, Jan 28, 2009 at 03:59:03PM +, Dmitrijs Ledkovs wrote: > I have a similar question. Upstream has file ./debian/files in their tarball. > Lintian complained about that file so I've deleted it. But during build in > pbuilder > it gets added back from the orig tarball. How to handle this? (disclaimer: IANADD) I would add a blank debian/files file, and override lintian with a suitable explanatory comment. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: whohas (bugfixes)
Hi Paul/George/others I'm looking for sponsorship for whohas/0.22-3, which closes these bugs: 510020 510524 513466 513473 513476 Partiularly, 510020 and 510524 are aging a bit, so it would be nice to tidy them up. Pedantic lintian is clean, and all the patches have gone upstream. You can find the dsc at http://mentors.debian.net/debian/pool/main/w/whohas/whohas_0.22-3.dsc Thanks -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: RFS: whohas (bugfixes)
On Fri, Jan 30, 2009 at 01:31:16PM +, Martin Meredith wrote: > Uploaded, couldn't find any issues. Cheers :-) -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
RFS: copher (bugfix)
Dear mentors I am looking for sponsorship for my package 'copher' (Paul Wise sponsored last time). It closes a serious bug #513710, and also includes the VCS fields now that I have converted my repository to git. The dsc is on mentors at http://mentors.debian.net/debian/pool/main/c/copher/copher_0.1.2+20081201-2.dsc Thanks in advance -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: RFS: sqldeveloper-package
On Wed, Feb 04, 2009 at 03:41:14PM +, Lazarus Long wrote: > You are right, I delayed filling the ITP until I got an acceptable > script so much I ended up forgetting to do it. Fixed: ITP #514124 The point of an ITP is that other developers can respond to your intent *before* you potentially waste time on a package that is duplicate, unneccessary or otherwise not going to go into the archive. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: RFS: clamfs (updated package)
On Sat, Feb 07, 2009 at 05:24:02PM +0100, Krzysztof Burghardt wrote: > I am looking for a sponsor for the new version 1.0.0-1 > of my package "clamfs". IANADD, but one improvement I see you could make: debian/control: s/An user-space/user-space/ -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: adapting a dpatch to changed source: how?
On Sun, Feb 15, 2009 at 08:55:33PM +0100, Andreas Schildbach wrote: > > dpatch-edit-patch does not allow editing a corrupt patch. Unfortunately, > dpatch-edit-patch is the only way I know how to create a dpatch patch > (besides writing it by hand). A dpatch patch is just a normal patch file (with a dpatch header, @DPATCH@ IIRC, so that dpatch knows it is in the right format). If you're unable to manipulate it by hand, there is a bigger problem here. The purpose of dpatch-edit-patch is to automate applying the patch series in the right order, and capturing your changes into a new or existing patch, to make the process less repetitive and prone to mistakes. That's all. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: adapting a dpatch to changed source: how?
On Sun, Feb 15, 2009 at 09:04:19PM +0100, Andreas Schildbach wrote: > So am I really supposed to create that patch file by hand in this case? If you can reconstruct the patched source, then: - apply the patch series as far as possible - take a copy of this original source, and on the copy reconstruct the patched source - take a diff of this against its original, and you get a patch - use dpatch-edit-patch to create a new patch against the original, apply the difference, and capture it -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: adapting a dpatch to changed source: how?
On Sun, Feb 15, 2009 at 09:34:47PM +0100, Andreas Schildbach wrote: > This is the problem. dpatch-edit-patch does not let me do anything as > long as the out-of-sync patch is in place. So take it out of place. A dpatch is two things: the patch file, and its entry in debian/patches/00list. Take its entry out, and dpatch-edit-patch won't try to apply it. > > (01_build_xml is the out-of-sync patch, 01_build_xml_2 is the new patch > I want to create as a replacement; I am using the debianonly layout) > > $ dpatch-edit-patch > --debianonly=/home/aschildbach/src/tarballs/libspring-2.5-java_2.5.6.orig.tar.gz > 01_build_xml_2 > dpatch-edit-patch: > * > /home/aschildbach/src/libspring-2.5-java/debian/patches/01_build_xml_2.dpatch > does not exist, it will be created as a new dpatch. > dpatch-edit-patch: * debian/-only layout selected > dpatch-edit-patch: * > unpacking /home/aschildbach/src/tarballs/libspring-2.5-java_2.5.6.orig.tar.gz > dpatch-edit-patch: * Copying /home/aschildbach/src/libspring-2.5-java to > reference directory. > dpatch-edit-patch: * Cleaning /tmp/dpep-ref.sezSKY/libspring-2.5-java > test -d debian/patched || install -d debian/patched > dpatch apply-all > applying patch 01_build_xml to ./ ... failed. > make: *** [patch-stamp] Error 1 > > Besides, if I created a new patch, how would I get rid of the old one? rm it, and remove its entry in 00list. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: adapting a dpatch to changed source: how?
On Mon, Feb 16, 2009 at 10:37:40AM +0100, Andreas Schildbach wrote: > Ok, dpatch-edit-patch still applies all the other patches (although the > patch I want to create is the first in the series). It is just by > coincidence that none of these patches relies on the problematic patch > being applied first. > > Also, dpatch-edit-patch invokes the clean target of the rules files, > which cannot work until I have that patch in place. A chicken and egg > problem? > I can't reproduce this; can you put your package and patch somewhere to take a look at it? (And there might be a DD around who can help too.) Thanks -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: RFS:qelectrotech
Hi, On Wed, Feb 18, 2009 at 11:59:20PM +0100, laurent scorpio wrote: > Package name: qelectrotech > Version :0.2+svn523.1 > Upstream Author : Xavier Guerrin > * URL : http://qelectrotech.org/ > * License : GPL > Section : Science > * Description :QElectroTech is a Qt4 application to design > electric diagrams. It uses XML > files for elements and diagrams, and includes both a diagram editor and an > element editor. Not being a developer, this is review only, but there is plenty to get on with. Did you run lintian on your built package? The version in sid says: I: qelectrotech source: debian-watch-file-is-missing W: qelectrotech source: package-depends-on-hardcoded-libc qelectrotech depends W: qelectrotech source: maintainer-not-full-name laurent W: qelectrotech: extra-license-file usr/share/doc/qelectrotech/LICENSE.gz W: qelectrotech: copyright-refers-to-versionless-license-file usr/share/common-licenses/GPL W: qelectrotech: copyright-lists-upstream-authors-with-dh_make-boilerplate (this is because you still have '(s)' on the end of the author line) W: qelectrotech: copyright-contains-dh_make-todo-boilerplate I: qelectrotech: desktop-entry-contains-encoding-key /usr/share/applications/qelectrotech.desktop:3 Encoding W: qelectrotech: desktop-mimetype-without-update-call /usr/share/applications/qelectrotech.desktop W: qelectrotech: new-package-should-close-itp-bug W: qelectrotech: debian-changelog-line-too-long line 2 W: qelectrotech: debian-changelog-line-too-long line 5 W: qelectrotech: maintainer-not-full-name laurent E: qelectrotech: depends-on-obsolete-package recommends: cupsys-bsd You can see the full texts with more information about how to fix them by using 'lintian -iIE' on your .changes file. I couldn't make your package build in a sid chroot without making some changes to debian/control: - remove invalid field 'Version' - move fields 'Depends', 'Recommends' and 'Suggests' into the binary package where they belong Is there some reason your binary package is Architecture: i386 instead of Architecture: any? There are still a few source files that don't have GPL grants in the headers, consider adding them. licensecheck is a good quick check, but it can be caught out, so check every file by hand too. You could also consider making your changes to qelectrotech.pro and sources/qet.h with a patch system instead of directly. If anything doesn't make sense please ask. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
