Re: ITS: homebank
On Fri, 1 Jun 2007 02:09:36 +0200 (CEST)
"francesco namuri" <[EMAIL PROTECTED]> wrote:
> On Ven, Giugno 1, 2007 00:16, Neil Williams wrote:
> > On Thu, 31 May 2007 22:45:01 +0200 (CEST)
> >
> > 1. The long description can be improved. The use of 'even more!' is not
> ideal and some of the features (like import/export) could do with some
> more detail. The "standard" application in this area is gnucash (I was a
> gnucash developer at one time) and your long description should follow
> that template and tell the user how homebank differs from the "standard"
> app in the field. For one thing, you should make a big deal about how
> quickly homebank starts up compared to gnucash (which
> > probably has a LOT to do with the vastly reduced number of
> > dependencies).
>
> I hope now it's ok...
"better look and feel" is subjective but that's OK. (You also refer to
the speed twice which is, umm, excessive.) ;-)
For the next upload, consider something like:
HomeBank is a fast, simple and easy to use program to manage your
accounts. HomeBank has a simpler look and feel than gnucash and
includes features such as easy analysis with graphical charts
(statistics, budget, overdrawn, car cost), multiple account support,
budget management, reminders, import from OFX/QFX-CSV files and visual
status indicators. It is based on GTK2.
> > 5. Please ask upstream to make it clear in the app that Help|Contents
> requires an internet connection - this action has the F1 shortcut key
> which most users would expect to provide offline documentation, not
> online - especially as the Help menu specifically includes an online
> help menu item which takes you to a different site. This is just a case
> of preempting bug reports. I would encourage you to encourage upstream
> to provide offline documentation - HTML is fine - via doc-base and a
> homebank-doc package.
>
> ok, I'll contact the author...
Something else for upstream too - before you get any bug reports from
debian-i18n, ask upstream about packaging po/homebank.pot in the next
upstream tarball. This makes it much much easier to ask for debian
translations that can also be fed upstream.
I know homebank includes support for translations upstream via
launchpad but there is no harm in also using the Debian translation
teams. Debian tools are intelligent enough to always use the
Last-Translator fields so that work is not duplicated and you can opt
not to send requests to certain upstream people. Each new translation
will need a change to configure.ac so it is best to ensure that new
translations are always fed upstream. Also, ask upstream to enable this
page:
https://launchpad.net/homebank/+translations
" The HomeBank product is not set up for translation in Launchpad.
If you’re Maxime Doyen, log in to begin the setup process. "
There is little point putting that link in the application when the
page has not been activated.
To package the POT file all upstream needs to do is create a suitable
target in the top level Makefile.am:
pot: Makefile
${MAKE} -C po $(PACKAGE).pot
and then add po/$(PACKAGE).pot to EXTRA_DIST
I think an en_GB translation may be useful for this one - "operations"
are probably easier to understand as "transactions" in the UK (and
maybe elsewhere). With a pot file in the .orig.tar.gz, you can use
podebconf-report-po to call for new translations as well as updates to
existing ones. See man podebconf-report-po
(The POT file contains minor typo errors too. I have done an en_GB
translation that highlights some of the typos - sent off list. Feel
free to send that upstream for inclusion in the next upstream release
and ask me for updates when some of the localisation issues are fixed.)
If this was my own package, I'd be tempted to use the easy CDBS patch
system to add the snippet above and document how to generate the POT
file via README.Debian. Depending on how you get on with upstream, that
could be a useful exercise for you as maintainer. You don't want to
include changes to EXTRA_DIST in your patch, just the make target.
A more involved task upstream is to handle plurals correctly:
%d·operation(s)·inserted\n
%d·error(s)·in·the·file
gettext can handle these such that the translator gets these strings:
%d·operation·inserted\n
%d·error·in·the·file
%d·operations·inserted\n
%d·errors·in·the·file
and gettext adds a plural when one is required. Adding (s) is not
a correct plural in many languages.
Also, the GNU licence text should not be marked translatable. Most
translators will realise this and not translate it but the licence text
is part of a legal document and translating it could cause a change in
the meaning of the text in specific locales.
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLTranslations
"It would be useful to have translations of the GPL into languages other
than English. People have even written translations and sent them to
us. But we have not dared to approve them as officially valid. That
carries a risk so great we d
RFS: gnofract4d
I am looking for a sponsor for my package "gnofract4d". Package name: gnofract4d Version : 3.4+dfsg-1 Upstream Author : Tim Whidbey <[EMAIL PROTECTED]> URL : http://gnofract4d.sourceforge.net/download.html License : BSD Section : graphics It builds these binary packages: gnofract4d - a fractal images creator The package is lintian clean. The upload would fix these bugs: 420507 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gnofract4d - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gnofract4d/gnofract4d_3.4+dfsg-1.dsc I would be glad if someone uploaded this package for me. Kind regards Francesco Namuri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[no subject]
subscribe [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: enblend
* Sebastian Harl [Wed, 30 May 2007 00:15:03 +0200]: > - The files under src/win32helpers are released under the 4-clause BSD > license which is incompatible with the GPL. Thus distributing them as > part > of a GPL'ed program is illegal - the .orig.tar.gz should be repackaged > to > not include those files (they are only needed under Windows anyway) and > '+dfsg' should be added to the version number. Two issues here: - works under a 4-clause BSD license where the copyright holder is the University of California are effectively under a 3-clause BSD license, as per ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change. - even then, it is perfectly fine to *distribute* in a same tarball these incompatible works, as long as they are not linked together (and since they're under win32helpers, I assume they're not on Unix systems). (If they link together, what you can't distribute is the resulting binary; for that, the copyright holder of the GPL part of the source would have to provide an exception allowing for such linkage.) HTH, and thanks to Jacobo Tarrío for confirming that my ideas about this were correct. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Testing can show the presence of bugs, but not their absence. -- Dijkstra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice on packaging SAGE
* Marcus Better <[EMAIL PROTECTED]> [070530 13:43]: > Jordi Gutierrez Hermoso wrote: > > mathematical pieces of software for Debian, beginning with surf, > > Singular's plotting engine, followed by Singular itself, > > IIRC Singular has licensing restrictions (requires citing the authors) so I > don't think it can go in main. I don't think that is part of the license. After the license there is first a request to send in comments and bugs to a specific address, then a request to register yourself as user, then this request: If you use Singular or parts thereof in a project and/or publish results that were partly obtained using SINGULAR, we ask you to cite SINGULAR and inform us thereof - see `http://www.singular.uni-kl.de/how_to_cite.html', for information on how to cite Singular. I'm no native english speaker, and I think those who have written this are neither. But this looks much like it is a request and no condition on use (or copying/modifying). There are licencse problems with the omalloc library included, but it looks like its author already relicenced it, so it will most likely be fixed in the next version. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libmesh
Hi Alan,
thanks for looking at that. Here is the new dsc:
http://mentors.debian.net/debian/pool/main/l/libmesh/libmesh_0.6.0~rc2.dfsg-1.dsc
The package is now lintian&linda clean, builds fine in pbuilder.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426734 seems to have
appeared now.
Fixed.
This doesn't look terribly portable (what's it going to do on hurd??) to me:
ls lib/i486-pc-linux-gnu_opt/*
cp lib/i486-pc-linux-gnu_opt/libmesh.so $(meshbin)
($shell gcc -dumpmachine) might be what you're looking for?
Actually, I had to use:
grep "hosttype " Make.common | cut -d "=" -f 2 | cut -c 2-
because the hosttype variable in Make.common (generated after the
configure is run) contains the correct path (the gcc -dumpmachine
doesn't).
Also section 1 of [1] is relevant here too I think, in that (your rules
at least) don't look very versioned to me.
Do you mean 8.1? I tried to fix that, please tell me if it needs some
more improvements.
It's also generally better to use install or even dh_install instead of cp
I didn't play with dh_install yet. I'll do it in the next iteration -
I should also include the examples in the debian package and some
instructions how to compile them. So far I only put some documentation
into the README.Debian.
# dh_makeshlibs
This line needs to be uncommented. This will go someway towards fixing
the lintian problem. People also like complaining about all the
commented lines left in from the template you used. E.g. there's no
point having #dh_installpam hanging around in your debian/rules
Fixed.
I noticed the following: "/usr/bin/make -j2" I don't think parallel
building is considered the done thing in debian/rules, at least that
seemed to be how I remmeber the discussion in [0] going. People don't
like the smaller buildds getting hit like that.
Fixed.
I haven't looked over the dfsg-ness yet. I think it's considered good
practice to document somewhere what had to go and why to make it dfsg.
Either way it'd be quite handy for me. Is it algorithm that's non-free?
Or documentation?
See debian/copyright. Basically, the upstream tar.gz contains some
packages, that are non-free. The rest is free however, so I would like
to have it in the main distribution.
I'd quite like to see libmesh in Debian, as my own work seems to be
heading more and more towards numerical solutions of PDEs and libmesh
looks like it's worth trying out.
Yes, libmesh is a good library. Only their build system and the way to
compile your own programs is nonstandard that's why I decided to
create a debian package for it. Now it can be used very easily as any
other C++ library.
I'll take another look over the package again later for you. Feel free
to ask more questions if you like :-)
I do :) :
* Currently, it only places libmesh.so.0.6.0 into /usr/lib. So should
I just put symlinks to libmesh.so into the debian/rules? Or what is
the correct way of handling this?
* The ${shlibs:Depends} in debian/control doesn't produce the
dependency on petsc2.3.2. I can put it there by hand. But isn't it
supposed to do it automatically?
If you have some more suggestions, please let me know.
Ondrej
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice on packaging SAGE
Bernhard R. Link wrote: >> IIRC Singular has licensing restrictions (requires citing the authors) so >> I don't think it can go in main. > > I don't think that is part of the license. I don't know, but I think that at least a clarification from the authors is needed. Citing the license [1]: "This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation ( version 2 of the License ); with the following additional restrictions (which override any conflicting restrictions in the GPL):" Note especially the last two lines. > After the license there is > first a request to send in comments and bugs to a specific address, > then a request to register yourself as user, then this > request: No, that's not after the license, but after the blurb which seems to state that those requests are additional restrictions. (Actually they contradict the GPL...) But I agree that the intention is likely as you interpret it, so it should not be difficult to get a clarification. Regards, Marcus [1] http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/COPYING -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice on packaging SAGE
* Marcus Better <[EMAIL PROTECTED]> [070601 15:12]: > Bernhard R. Link wrote: > >> IIRC Singular has licensing restrictions (requires citing the authors) so > >> I don't think it can go in main. > > > > I don't think that is part of the license. > > I don't know, but I think that at least a clarification from the authors is > needed. Citing the license [1]: > > "This program is free software; you can redistribute it and/or modify it > under the terms of the GNU General Public License as published by the > Free Software Foundation ( version 2 of the License ); with the > following additional restrictions (which override any conflicting > restrictions in the GPL):" > > Note especially the last two lines. Hm, after the colon there is a list of subdirectories having their own copyrights and/or licenses. Then there is a warrenty disclaimer and notice where to get a full text of the GPL if not included. But even if there is quite some text in between, it makes it more difficult to decide, of course. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITS: fuseiso
Looks pretty much ok now to me. I'll test it a bit more thoroughly at home later, and then if I don't find any problems make an upload for you. Alan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITS: fuseiso
Il giorno Fri, 1 Jun 2007 15:28:20 +0100 Alan Woodland <[EMAIL PROTECTED]> ha scritto: > Looks pretty much ok now to me. I'll test it a bit more thoroughly > at home later, and then if I don't find any problems make an upload > for you. Thanks for your interest :-) > Alan Have a nice day, David -- . ''`. Debian packager! | http://snipurl.com/gofoxygo/ : :' : User #334216 | http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://www.debianizzati.org/ `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnofract4d
On Fri, 01 Jun 2007 10:25:29 +0200 (CEST) francesco namuri <[EMAIL PROTECTED]> wrote: > > I am looking for a sponsor for my package "gnofract4d". > > Package name: gnofract4d > Version : 3.4+dfsg-1 > Upstream Author : Tim Whidbey <[EMAIL PROTECTED]> > URL : http://gnofract4d.sourceforge.net/download.html > License : BSD > Section : graphics > > It builds these binary packages: > gnofract4d - a fractal images creator > > The package is lintian clean. > > The upload would fix these bugs: 420507 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/g/gnofract4d > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/g/gnofract4d/gnofract4d_3.4+dfsg-1.dsc > > I would be glad if someone uploaded this package for me. I would, but the copyright file states: | fractutils/gf4d_subprocess.py: | | #By obtaining, using, and/or copying this software and/or its | #associated documentation, you agree that you have read, understood, | #and will comply with the following terms and conditions: | # | #Permission to use, copy, modify, and distribute this software and | #its associated documentation for any purpose and without fee is | #hereby granted, provided that the above copyright notice appears in | #all copies, and that both that copyright notice and this permission | #notice appear in supporting documentation, and that the name of the | #author not be used in advertising or publicity pertaining to | #distribution of the software without specific, written prior | #permission. To my understanding this is contrary to DFSG #1 because you cannot sell it, permission is only given "for any purpose AND without fee". So either you contact the upstream author and agree with him to change this clause or you package it for non-free. regards, -- Ricardo Mones http://people.debian.org/~mones «Try the Moo Shu Pork. It is especially good today.» signature.asc Description: PGP signature
Re: RFS: libhttp
On Wednesday 30 May 2007, you wrote: [snip] | Hmm. I'm not sure about the package name - http is a VERY crowded | namespace and a lot of users would assume some kind of Apache | connection with this package. I went ahead and renamed it libemhttp and added the -dbg and emhttp-tools as well. | Which package(s) are going to depend on this library? plucker-desktop (v1.9) that is in the upstream SVN requires this library in order to build the desktop. Right now Debian isn't building the desktop due to issues with it and this library helps curb that issue. | The binary should specify the SONAME: libhttp0 or libhttp1. The source | package is fine. I fixed this, the SONAME is libhttp0 (libhttp.so.0). | You should also provide a -dbg package for all libraries (you also | haven't specified the language used in this project - the code samples | in the txt file are all C). -dbg packages are likely to become mandatory | in due course to provide a complete debug chain. In an embedded context, | these would be used inside a chroot on the workstation (debugging on an | iPAQ isn't fun.) Added the dbg package. [snip] | Your website txt file mentions embedded use (hence my interest as | DD & Emdebian developer and iPAQ/GPE developer) but remember that this | is not simply going into Emdebian or some limited repository just for | embedded packages. It is going into Debian with 19,000 other packages. | Let's just say that most of the short names have been taken. ;-) | | It would be VERY handy to convert that txt file into the simplest of | HTML and link to it from the homepage. (It's also v.long for a txt file | so it would be best to split it into general, usage, history and API | pages). Nothing fancy, just wrap in and | wrap each paragraph in and maybe use a few lines. Just so you know this isn't my library or my site, so I can't do that with the http.txt file, what I did though was add it to the description. | I'm willing to take a closer look at it and potentially sponsor it - | BUT the package name must be changed first, IMHO. Name is fixed, but there may be some more things yet to fix. This is my first library package and I am super new to this. [snip] | The other problem is that you appear to make this CPU-specific - I | think this should be made much clearer. Exactly which CPU's are | supported and which are not? I have the Architecture set to any. It builds out on i386 and amd64 here. [snip] | Maybe rename the source package as emhttp-tools. The main package | provides the binaries which depend on libemhttp0 and this ONLY contains | the shared library, built from the one source package (along with the | -dbg and -dev). i.e. you should be making FOUR binary packages from | this tarball: | | emhttp-tools: /usr/bin/* | libemhttp0: /usr/lib/ | libemhttp-dev: /usr/include usr/lib/pkgconfig (if used) and the other | components of a normal -dev. | libemhttp-dbg: /usr/lib/debug/usr/lib This has been fixed as well. If there are any required changes I can fix them up. | Debian will add other bits like ChangeLog, copyright and manpages for | each of those binaries. Emdebian will remove all of those and | cross-build suitable binaries. | | On a final note, I haven't looked at the package yet but I would | STRONGLY recommend CDBS for this package. It makes automated | cross-builds trivial. Whatever you use, *please* do not use highly | customised rules in debian/rules. As a package directly targetting | embedded uses (and which has very, very little benefit to a desktop | machine) it is only sensible to ensure that it cross-builds (within | Debian) as easily as possible. See http://wiki.debian.org/EmdebianGuide | (Adding cross-build detection section.) I am using CDBS. First time actually and I never realized just how easy it makes things. Neil, I appreciate your help and your possible sponsorship once this package is ready. If you have anymore comments, questions, or concerns, please do not hesitate to contact me. -- Richard A. Johnson [EMAIL PROTECTED] GPG Key: 0x2E2C0124 signature.asc Description: This is a digitally signed message part.
Re: RFS: libhttp
http://mentors.debian.net/debian/pool/main/l/libemhttp0/libemhttp0_1.1.dsc Might help to have a link to the .dsc file. sorry for the double post. -- Richard A. Johnson [EMAIL PROTECTED] GPG Key: 0x2E2C0124 signature.asc Description: This is a digitally signed message part.
RFS: pyqwt5
Dear mentors, I am looking for a sponsor for my package "pyqwt5". * Package name: pyqwt5 Version : 5.0.0-1 Upstream Author : Gerard Vermeulen <[EMAIL PROTECTED]> * URL : pyqwt.sf.net * License : GPL Section : python It builds these binary packages: python-qwt5-doc - Python version of the Qwt5 technical widget library python-qwt5-qt3 - Python version of the Qwt5 technical widget library python-qwt5-qt4 - Python version of the Qwt5 technical widget library The upload would fix these bugs: 413372 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pyqwt5 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pyqwt5/pyqwt5_5.0.0-1.dsc I would be glad if someone uploaded this package for me. The package contains lintian warnings: W: pyqwt5 source: source-contains-cvs-conflict-copy PyQwt-5.0.0/sip/qwt5qt3/.#QwtTypes.sip.1.5 W: pyqwt5 source: source-contains-cvs-conflict-copy PyQwt-5.0.0/sip/qwt5qt4/.#QwtTypes.sip.1.5 I have informed the author of these warnings so I hope they will not appear in version 5.0.1 Kind regards Gudjon I. Gudjonsson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: pyqwt3d
Dear mentors, I am looking for a sponsor for my package "pyqwt3d". * Package name: pyqwt3d Version : 0.1.4-1 Upstream Author : Gerard Vermeulen <[EMAIL PROTECTED]> * URL : pyqwt.sf.net * License : GPL Section : python It builds these binary packages: python-qwt3d-doc - Documentation for the Python-qwt3d library python-qwt3d-qt3 - Python bindings of the QwtPlot3D library python-qwt3d-qt4 - Python bindings of the QwtPlot3D library The upload would fix these bugs: 413355 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pyqwt3d - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pyqwt3d/pyqwt3d_0.1.4-1.dsc I would be glad if someone uploaded this package for me. The package contains lintian warnings: W: pyqwt3d source: source-contains-cvs-conflict-copy PyQwt3D-0.1.4/Doc/pyqwt3d/.#pyqwt3d.tex.1.15 I have informed the author of these warnings so I hope they will not appear in the next version Kind regards Gudjon I. Gudjonsson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITR: libhttp
On Fri, 1 Jun 2007 15:11:43 -0500 "Richard A. Johnson" <[EMAIL PROTECTED]> wrote: > On Wednesday 30 May 2007, you wrote: > [snip] > | Hmm. I'm not sure about the package name - http is a VERY crowded > | namespace and a lot of users would assume some kind of Apache > | connection with this package. > > I went ahead and renamed it libemhttp and added the -dbg and > emhttp-tools as well. Great, thanks. > | It would be VERY handy to convert that txt file into the simplest of > | HTML and link to it from the homepage. (It's also v.long for a txt > | file so it would be best to split it into general, usage, history > | and API pages). Nothing fancy, just wrap in > | and wrap each paragraph in and maybe use a > | few lines. > > Just so you know this isn't my library or my site, so I can't do that > with the http.txt file, what I did though was add it to the > description. That's fine - just mention it to upstream when you get a chance. > Name is fixed, but there may be some more things yet to fix. This is > my first library package and I am super new to this. The New Maintainer Guide does hint that libraries are not usually the best packages to pick. ;-) Don't worry though - my first upstream package and my first Debian package, even before NM, were libraries. :-) > [snip] > | The other problem is that you appear to make this CPU-specific - I > | think this should be made much clearer. Exactly which CPU's are > | supported and which are not? > > I have the Architecture set to any. It builds out on i386 and amd64 > here. Check with upstream - the text file does appear to use some CPU-specific code, or at least describes the usage of such code. > I am using CDBS. First time actually and I never realized just how > easy it makes things. :-) I know lots of DD's dislike CDBS but for those going to DebConf, be aware that I am strongly in favour of CDBS for any package that has a remote chance of being cross-built. Nothing is easier to cross-build than CDBS. > Neil, I appreciate your help and your possible sponsorship once this > package is ready. If you have anymore comments, questions, or > concerns, please do not hesitate to contact me. OK, I'm reviewing the package tonight. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpq9Ay58VxI2.pgp Description: PGP signature
Re: ITR: libhttp
On Fri, 1 Jun 2007 15:14:16 -0500 "Richard A. Johnson" <[EMAIL PROTECTED]> wrote: > http://mentors.debian.net/debian/pool/main/l/libemhttp0/libemhttp0_1.1.dsc > > Might help to have a link to the .dsc file. sorry for the double post. OK, the review. Lots. 1. debian/copyright : boilerplate code is still present. Complete the details for the download location and the upstream author(s). You must put details of the licence in this file. As this is not a "common licence", quote the licence text from the .c file in full. Check each .c and .h file and ensure that they are all using the same licence text, then remove the comments at the end of debian/copyright. Whether CDBS is used or not, whether the package is for an embedded platform or not, this kind of omission simply has to be fixed. Compare with other packages. 2. debian/control : The Source package doesn't need the SONAME because the source package name doesn't change when the API changes. I think you need to summarise the main points of that text, not simply link to it from the long description. This is especially true because the upstream page is just plain text (hard to read, hard to scan) and the actual link itself is not "active", only the Homepage link is clickable in packages.debian.org. Put other parts of the page in README and manpages. Changing the source name will also require changes to debian/changelog. (Use some of the text from the packaged README to fill out the description, use the rest in the manpages. Point to the README from the manpages to help users find the API documentation and talk to upstream about possibly making that API documentation available as HTML.) 3. debian/rules : --prefix=/usr is already specified for you by CDBS, it isn't needed in EXTRA_FLAGS. 4. lintian warnings (some covered above) Now running lintian... E: libemhttp0-dev: helper-templates-in-copyright E: libemhttp0-dbg: non-standard-toplevel-dir debian/ E: libemhttp0-dbg: helper-templates-in-copyright E: libemhttp0: helper-templates-in-copyright W: libemhttp0: package-name-doesnt-match-sonames libhttp0 W: emhttp-tools: binary-without-manpage usr/bin/hget W: emhttp-tools: binary-without-manpage usr/bin/hhead W: emhttp-tools: binary-without-manpage usr/bin/hpost E: emhttp-tools: helper-templates-in-copyright Finished running lintian. Write those manpages - no, really, write them. The binaries appear to have --help output so, for starters, use the template created by dh_make (create a temporary directory to re-run dh_make and copy the manpage XML from there). Introduce some of the content of that upstream text file and then use xsltproc to convert the XML into a usable manpage. Keep the XML in debian/ (so that changes are easy to update) but don't bother generating the manpages during the build - do it manually yourself when the XML changes. Just because embedded platforms will remove the manpage, does not mean you can get away without a manpage. If anything, it makes it MORE important that the Debian package has a detailed manpage so that the cross-built embedded package can be debugged more easily. Use the upstream text to explain, in detail, where this package differs to other implementations of these processes and calls. Documentation is important. E: libemhttp0-dbg: non-standard-toplevel-dir debian/ This refers to ./debian/tmp/usr/lib/debug/ in the dbg package. This is a serious error and must be fixed. Use debc to view the details of the package. This is the most serious problem: W: libemhttp0: package-name-doesnt-match-sonames libhttp0 Renaming is NOT simply a case of changing debian/control. You need to rename the actual shared library (and symlinks). Your package tries to install ./usr/lib/libhttp.so.0.0.9 when it should be ./usr/lib/libemhttp.so.0.0.9 (and so on for all the other files). That's why my original post may have seemed to come across quite harshly - renaming a library package is actually a reasonable amount of work both now and into the future. If at all possible, work with upstream to change the name permanently. There is quite a lot to do in this package yet. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpp2IbaTPoFT.pgp Description: PGP signature
Re: ITS: homebank
Hi Neil, meanwhile I want to thank you for the precious suggestions and for the sponsorship. On Ven, Giugno 1, 2007 11:26, Neil Williams wrote: > On Fri, 1 Jun 2007 02:09:36 +0200 (CEST) > "francesco namuri" <[EMAIL PROTECTED]> wrote: > >> On Ven, Giugno 1, 2007 00:16, Neil Williams wrote: >> > On Thu, 31 May 2007 22:45:01 +0200 (CEST) >> > >> > 1. The long description can be improved. The use of 'even more!' is >> not >> ideal and some of the features (like import/export) could do with some >> more detail. The "standard" application in this area is gnucash (I was a >> gnucash developer at one time) and your long description should follow >> that template and tell the user how homebank differs from the "standard" >> app in the field. For one thing, you should make a big deal about how >> quickly homebank starts up compared to gnucash (which >> > probably has a LOT to do with the vastly reduced number of >> > dependencies). >> >> I hope now it's ok... > > "better look and feel" is subjective but that's OK. (You also refer to > the speed twice which is, umm, excessive.) ;-) > > For the next upload, consider something like: > HomeBank is a fast, simple and easy to use program to manage your > accounts. HomeBank has a simpler look and feel than gnucash and > includes features such as easy analysis with graphical charts > (statistics, budget, overdrawn, car cost), multiple account support, > budget management, reminders, import from OFX/QFX-CSV files and visual > status indicators. It is based on GTK2. perfect, in the next upload I will change the description > Something else for upstream too [cut] I will write a letter to the author informing him on all these issuess, I think that he should have the whole interest to implement all these improvements. In contrary case I will prepare some patches to be able to fix everything the possible as my behalf as mainteiner in the next upload. thanks again Neil, I hope to have soon positive novelty from the author. kind regards, francesco -- Francesco Namuri http://www.namuri.it/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnofract4d
Hi Ricardo, On Ven, Giugno 1, 2007 19:27, Ricardo Mones wrote: > | fractutils/gf4d_subprocess.py: > | > | #By obtaining, using, and/or copying this software and/or its > | #associated documentation, you agree that you have read, understood, > | #and will comply with the following terms and conditions: > | # > | #Permission to use, copy, modify, and distribute this software and > | #its associated documentation for any purpose and without fee is > | #hereby granted, provided that the above copyright notice appears in > | #all copies, and that both that copyright notice and this permission > | #notice appear in supporting documentation, and that the name of the > | #author not be used in advertising or publicity pertaining to > | #distribution of the software without specific, written prior > | #permission. > > To my understanding this is contrary to DFSG #1 because you cannot sell > it, permission is only given "for any purpose AND without fee". > > So either you contact the upstream author and agree with him to change > this clause or you package it for non-free. Yes, you are right, I've searched in google and I've found a problem like this one in other package; the license has been changed in subprocess.py distributed with python2.4, I've asked the upstream author to change this file with the one of python2.4, now I'm waiting the answer hoping that he agree. In the meanwhile I've uploaded to mentors a new version of the package changing the section to non-free. kind regards, francesco -- Francesco Namuri http://www.namuri.it/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: tetgen
Dear mentors, I am looking for a sponsor for my package "tetgen". * Package name: tetgen Version : 1.4.2-1 Upstream Author : Hang Si <[EMAIL PROTECTED]> * URL : http://tetgen.berlios.de/ * License : MIT with a non-free clausule Section : math It builds these binary packages: tetgen - A Quality Tetrahedral Mesh Generator The package is lintian clean. The upload would fix these bugs: 427094 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tetgen - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tetgen/tetgen_1.4.2-1.dsc I would be glad if someone uploaded this package for me. Unfortunately, it's not DFSG free, from the LICENSE file: " This means that TetGen is no free software, but for private, research, and educational purposes it can be used at absolutely no cost and without further arrangements. " So it will have to go to non-free. Tetgen is a high-quality software though and referenced by several packages (gmsh, libmesh...), so it would be nice, if it was in Debian, even though as non-free. Kind regards Ondrej Certik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITR: libhttp
On Friday 01 June 2007, Neil Williams wrote: [snip] | There is quite a lot to do in this package yet. Neil, you aren't joking there. Wow had no idea what all I was getting into here, but since I have started, no way I am going to quit or slow down. This is what I did to a) try and make the packaging a little easier just in case sometime down the road I disappear, and b) because it would have looked silly if I just had one point... OK, I contacted via email, and am awaiting a response, the upstream author asking if it is at all possible for changes. If the author doesn't respond or doesn't feel like implementing some minor changes to help this package mold itself, I guess I am free to grab and make my own version of the package. In a way having me work on the package would kill a couple of birds with one stone, or least knock a wing off :) I appreciate your report and I apologize for dput'ing the wrong directory up to mentors. Bad mistake on my part. 75% of what you noted had someone been fixed in the "correct" package here, i.e. Copyright, Control, and such. Once again thanks for pointing me in the right direction on some things I was beginning to question. Have a great weekend! -- Richard A. Johnson [EMAIL PROTECTED] GPG Key: 0x2E2C0124 signature.asc Description: This is a digitally signed message part.
package stuck in building state due to uninstallable build-deps
Dear mentors, I'm the sponsored maintainer of the gimp-resynthesizer package. About a month ago, I had an upload sponsored for some minor cleanups. Currently, it's still in the 'building' state on sparc and mips[1]. I've taken a look at the buildd logs[2][3], and it seems that last month, it failed to build on those arches due to uninstallable build-deps. Will the buildds automatically requeue my package once the build-deps become installable? If not, is there a convenient way to know whether they're installable on those arches now? Thanks, Bryan Donlan [1] - http://people.debian.org/~igloo/status.php?packages=gimp-resynthesizer [2] - http://tinyurl.com/2kjbnn [3] - http://tinyurl.com/34z6w3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
