Re: How to do a survey on lbzip2 as a bzip2 alternative?
Hello, On Sat, 21 Nov 2009, ERSEK Laszlo wrote: I *really* feel my work between lbzip2-0.15 and lbzip2-0.17, both upstream and packaging, is down the drain. At the very least this work was of use to _you_ --- so it is not down the drain. I was pestering the bzip2 and tar package maintainers to cooperate with me on alternatives symlinks, but once it comes to specifics, they conveniently ignore me. I guess they are right; if users don't care, why should they? And why should users care if lbzip2 is not useful to them? I'm just hurting because I worked in vain to serve what I perceived to be a user request. Won't happen ever again, I promise. I don't really understand how you feel. However, Galois, Abel, van Gogh and others who spent their life unappreciated might have felt even greater pain than you do! :-) This is not meant to mock you but to help you appreciate the fact that doing a nice job (as you have done) does not necessarily lead to appreciation from the society at large. This should not deter us from continuing to do our best. Regards, Kapil. -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: obexpushd (updated package)
Hello, On Tue, 02 Jun 2009, Dominik Bruhn wrote: I am looking for a sponsor for the new version 0.8-1 of the package obexpushd. On Sat, 06 Jun 2009, Dominik Bruhn wrote: I'm looking for someone to sponsor a new version (0.8) for obexpushd. The changes are small, so it should be reasy to review. It is of course linitan clean, so no problems here. The RFA was ITP'ed by the upstream maintainer Hendrik Sattler p...@hendrik-sattler.de on 3rd June 2009. Dominik Bruhn deb...@dbruhn.de ITP'ed on 6th June 2009. Could you please resolve this matter between the two of you before we proceed? There are two possibilities: a. Co-maintainer-ship b. The person who will give up the ITP should send an appropriate mail to 529...@bugs.debian.org. Regards, Kapil. -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Combining changelog entries with dpkg-genchanges
Hello, On Fri, 05 Jun 2009, Romain Beauxis wrote: Can't you just create a version number that fits ? For instance, if your version schema is x.y.z-t, and you want all versions, you can use for instance 0.0.0 I think this means also that the version passed in -v does not have to be present in the changelog. This does not work. As I wrote at the top of this thread: I have wondered why dpkg-genchanges takes the -v option the way it does; which is to take the changelog entries for changes _after_ the specified version --- which must exist. In other words, dpkg-genchanges will not accept a version number argument to -v which is not present in the changelog --- with one exception[*] pointed out by Ben Finney. If the version given is empty then it will take _all_ the entries as new. Regards, Kapil. [*] Of course, one could also argue that the empty version number _is_ present in the changelog :-) -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Combining changelog entries with dpkg-genchanges
Hello, In the context of the RFS for febootstrap, On Wed, Jun 03, 2009 at 01:16:26AM +0530, Y Giridhar Appaji Nag wrote: Another note: I built with -v2.1-1 in debbuildopts but that doesn't include the changelog entry for 2.1-1 in the changes file. I have wondered why dpkg-genchanges takes the -v option the way it does; which is to take the changelog entries for changes _after_ the specified version --- which must exist. This makes it difficult to include multiple changelog entries in a NEW upload. One suggestion I found (I think in Neil William's sponsoring requirements write-up) was to use an empty argument for -v but I couldn't get that to work. Any suggestions? Regards, Kapil. -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Combining changelog entries with dpkg-genchanges
Hello, On Thu, 04 Jun 2009, Ben Finney wrote: Kapil Hari Paranjape ka...@debian.org writes: One suggestion I found (I think in Neil William's sponsoring requirements write-up) was to use an empty argument for -v but I couldn't get that to work. It works fine for me. Perhaps show a VCS repository containing the pre-build state of your tree, and show the ‘foo.source_changes’ you get so we can try reproducing the problem? I didn't give the full context of what was being tried. The -v was inside a pbuilderrc DEBBUILDOPTS variable assignment. It is possible that I got the quotes wrong in the assignment. :-( Since the empty value for the -v argument is not mentioned on the man page I didn't try it with much confidence! I'll try it again. Thanks and regards, Kapil. -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: agedu
Hello, On Fri, 29 May 2009, Alexander Prinsier wrote: Anything else that keeps my package from getting sponsored?;) Uploading! I'm uploading the package. However, you should find a different way to handle the manpage patches in the long run. - send those patches upstream so they can be incorporated into the upstream source. This would be the ideal way. - (possibly in parallel) use some sort of patch management like quilt to manage Debian patches in debian/patches and push the patches into the quilt series. The latter will be useful in case upstream is slow to incorporate these fixes and/or there are other patches which are required for the Debian package. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: agedu
Hello, On Fri, 29 May 2009, Alexander Prinsier wrote: PS: can I bother you when I have an update available for agedu or should I mail to debian-mentors again? You could email to me with a cc to debian-mentors. It may just happen that I am unavailable at the time and someone else will sponsor the package if you send a copy to debian-mentors. PS2: for DD's, is it customary to upload a new version to unstable even if it only fixes a small issue? Or should small issues be batched into one update? Couldn't find an answer on this in the Debian policy. There is no one formula to fit this. If you think that the package looks bad without this fix and/or there is a release/freeze coming up then it is better to fix even small-ish issues. On the other hand if there is a lot of upstream flux or the package is new and is likely to draw a lot of comments/bugs then it may be better to wait so as to incorporate all these as well. Regards, Kapil. P.S. There was a discussion on what fixes are too small on debian-mentors a couple of months ago but I couldn't locate it in my mailbox! -- signature.asc Description: Digital signature
Re: RFS: agedu
Hello, On Wed, 27 May 2009, Alexander Prinsier wrote: * Package name: agedu Version : 8442-2 Upstream Author : Simon Tatham ana...@pobox.com * URL : http://www.chiark.greenend.org.uk/~sgtatham/agedu/ * License : MIT Section : utils It builds these binary packages: agedu - a Unix utility for tracking down wasted disk space The package appears to be lintian clean. Appearances are deceptive. :-) Run a recent version of lintian with the -iIv options to see more! - the manpage uses a hyphen instead of a minus sign - there is no debian/watch file - the standards version is 3.8.0 whereas it should be 3.8.1 - The word Copyright or the unicode copyright symbol should appear in the copyright file I used: - dget http://mentors.debian.net/debian/pool/main/a/agedu/agedu_8442-4.dsc Regards, Kapil. P.S. It would be nice if the key with which you sign the dsc file was in some public place like the keyrings at keys.gnupg.net or pgp.mit.edu -- signature.asc Description: Digital signature
Re: pbuilder --build --binary-arch invokes 'build' target
Hello, On Tue, 05 May 2009, Petr Pudlak wrote: The problem is that if pbuilder is invoked with --binary-arch, it still tries to build the whole project, including the documentation (indep). It looks to me as if the problem is with pbuilder (or with the tools it's invoking), but of course the problem might as well be my ignorance. If you invoke pbuilder --binary-arch then it in turn invokes debian/rules binary-arch. So it looks as if your binary-arch target is running the complete build target. In the case of the tex4ht package I have chosen to create two targets build-arch and build-indep which are invoked by the appropriate binary-* targets. You can browse the SVN repo of the debian directory of the tex4ht package on svn.debian.org http://svn.debian.org/wsvn/collab-maint/deb-maint/tex4ht/trunk/debian/rules to see this. Regards, Kapil. -- signature.asc Description: Digital signature
Re: Best way to solve a file conflict between packages?
Hello,
On Mon, 30 Mar 2009, Davide Puricelli wrote:
I'm asking you help about bug #509367.
As you can imagine similar problems have come-up in the past.
2) just putting a Conflicts between mono-devel and chicken-bin,
but I think it's not a good solution for users.
This is not correct since there is no conflict in the usability
of these two packages on the same system.
3) well, mono-devel came second, they introduced the problem and they
should fix it, renaming their file.
I prefer the solution #3, but I'm not really impartial, I know, so,
what do you think?
I agree with this approach.
In the long run, both maintainers must think about how likely it is
that users will call /usr/bin/csc _by_ _name_ ('csc') in each case. If
this is not too likely, then the binary could equally well be located
somewhere else (like /usr/lib/pkgname/csc for example).
Regards,
Kapil.
--
signature.asc
Description: Digital signature
Re: man pages question
Hellom On Wed, 25 Mar 2009, Jaromír Mikeš wrote: I got these warnings in lintian for my package, having no idea how to solve this issue. I probably have to manage to same man pages opening like this: man jack-jconv will be opened on these too: man jconv man fconv man mkwavex This is done by symbolic links. For example 'man grep' and 'man egrep' are usually the same page. If the links are not created by your upstream package, then you will have to create them with debian/pkgname.links Regards, Kapil. -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: tmux (updated package)
Hello,
On Wed, 11 Mar 2009, Karl Ferdinand Ebert wrote:
I am looking for a sponsor for the new version 0.7-1
of my package tmux.
Here are some comments:
- add FAQ to docs
- add CHANGES file as upstream changelog
- ITP bug will be closed by the first upload not the first packaging attempt
So the Closes should come in the topmost changelog entry.
- some licenses are BSD 3-clause some are BSD-2 and others are of the type
included in the debian/copyright file
- include NOTES file in docs
- include examples in docs
The package appears to be lintian clean.
Not so! :-(
There are Lintian errors in your manpage (hyphen used as minus sign).
The report is attached.
Regards,
Kapil.
--
N: Setting up lab in /tmp/S5enavUQOg ...
N: Processing changes file tmux_0.7-2_amd64.changes ...
N: Processing 2 packages...
N:
N: Processing source package tmux (version 0.7-2) ...
N:
N: Processing binary package tmux (version 0.7-2) ...
I: tmux: hyphen-used-as-minus-sign usr/share/man/man1/tmux.1.gz:340
N:
N: Manual page seems to contain a hyphen where a minus sign was intended.
N: '-' chars are interpreted as hyphens (U+2010) by groff, not as minus
N: signs (U+002D). Since options to programs use minus signs (U+002D),
N: this means for example in UTF-8 locales that you cannot cutpaste
N: options, nor search for them easily.
N:
N: '-' must be escaped ('\-') to be interpreted as minus. If you really
N: intend a hyphen, write it as '\(hy' to emphasise that fact. See
N: groff(7) and especially groff_char(7) for details, and also the thread
N: starting with
N: http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg01481
N: .html
N:
N: If you use some tool that converts your documentation to groff format,
N: it might be possible that this tool converts dashes of any kind to
N: groff hyphens, while the safe way of converting dashes is usually to
N: convert them to '\-'.
N:
N: Because this error can occur very often we show only the first 10
N: occurrences for each man page and give the number of suppressed
N: occurrences. If you want to see all warnings, run lintian with the
N: -d/--debug option.
N:
I: tmux: hyphen-used-as-minus-sign usr/share/man/man1/tmux.1.gz:342
I: tmux: hyphen-used-as-minus-sign usr/share/man/man1/tmux.1.gz:344
I: tmux: hyphen-used-as-minus-sign usr/share/man/man1/tmux.1.gz:346
I: tmux: hyphen-used-as-minus-sign usr/share/man/man1/tmux.1.gz:999
N: Removing /tmp/S5enavUQOg ...
signature.asc
Description: Digital signature
Re: RFS: tmux (updated package)
Hello, On Thu, 12 Mar 2009, Paul Wise wrote: This sounds very much like 'screen', what advantages does it have over 'screen'? Just quoting from the FAQ: * How is tmux different from GNU screen? What else does it offer? tmux offers several advantages over screen: - a clearly-defined client-server model: windows are independent entities which may be attached simultaneously to multiple sessions and viewed from multiple clients (terminals), as well as moved freely between sessions within the same tmux server; - a consistent, well-documented command interface, with the same syntax whether used interactively, as a key binding, or from the shell; - easily scriptable from the shell; - multiple paste buffers; - choice of vim or emacs key layouts; - an option to limit the window size; - a more usable status line syntax, with the ability to display the first line of output of a specific command; - a cleaner, modern, easily extended, BSD-licensed codebase. Some of these (preferably not just the last!) should be chosen and added to the package description. Currently upstream considers UTF-8 support to be in need of improvement. Kapil. -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS [2]: math input formatter for pidgin (pidgintex), general math formatter tool (mathtex)
Hello, On Sat, 24 Jan 2009, Johan Henriksson wrote: Johan Henriksson wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509601 http://mahogny.areta.org/temp/debs/ Source: pidgintex Section: net Priority: optional Maintainer: Johan Henriksson maho...@areta.org Build-Depends: debhelper (= 7), pidgin-dev Standards-Version: 3.8.0 Homepage: http://code.google.com/p/pidgintex/ I see that your package has not been sponsored as yet. As I do not use pidgin (though I use TeX) I am not yet sure that I will sponsor your package eventually. In any case here are some preliminary comments: - debian/copyright information is at odds with pidginTeX.[ch] - FSF address in those files is wrong - debian/copyright needs state the license more clearly than a bald GPL 2.0 - spurious change in upstream Makefile (blank line added) - there are some other mini-tex converters like texgd, will the package work with those? - is it LaTeX only or does it work with plain TeX. The last two questions could be addressed in a README.Debian or if possible in the package description. I may return to examine this package this evening with some more comments. Kapil. -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS [2]: general math formatter tool (mathtex)
Hello,
On Sat, 24 Jan 2009, Johan Henriksson wrote:
Johan Henriksson wrote:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509626
http://mahogny.areta.org/temp/debs/
Source: mathtex
Section: graphics
Priority: optional
Maintainer: Johan Henriksson maho...@areta.org
Build-Depends: debhelper (= 7), docbook-to-man
Standards-Version: 3.8.0
Homepage: http://www.forkosh.dreamhost.com/source_mathtex.html
Package: mathtex
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, dvipng, texlive
Description: Generate image from LaTeX command
MathTeX, licensed under the gpl, is a cgi program that lets you easily
embed LaTeX math in your own html pages, blogs, wikis, etc. It parses
a LaTeX math expression and immediately emits the corresponding gif
(or png) image, rather than the usual TeX dvi.
Usually, it is good to separate the RFS's according to package! Here
are some comments.
- description needs to be improved; e.g. do not mention gpl. can
it be used only as cgi? is it LaTeX only or does it support
plain TeX or other dialects.
- dependency on all of texlive is probably incorrect.
- bald GPL 3.0 is not a copyright assertion.
- license has been changed to GPL 3 or later while packaging!
- Makefile can be replaced by debian/rules
- manpage can be kept in debian/ since it has been added as part of debian
packaging
- what is the difference between this and mimetex or texgd?
- add a debian/watch file (see man uscan)
Regards,
Kapil.
--
signature.asc
Description: Digital signature
Re: RFS: libpam-paperauth
Hello,
On Fri, 27 Feb 2009, Luke Faraone wrote:
I am looking for a sponsor for my package libpam-paperauth.
Generally looks good. However, it fails to build from source.
The pbuilder build returned the following error:
/usr/bin/ld: pam_ppp_so-pam_ppp.o: relocation R_X86_64_32 against
`a local symbol' can not be used when making a shared object;
recompile with -fPIC
pam_ppp_so-pam_ppp.o: could not read symbols: Bad value
The log is attached.
Kapil.
--
I: Using pkgname logfile
Current time: Wed Mar 4 16:21:09 IST 2009
pbuilder-time-stamp: 1236163869
Installing the build-deps
- Attempting to satisfy build-dependencies
- Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team pbuilder-ma...@lists.alioth.debian.org
Description: Dummy package to satisfy dependencies with aptitude - created by
pbuilder
This package was created automatically by pbuilder and should
Depends: cdbs, debhelper (= 7), autotools-dev, uuid-dev, libpam0g-dev,
asciidoc, xsltproc, docbook-xml, docbook-xsl
dpkg-deb: building package `pbuilder-satisfydepends-dummy' in
`/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Reading package lists...
Building dependency tree...
Reading state information...
aptitude is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Selecting previously deselected package pbuilder-satisfydepends-dummy.
(Reading database ... 9780 files and directories currently installed.)
Unpacking pbuilder-satisfydepends-dummy (from
.../pbuilder-satisfydepends-dummy.deb) ...
dpkg: dependency problems prevent configuration of
pbuilder-satisfydepends-dummy:
pbuilder-satisfydepends-dummy depends on cdbs; however:
Package cdbs is not installed.
pbuilder-satisfydepends-dummy depends on debhelper (= 7); however:
Package debhelper is not installed.
pbuilder-satisfydepends-dummy depends on autotools-dev; however:
Package autotools-dev is not installed.
pbuilder-satisfydepends-dummy depends on uuid-dev; however:
Package uuid-dev is not installed.
pbuilder-satisfydepends-dummy depends on libpam0g-dev; however:
Package libpam0g-dev is not installed.
pbuilder-satisfydepends-dummy depends on asciidoc; however:
Package asciidoc is not installed.
pbuilder-satisfydepends-dummy depends on xsltproc; however:
Package xsltproc is not installed.
pbuilder-satisfydepends-dummy depends on docbook-xml; however:
Package docbook-xml is not installed.
pbuilder-satisfydepends-dummy depends on docbook-xsl; however:
Package docbook-xsl is not installed.
dpkg: error processing pbuilder-satisfydepends-dummy (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
pbuilder-satisfydepends-dummy
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
The following NEW packages will be installed:
asciidoc{a} autotools-dev{a} bsdmainutils{a} cdbs{a} debhelper{a}
docbook-xml{a} docbook-xsl{a} file{a} gettext{a} gettext-base{a}
groff-base{a} html2text{a} intltool-debian{a} libcroco3{a} libdb4.5{a}
libgcrypt11{a} libglib2.0-0{a} libgpg-error0{a} libmagic1{a}
libpam0g-dev{a} libpcre3{a} libsqlite3-0{a} libssl0.9.8{a} libxml2{a}
libxslt1.1{a} man-db{a} mime-support{a} po-debconf{a} python{a}
python-minimal{a} python2.5{a} python2.5-minimal{a} sgml-base{a}
sgml-data{a} uuid-dev{a} xml-core{a} xsltproc{a}
The following partially installed packages will be configured:
pbuilder-satisfydepends-dummy
0 packages upgraded, 37 newly installed, 0 to remove and 0 not upgraded.
Need to get 19.7MB of archives. After unpacking 68.3MB will be used.
Writing extended state information...
Get:1 http://192.168.17.7 sid/main libmagic1 4.26-2 [369kB]
Get:2 http://192.168.17.7 sid/main file 4.26-2 [44.8kB]
Get:3 http://192.168.17.7 sid/main html2text 1.3.2a-13 [103kB]
Get:4 http://192.168.17.7 sid/main libpcre3 7.8-2 [215kB]
Get:5 http://192.168.17.7 sid/main libglib2.0-0 2.18.4-2 [844kB]
Get:6 http://192.168.17.7 sid/main libxml2 2.7.3.dfsg-1 [870kB]
Get:7 http://192.168.17.7 sid/main libcroco3 0.6.1-2 [123kB]
Get:8 http://192.168.17.7 sid/main gettext-base 0.17-6 [125kB]
Get:9 http://192.168.17.7 sid/main gettext 0.17-6 [2710kB]
Get:10 http://192.168.17.7 sid/main intltool-debian 0.35.0+20060710.1 [30.8kB]
Get:11 http://192.168.17.7 sid/main po-debconf 1.0.15 [237kB]
Get:12 http://192.168.17.7 sid/main groff-base 1.18.1.1-21 [898kB]
Get:13 http://192.168.17.7 sid/main bsdmainutils 6.1.10 [179kB]
Get:14 http://192.168.17.7 sid/main man-db 2.5.4-1 [1386kB]
Get:15 http://192.168.17.7 sid/main debhelper 7.0.52 [547kB]
Get:16 http://192.168.17.7 sid/main cdbs 0.4.52 [921kB]
Get:17 http://192.168.17.7 sid/main autotools-dev 20080123.2 [63.0kB]
Get:18 http://192.168.17.7 sid/main uuid-dev 1.2-1.41.3-1 [59.4kB]
Get:19 http://192.168.17.7
Re: generating html documentation from LaTeX?
Hello, On Fri, 27 Feb 2009, Petr Pudlak (Debian) wrote: generating documentation also in HTML. I found a nice program, tex4ht, which seems to work quite well. Great to hear that! I have a few question though: 2) The HTML page is quite large, ~300k, about the same size as the PDF. Should I put it into a separate package or not? You could use the sectioning options for tex4ht (look at the log file after running htlatex for additional options to fine tune the output of tex4ht) to decide how to split the output so that individual pages are not too big. 3) Should I state 'tex4ht' in build dependencies and rebuild the documentation in debian/rules, or should I create it in advance and include it as a diff/patch? I think the first method is better. It may be possible to make a separate -doc package which is arch all. This way you could build the documentation only once and you avoid loading the buildd's. You can also use Build-Depends-Indep to put tex4ht only as a Build dependency only for the arch independent build. However with only 300k worth of documentation (:-)) this may not be worth the effort. Regards, Kapil. -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
Hello, On Mon, 19 Jan 2009, Ben Finney wrote: * When packages are created by ‘dpkg-buildpackage’, the ‘*_changes’ files by default contain only changes from the latest entry in the changelog. By default, yes. However, there is the -vmmm.nnn-qqq option which makes the changelog of all versions succeeding mmm.nnn-qqq get included in the changes file. Kapil. -- signature.asc Description: Digital signature
Re: Library Packaging
Hello, On Fri, 03 Oct 2008, Neil Williams wrote: On Fri, 2008-10-03 at 16:16 -0400, Jonathan Steel wrote: I'm trying to create a package of a shared library and I can't figure out how to do it. I can do it for a normal binary using dh_make and debuild. Ive read through all the debian packaging guides I can find. Generally, I don't recommend that anyone on this list seriously considers packaging shared libraries until they have a couple of ordinary binary packages in the archive. /me agrees. /me thinks I'm going to have to write a little guide on this but lack the time right now. There is a guide covering some of the basic issues at http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html Kapil. -- signature.asc Description: Digital signature
Re: [OT] Re: how to install package using apt-get in folder other than /usr
Hello, On Tue, 30 Sep 2008 21:19:27 +0900 Charles Plessy [EMAIL PROTECTED] wrote: whereas one of the goals of letting the user installing packages in his home directory is to not bother the admins. In that case, use fakechroot, it may be enough for you. Alternatively use qemu or user-mode-linux to create an entire emulated machine over which the user has complete control. On recent hardware this can be fast enough for regular use. You have already mentioned zero-install. It works outside the packaging system and provides a solution for some users as well. Regards, Kapil. -- signature.asc Description: Digital signature
Re: how to install package using apt-get in folder other than /usr
Hello, On Mon, 29 Sep 2008, Kruti wrote: Can someone help me regarding how to install a package in any user defined folder other than /usr using apt-get? If you just want to examine the contents of the .deb package then you can download the package (e.g. aptitude download pkgname) and unpack it using dpkg -x pkgname target_directory or using ar. Installing a package so that it can be used is more complex since it is likely that the pre-compilation configuration of a binary package set the prefix for the installation as /usr. Hence the package may not work as you expect. Here are some possible solutions: 1. Use an schroot (e.g. this is described in my article http://www.linuxgazette.net/150/kapil.html) This will still be in /usr but under a different directory heirarchy. 2. Use a fakechroot (e.g. this is described in my blog post http://www.imsc.res.in/~kapil/blog/floss/fakeroot-2008-03-04-10-01 The second solution does not require you to re-install all the dependencies of the package that have already been installed. However, it may not work for all packages. Regards, Kapil. -- signature.asc Description: Digital signature
Re: No response from MIA
Hello, On Fri, 26 Sep 2008, W. van den Akker wrote: I am trying to get the maintainership for a package (SCID, et al). Does this mean that you are: 1. Working on bugs in the package --- in which case please file patches to the relevant bug report. 2. Working on a newer upstream version --- in which case file a bug report saying please package newer version and if possible post an interdiff between the existing debian .diff.gz and a new diff.gz which packages the new version. 3. Finding bugs in the package --- in which case please report the bugs and file patches where possible. If you have already done all of the above then please mention this (with reference to the bug report) in your e-mail to QA. Regards, Kapil. -- signature.asc Description: Digital signature
Re: apt-proxy, apt-cacher approx
Hello, On Tue, 23 Sep 2008, Thomas Goirand wrote: P.S: I also had hard time doing a backport of the Lenny version of apt-cacher that depends on so many packages to be backported. You can use schroot or chroot to run the lenny version of software under etch (for example http://linuxgazette.net/150/kapil.html even if I say so myself!) It takes slightly more disk space than a backport but is often simpler than the latter. Disclaimer: I run approx. Kapil. -- signature.asc Description: Digital signature
Re: Need advice about my first package
Hello, On Sat, 20 Sep 2008, Laurent Guignard wrote: I think that the RFS procedure is too strict or legal for me (at this moment according to my knowledge about Debian) and i would like to have a mam to man discuss about... Is it possible ? Don't ask whether you can ask! Just ask. In other words, ask your question about Debian packaging. What is the worst that can happen? Kapil. -- signature.asc Description: Digital signature
[DONE] Re: RFS: remind (updated package)
Hello, On Fri, 11 Jul 2008, Kurt B. Kaiser wrote: I've uploaded -2, thanks! (Will need tarball upload) http://mentors.debian.net/debian/pool/main/r/remind/remind_03.01.05-2.dsc Please note that the following changelog line was missing from your package and was added: * Update Standards Version to 3.8.0. No other changes required. Uploaded. Thanks for your work on this package. Regards, Kapil. -- signature.asc Description: Digital signature
License help needed (nvi 1.81.6-3)
Dear Jan, (I am cc-ing this to debian-mentors some of whom might be able to help.) I looked at your packaging at: http://www-pool.math.tu-berlin.de/~hesso/deb/nvi_1.81.6-3.dsc I agree that the copyright situation is a bit complex. Basically, Joerg has raised the question because the current debian/copyright does not clarify matters enough. I would try to create a debian/copyright which tries to clearly collate and organise all the copyright assertions in the code. We can then separately worry about interpretations and what an appropriate aggregated copyright is! (A document that will help to organise things is http://wiki.debian.org/Proposals/CopyrightFormat) For example, grep -rl LICENSE gives all the files that refer to the file LICENSE which is the BSD 3-clause license file. This reduces the number of files that one needs to examine for variations. Another example. You probably need to include the top portion of regex/COPYRIGHT in debian/copyright according what is stated there. That is the license of Henry Spencer who is the original author. Moreover, he has specifically said that *his* code is _not_ subject to any license of the Regents of the University of California! The _modifications_ to that code are under distributed under BSD-3. This is all a bit painful but I am sure that we will all thank you for this effort. I too will try to help by producing my version of debian/copyright for this package. Regards, Kapil. -- signature.asc Description: Digital signature
Re: License help needed (nvi 1.81.6-3)
Dear Jan, On Sun, 06 Jul 2008, Jan Christoph Nordholz wrote: I've uploaded an updated package to the above URL and also uploaded the new copyright file separately to http://www-pool.math.tu-berlin.de/~hesso/deb/nvi.copyright Short explanation: * All files that refer to LICENSE instead of including an own license statement are covered by BSD-3 and pose no problem. * The regex/ subdirectory is covered by regex/COPYRIGHT. Original author seems to be Henry Spencer, whose license text I have included as-is. Subsequent modifications are by UCB and therefore under BSD-3. * The clib/ subdirectory has BSD-4 license texts, but the only copyright holder is UCB, so due to their retroactive removal of the ad-clause I believe those to be equivalent to BSD-3. * dist/ltmain.sh is FSF code under GPL-2+. This is more or less what I thought as well. Some points: a. dist/ltmain.sh is a generated file and so I think it need not be described in debian/copyright separately. That file says: # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. b. While I concur with you on the clib/ directory, I think it would be good if we get a second opinion (perhaps Joerg's?) from debian-mentors. Alternatively/additionally, the statement you made above should probably be made in debian/copyright so that it is clear on what basis we are drawing our conclusions. This is because the files explicitly contain the BSD-4 clause license. c. The debian/copyright file in the URL above makes no mention of the debian packaging. That is copyrighted by the maintainer(s) and a license has to be specified. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: remind (updated package)
Hello, On Thu, 03 Jul 2008, Kurt B. Kaiser wrote: I am looking for a sponsor for the new version 03.01.05-1 of my package remind. Since the previous version (03.01.04) of the package has been accepted with DM-Upload-Allowed: yes and you as the maintainer, it seems to me that you should be able to upload the package yourself since you are listed in the Debian Maintainer's keyring. Here are some additional comments. - A lot of the files list David F. Skoll as one of the copyright holders, not just the files that you list under exceptions in debian/copyright. - You use the field XS-DM-Upload-Allowed instead of DM-Upload-Allowed. - You use Standards Version 3.7.3 when the current version is 3.8.0 Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: remind (updated package)
Hello, On Sat, 05 Jul 2008, Kurt B. Kaiser wrote: I am not yet in the DM keyring. Once I get my package gambc uploaded, I will apply. Oops. I should have checked with gpg --list-options show-keyring! Sorry about that. Also, remind has never been uploaded with the DM-Upload-Allowed field set, Actually, this is what confused me a bit. If you run apt-get source remind zgrep DM-Upload-Allowed remind_03.01.04-1.diff.gz then you'll see that this field *is* set in the Debian package. That's when I switched back to XS-DM-U-A :-) Currently that counts as a diff between your new 03.01.05-1 package and Debian version 03.01.04-1. Here is an important principle of Debian packaging (especially needs checking when your packages are being sponsored). The current version of the Debian package is what is in the archive --- *not* the version that is on your disk. (I've been bitten by this at least once!) So it is best if you do an apt-get source -t unstable remind in order to check the differences between the earlier version and the new one. I would upload it with DM-U-A set as it is in 03.01.04-1. David F. Skoll is the owner of Roaring Penguin, which holds the remind copyright. The exceptions are for code which is not (entirely) his own. In that case, it would best if a change is made to the files upstream. Alternatively, you could just add the copyright assertion for David F. Skoll to debian/copyright where it used to be next to the copyright assertion for Roaring Penguin in the earlier version. The point is that someone looking at the source files and comparing them with debian/copyright might not be aware of the fact you have given above and would need further clarification. The point of debian/copyright is to avoid such needs! The package has been on mentors for two months; my sponsor hasn't been able to find the time to upload it, so I'm now asking here. Since I use remind regularly, I am keen to see an updated version and will upload it. Please fix the debian/control and debian/copyright files as indicated. Regards, Kapil. -- signature.asc Description: Digital signature
[DONE] Re: RFS: bindfs
On Fri, 27 Jun 2008, Eugene V. Lyubimkin wrote: New package on mentors: http://mentors.debian.net/debian/pool/main/b/bindfs/bindfs_1.6.2-1.dsc Uploaded. Thanks for your contribution to Debian. Regards, Kapil. -- signature.asc Description: Digital signature
Re: Some license issues (Was Re: RFS: unionfs-fuse)
Dear Bernd, On Thu, 26 Jun 2008, Bernd Schubert wrote: Thanks at lot! I modified a bit following the wiki page Richard posted (http://wiki.debian.org/Proposals/CopyrightFormat#head-133d3ff18d9a3119d48e96f0c8aca4a37391769f). In detail I changed License to other. From the wiki page it not clear to me if it ok to have the license at the end of the file. All examples there have the license text directly below the License field. I also removed the Authors field, since it does not exist on the wiki page. Looks good. Fixed now, by rewriting the elfhash function. That's quick! dget http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs-fuse_0.20-3.dsc PS: I didn't try to upload the package for several months, since I was all the time afraid of the formalisms like these. I hope that this response has been encouraging rather than otherwise. I have one and a half more nit-picks. - The debian/copyright.in file no longer has any use and can be removed. - You may want to install the CREDITS file in /usr/share/doc/unionfs-fuse using dh_installdocs Regards, Kapil. -- signature.asc Description: Digital signature
Re: Some license issues (Was Re: RFS: unionfs-fuse)
Hello, On Thu, 26 Jun 2008, Bernd Schubert wrote: Thanks for spotting that. Fixed now. I just uploaded another version. dget http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs-fuse_0.20-4.dsc Uploaded. Thanks for your contribution to Debian. Please check http://buildd.debian.org/unionfs-fuse for further info. On a personal note. I have a version of pbuilder that uses unionfs to speed things up. So far that has not worked under vserver because unions cannot be created and removed in those. I am hoping to use unionfs-fuse to solve this issue. Regards, Kapil. -- signature.asc Description: Digital signature
Re: Some license issues (Was Re: RFS: unionfs-fuse)
Hello, On Thu, 26 Jun 2008, Bernd Schubert wrote: PS: I didn't try to upload the package for several months, since I was all the time afraid of the formalisms like these. I hope that this response has been encouraging rather than otherwise. Well, yes and no ;) For this package all of this is still ok, since the package is rather small. Your help and efforts are great and very appreciated, of course! On the other we (q-leap) also have our own debian ofed packages and actually we also want to upload these. But compared to unionfs-fuse ofed-1.3 is huge (38 packages) and I'm really scared of the debian-upload process. Since I do mathematical research I compare this process to that. The most enjoyable part is to do the mathematics. Then there is the part of actually writing the paper and getting it ready for public consumption (with the interference^Wassistance of referees). However, the great thing is that once the second step is over, it becomes possible for other people to pick up the baton. Best wishes for your larger package set. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: bindfs
Hello, On Thu, 26 Jun 2008, Eugene V. Lyubimkin wrote: Dear mentors, I'm looking for sponsor :) - - dget http://mentors.debian.net/debian/pool/main/b/bindfs/bindfs_1.6.1-3.dsc Here are some issues with this package. - many source files have *no* copyright or author identification. - there are spelling mistakes in debian/changelog. Please spellcheck the files in debian/ which are for users to read. - dpkg_shlibs gives the following warnings: dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if debian/bindfs/usr/bin/bindfs were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if debian/bindfs/usr/bin/bindfs were not uselessly linked against it (they use none of its symbols). Regards, Kapil. -- signature.asc Description: Digital signature
Some license issues (Was Re: RFS: unionfs-fuse)
Hello, Mentors with some experience ith license issues may want to chip in here! On Mon, 23 Jun 2008, Bernd Schubert wrote: - Please comply with section 4.2 of the Maintainer's guide I tried my best to fulfill these reqirements dget http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs-fuse_0.20-2.dsc The general consensus is that the debian/copyright file should contain details about the copyright for each file that is included not just the primary files. I have enclosed a sample debian/copyright file for your package. You might wish to edit it before including it. Another point is that I am not very clear on the compatability of the CPL license (used in elfhash*) with the BSD code. It _seems_ to be OK and so I would upload your package, but it would be nice if you have a reference (URL or e-mail) readily available to clarify this. Regards, Kapil. -- This package was debianized by Bernd Schubert [EMAIL PROTECTED] on Wed, 12 Sep 2007 19:22:07 +0200. It was downloaded from http://podgorny.cz/moin/UnionFsFuse The brief summary of the copyright information for the files in this package is given below. The summary is followed by the detailed license texts. Files: debian/* Authors: Bernd Schubert [EMAIL PROTECTED] Copyright: Copyright 2008, Bernd Schubert [EMAIL PROTECTED] License: Modified BSD 3-Clause Files: hashtable*.[ch] Authors: Christopher Clark Copyright: Copyright 2002, 2004, Christopher Clark License: Modified BSD 3-Clause Files: elfhash.[ch] Authors: Arash Partow Copyright: Copyright 2002, Arash Partow Licence: Common Public Licences (CPL) Version 1.0 or most recent Files: cow_utils.[ch] Authors: OpenBSD developers Bernd Schubert [EMAIL PROTECTED] Copyright: Copyright 1991, 1993, 1994, The Regents of the University of California. License: Original BSD 3-Clause Files: * Authors: Radek Podgorny Maxim Konushikhin [EMAIL PROTECTED] R. Ramkumar [EMAIL PROTECTED] John Cobb [EMAIL PROTECTED] Bernd Schubert [EMAIL PROTECTED] Samuel Gelineau [EMAIL PROTECTED] Mattias Wadman [EMAIL PROTECTED] Lucas C. Villa Real [EMAIL PROTECTED] Copyright: Copyright 2008, Radek Podgorny, Bernd Schubert License: Modified BSD 3-Clause The detailed License Texts == Original BSD 3-Clause: -- The Original BSD 3-Clause licence can be found in the file /usr/share/common-licenses/BSD on a Debian system. Modified BSD 3-Clause: -- (taken from LICENSE file in source package) Copyright author_names specific to each file as detailed above All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the original author; nor the names of any contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Common Public License - (taken from http://www.opensource.org/licenses/cpl1.0.txt) THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS COMMON PUBLIC LICENSE (AGREEMENT). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT. 1. DEFINITIONS Contribution means: a) in the case of the initial Contributor, the initial code and documentation distributed under this Agreement, and b) in the case of each subsequent Contributor: i) changes to the Program, and ii) additions to the Program; where such changes and/or additions to the Program originate from and are distributed by that particular Contributor. A Contribution 'originates' from a Contributor if it was added to the Program by such Contributor itself or anyone acting on such Contributor's behalf. Contributions do not include additions to the
Re: RFS: nvi [DONE] (Was Re: Multi-RFS: nvi, autofs5, mt-st)
Hello, On Thu, 12 Jun 2008, Jan Christoph Nordholz wrote: * nvi (1.79-26 = 1.81.6+debian-1) Switch from the stable branch (which has been dead for ages) to the development branch - it doesn't feel developmental though. Package has been thoroughly revised (the 1.79 series didn't even employ a patch system) at that opportunity. On Sun, 22 Jun 2008, Jan Christoph Nordholz wrote: [1]: http://www-pool.math.tu-berlin.de/~hesso/deb/nvi_1.81.6-2.dsc (again built with -sa -v1.79-26) Uploaded the most recent revision. Thanks for your work on Debian. Kapil. -- signature.asc Description: Digital signature
Re: RFS: nvi (Was Re: Multi-RFS: nvi, autofs5, mt-st)
Hello, On Thu, 12 Jun 2008, Jan Christoph Nordholz wrote: * nvi (1.79-26 = 1.81.6+debian-1) Switch from the stable branch (which has been dead for ages) to the development branch - it doesn't feel developmental though. Package has been thoroughly revised (the 1.79 series didn't even employ a patch system) at that opportunity. Mostly looks good. Warning during build: - dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/nvi/usr/bin/nview debian/nvi/usr/bin/nvi debian/nvi/usr/bin/nex were not uselessly linked against it (they use none of its symbols). I see that you have 1.81.6+debian as a repackaged source file since you have added the files: nvi-1.79/FAQ nvi-1.79/docs/changelog nvi-1.79/docs/tutorial/vi.advanced nvi-1.79/docs/tutorial/vi.beginner In view of long-term maintenance (for example if upstream goes to 1.81.7) isn't it easier to add these files in patches (which you can also send upstream). That way you do not need to repack the upstream tar ball. Does nvi support wide-chars? Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-RFS: nvi, autofs5, mt-st
Hello, On Thu, 12 Jun 2008, Jan Christoph Nordholz wrote: * nvi (1.79-26 = 1.81.6+debian-1) Switch from the stable branch (which has been dead for ages) to the development branch - it doesn't feel developmental though. Package has been thoroughly revised (the 1.79 series didn't even employ a patch system) at that opportunity. http://www-pool.math.tu-berlin.de/~hesso/deb/nvi_1.81.6+debian-1.dsc I am looking at this. However, I almost gave up since it is now: http://www-pool.math.tu-berlin.de/~hesso/deb/nvi_1.81.6+debian-2.dsc Jan, please send an updated mail when you create new versions. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: unionfs-fuse
Hello, On Fri, 20 Jun 2008, Bernd Schubert wrote: I am looking for a sponsor for my package unionfs-fuse. http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs-fuse_0.9.20-2.dsc This should have been: - http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs-fuse_20-1.dsc The copyright file is buggy: - it contains multiple versions of the same lines - it contains the complete BSD licence instead of refering to common-licenses - Please comply with section 4.2 of the Maintainer's guide There is no watch file Is there any chance that unionfs-tools can be used to manage these unionfs-fuse file systems? Regards, Kapil. -- signature.asc Description: Digital signature
Re: Sponsor for link-grammar
Hello, On Fri, 20 Jun 2008, Ken Bloom wrote: Could someone please sponsor an upload of link-grammar for me? The packages are at http://lingcog.iit.edu/~bloom/link-grammar/ Is there some reason to use this package rather than the more actively developed one (current version 4.3.5) at the URL below? http://www.abisource.com/projects/link-grammar/ Regards, Kapil. -- signature.asc Description: Digital signature
Re: Need some tips on building Debian packages
Hello, On Fri, 30 May 2008, Paul Johnson wrote: I've been asking around for help on building debian packages. changes, and all of those fiddles were getting wrapped up into the one big diff file, making it impossible to figure out who did what. One possible reason to do this is that the person/machine doing a build from source requires *no* tools other than compilers and make (and the library dependencies). In order to keep track of the patches applied, there has been a suggestion that these patches be kept inside the debian/ directory sorted by topic. (Thereby the size of the .diff.gz is roughly doubled.) A more common approach is to use debian/patches and then have the patches applied using some patch management tool. Note that in this case the build process depends on this patch management tool. And the Debian diff for the package would then pick up all the rcs files, right? dpkg-source (which is called by *-buildpackage) has the -i and -I options to ignore certain files/directories. That process creates a bunch of files that should NOT be included in the Debian diff file, such as changes in config.sub or such, but the Debian package does include those things. You can remove them in the clean target. The rule to remember is that the Debian .diff.gz will *not* track files that are removed from the upstream source during the build process. So you can safely regenerate autogenerated upstream files and then remove them if you do not want these changes to go into the diff. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Finding the origin of a binary package.
Hello, On Tue, 11 Mar 2008, Alexander Schmehl wrote: Am 11.3.2008 schrieb Charles Plessy [EMAIL PROTECTED]: I am wondering how to find the origin of a binary package: if it was built on a buildd or the machine of a developper, and in this case, who uploaded it. Well... If it was build by an buildd, it is mentioned in the build log. In any case, it can be found by examining the changes file which can be found on merkel.debian.org (only for DD's!) at /org/ftp.debian.org/queue/done/pkgname_pkgver_arch.changes Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Requests for sponsors to upload NMUs
On Tue, 04 Mar 2008, Neil Williams wrote: Note: only fix bugs that are already filed to the BTS The rest of the normal NMU rules still apply: The following quote invites other fixes as well! On Sun, 02 Mar 2008, Marc 'HE' Brockschmidt wrote: (http://lists.debian.org/debian-devel-announce/2008/03/msg1.html) Please note that in a BSP, you shouldn't just NMU every RC bug you see. While you are working on a package, check for other low-hanging fruits (like translation updates, typos that can easily be fixed, ...) and fix them in your NMU. So it would seem like *some* additional cleanup *is* permissible while NMU'ing. But HE also said: On the other hand, if you notice that a package looks unmaintained, refrain from fixing the bugs for now and try to find out if the package should be removed or adopted by another maintainer instead. There is no best answer to packages which seem un-maintained to some while the maintainer appears to feel that they are in good shape. Here is a possible order with some time-lag between these (except between 0 and 1!) 0. File bugs. 1. Put bug fixes in the BTS tagged patch. 2. Make a NMU which fixes *only* BTS bugs. 3. Offer to co-maintain the package (copy to MIA). 3alt. Suggest removal of the package. 4. Offer to adopt the package (copy to MIA). Above all be polite both in words and deed! Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: monkey
Hello, On Wed, 27 Feb 2008, Thorsten Schmale wrote: i'm not on testing - i'm using etch currently. Is that a problem? Even if you run etch you should probably have a testing/unstable copy of lintian and the various documents like policy, developer's ref and maint-guide. Of course, you should do your builds in an unstable chroot as well (probably using pbuilder). One solution to this is to have a testing/unstable chroot with a minimal install for development (lintian, pbuilder and the documents at the very least). You can use (c)debootstrap to build such a chroot. (Note that pbuilder will then create a chroot inside this chroot but that is fine of course!). Regards, Kapil. -- signature.asc Description: Digital signature
[Uploaded] RFS: syslog-summary (updated and adopted package)
Hello, On Thu, 07 Feb 2008, David Paleino wrote: I am looking for a sponsor for the new version 1.13 of the package syslog-summary, which I'm also adopting (ITA: #455005). On Thu, 21 Feb 2008, David Paleino wrote: I've fixed everything, you can find the new package at the same url as before. Uploaded. Thanks for your contribution to Debian. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: syslog-summary (updated and adopted package)
Hello, On Wed, 20 Feb 2008, David Paleino wrote: The package is now available on sourceforge.net: http://sourceforge.net/projects/syslog-summary The .dsc can be found on mentors: http://mentors.debian.net/debian/pool/main/s/syslog-summary/syslog-summary_1.13-1.dsc Could you please review it? :) Looking ... Regards, Kapil. -- signature.asc Description: Digital signature
Re: GPG key change
Hello, On Wed, 20 Feb 2008, David Paleino wrote: is there any procedure to follow in case one needs to revoke his GPG key (thus creating a new one)? I mean, I have some packages in Debian, which are signed by my current key (0x1392B174). Is it sufficient to start signing new packages with my new key? The only real reason to revoke the primary GPG key would be when there are security concerns about it like: 1. You feel that you have chosen a key size which is too small. 2. You lost your key in some way. 3. Your private key has become exposed. Otherwise, you can continue to use your GPG key forever. Note that you can add different sub-keys and different e-mail identities to your primary key so you are not stuck with using the same location information. I've also applied NM, but I'm in an early stage -- my key hasn't been involved yet. In some sense your key is already involved since (for example) the key with which you signed your packages on mentors has entered my key-ring and is used to verify newer packages that you upload to mentors. If packages now appear on mentors signed with the new keys how can I be sure that it is the same David Paleino whose excellent packages I sponsored earlier ;-) More seriously, you should think carefully about why you want to revoke your key. Regards, Kapil. -- signature.asc Description: Digital signature
Re: GPG key change
Hello David, On Wed, 20 Feb 2008, David Paleino wrote: I've somehow lost my private key for encryption. That is, I can sign anything, also encrypt, but not decrypt anything encrypted with my key. I've already added a new encryption sub-key (and works), but having lost the private part for the other subkey, I cannot revoke it. Any idea? Its a while since I played around with GPG but IIRC, the sub-keys are signed (and thus revoked) by the signing key. So having access to the signing key ought to be enough to generate a revocation certificate for an encryption key. Let me check. Regards, Kapil. -- signature.asc Description: Digital signature
Re: Bug#466550: Please clarify the get-orig-source target stated in Policy 4.9
Hello, Perhaps the following elaborate statement can be condensed (once sufficient cooling has occurred :-)) 1. Once pkg_ver.orig.tar.gz enters the Debian archive this is considered the authoritative Debian version from which all the binary Debian packages will be built (for that version of the package). A signature/checksum is used (in the upload and the Sources.gz file) so as to detect any contamination. 2. If re-packaging of upstream sources was required in order to create this .orig.tar.gz, then this should be documented in the copyright file (with some further explication in README.Debian-source perhaps). 3. Whenever upstream releases a new version, one needs to create a pkg_nver.orig.tar.gz for the newer version. In case this is merely a matter of downloading and renaming an upstream tar.gz, the uscan and uupdate programs are adequate and there is no significant need for a get-orig-source target. In the case when re-packaging has been done as in (2), it is a non-trivial convenience if these steps are automated by such a program or target. Such a program further clarifies the statements in the copyright file and the README.Debian-source file. (Program as documentation!) In the last case, someone who wishes to verify the accuracy of the statements in the copyright file may also wish to re-generate pkg_ver.orig.tar.gz to compare it with the Debian version. This can also be provided for to the extent possible. If there is any reason to suspect that the pkg_ver.orig.tar.gz was not in fact created as documented then this constitutes a bug whose severity would depend on the extent of the discrepancy. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: ee (updated package)
Hello, On Wed, 20 Feb 2008, Paul Wise wrote: On Feb 20, 2008 6:27 AM, Mauro Lizaur [EMAIL PROTECTED] wrote: It builds these binary packages: ee - An easy editor for novices and compuphobics What are compuphobics? Sounds like a word that should not be in a short description. Apparently the correct word is cyberphobic people (which could probably be shortened to cyberphobics): Cyberphobia - Fear of computers or working on a computer. (from www.phobialist.com) Though why someone who has this fear would be using an editor on a computer is not clear... Regards, Kapil. -- signature.asc Description: Digital signature
Re: In which section should go this kernel patch package (tuxonice)?
Hello, On Mon, 18 Feb 2008, Mattia Oss wrote: I'm trying to make a deb of kernel patch tuxonice[1], an alternative way to suspend-to-disk and suspend-to-ram. In which section should this package go? admin? devel? At first glance this is likely to be more than one package. There is the kernel-patch which would be in devel, the hibernate script which would be in admin and the user-interface which could be in utils. What is tuxonice: TuxOnIce is most easily described as the Linux equivalent of Windows' hibernate functionality. It saves the contents of memory to disk and powers down. When the computer is started up again, it reloads the contents and the user can continue from where they left off. No documents need to be reloaded or applications reopened and the process is much faster than a normal shutdown and start up. This description would probably not be enough. For example, as you said in your mail it is an alternative to the in-kernel suspend which is part of the stock Debian kernels and the uswsusp which is the user-space suspend which depends on some in-kernel features (again stock Debian kernel features). Both of these could be described as the Linux equivalent of Windows' hibernate functionality (sic). What will distinguish your package from these earlier ones? You should say this crisply in your package Description. Another thing is that there is already a package called hibernate which may cause a conflict with the version you are planning to package. Perhaps you should co-ordinate with that maintainer. That said, best wishes on your effort to package this functionality for Debian. Regards, Kapil. -- signature.asc Description: Digital signature
Re: In which section should go this kernel patch package (tuxonice)?
Hello, On Mon, 18 Feb 2008, Mattia Oss wrote: On Mon, 18 Feb 2008 18:42:32 +0530 Kapil Hari Paranjape [EMAIL PROTECTED] wrote: At first glance this is likely to be more than one package. There is the kernel-patch which would be in devel, the hibernate script which would be in admin and the user-interface which could be in utils. I'm trying to package only the kernel patch; the hibernate and tuxonice-userui programs are already packaged in debian. I misunderstood. So it should be devel, right? Right. I think the remaining linux-patch-* packages are in devel too! By the way, you should figure out whether your patch is compatible with the default (patched) debian linux source or it needs the upstream linux sources. It will need to be applied and compiled accordingly. Regards, Kapil. -- signature.asc Description: Digital signature
Re: In which section should go this kernel patch package (tuxonice)?
Hello, On Mon, 18 Feb 2008, Mattia Oss wrote: This is what I thought! But when I searched in the debian archive I found: linux-patch-aufs: Section: misc linux-patch-bootsplash: Section: graphics linux-patch-debian-2.6.24:Section: devel linux-patch-debianlogo: Section: devel linux-patch-evms: Section: admin linux-patch-gcov: Section: devel linux-patch-openswan: Section: net linux-patch-skas: Section: devel Interesting! It looks like my suggestion was not quite correct. It is also strange that bootsplash is in graphics but debianlogo is in devel! So admin seems to be a reasonable section as well. This patch will be compatible only with linux-source, that is the kernel with Debian patches already applied. That's nice. It means that one doesn't have to give up any of the other Debian features to obtain this feature. Regards, Kapil. -- signature.asc Description: Digital signature
Re: removal of unneeded packages installed by pbuilder
Hello,
One way to use pbuilder and avoid using aptcache is to use a
local mirroring tool as the MIRRORSITE. I use approx but YMMV.
Another way to avoid the massive file copying is to use a
BINDMOUNTS and set APTCACHE to . The tricky part is that
pbuilder's BINDMOUNTS allows you to specify the source of
the bind but not the target. So one way around this would be
to use BINDMOUNTS as /var/cache/pbuilder/${DISTRIBUTION}/aptcache.
Then you configure apt in the chroot to use this directory
as its cache directory. I had this setup until I hit upon the first
option.
Regards,
Kapil.
--
signature.asc
Description: Digital signature
Re: removal of unneeded packages installed by pbuilder
Hello, On Sun, 17 Feb 2008, Kapil Hari Paranjape wrote: Then you configure apt in the chroot to use this directory as its cache directory. I had this setup until I hit upon the first option. I forgot to say that you can use the APTCONFDIR option to give a specialised configuration for APT inside the CHROOT. Regards, Kapil. -- signature.asc Description: Digital signature
Re: Writing get-orig-source targets to conform with policy
Hello, On Sat, 16 Feb 2008, Andres Mejia wrote: Second question is regarding a get-orig-source target I have for the package mediatomb. It goes like: # Common variables used to ease maintenance of the get-orig-source target. MEDIATOMB_TARBALL = mediatomb-0.10.0.tar.gz MEDIATOMB_VERSION = 0.10.0 CORRECT_CHECKSUM = 2436c73de4ac5f3ba1575f7ee93a0430 Why have you hardcoded the version number and checksum for the tarball? The way I understand it, the get-orig-source target is used to get newer upstream sources. Policy 4.9 says: `get-orig-source' (optional) This target fetches the most recent version of the original ^^^ source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory. So your script is mainly a tool to provide an automated way for someone to get a newer version of upstream source re-packaged exactly the way you have done with the current version. If you want to document how/why you re-packaged the source for Debian, this should be in README.Debian-source. This target may be invoked in any directory, and should take care to clean up any temporary files it may have left. I think this means that you should probably run the download in a temporary directory using mktemp and then create/move the output to the directory just above the current directory. I hope this clarifies most of your questions. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: syslog-summary (updated and adopted package)
Hello, On Fri, 15 Feb 2008, David Paleino wrote: Il giorno Fri, 15 Feb 2008 09:58:34 +0530 Kapil Hari Paranjape [EMAIL PROTECTED] ha scritto: Could you please clarify the following issues: 1. The package does not seem to be Debian specific. Yet it is packaged as such. FYI: https://sourceforge.net/projects/syslog-summary/ I was going to suggest Alioth but you were too quick for me! :-) All the best for your exams.[*] Kapil. [*] As one who is essentially at the opposite end of examinations (i.e. examiner instead of examinee which is what I understood you to mean) I can assure you that they are equally painful from both ends! :-( -- signature.asc Description: Digital signature
Re: How uploaded zerofree?
Hello, On Thu, 14 Feb 2008, Thibaut Paumard wrote: someone was so kind as to upload one of my packages, zerofree (now in NEW). I'd like to be sure who that was, so I can contact them later for the next upload for instance. How can I find out? Usually, who-uploads from devscripts should provide the answer. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: syslog-summary (updated and adopted package)
Hello, On Thu, 07 Feb 2008, David Paleino wrote: I am looking for a sponsor for the new version 1.13 of the package syslog-summary, which I'm also adopting (ITA: #455005). Looks like a worthwhile package to keep going. The package can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/s/syslog-summary/syslog-summary_1.13.dsc Could you please clarify the following issues: 1. The package does not seem to be Debian specific. Yet it is packaged as such. 2. I think that you have incorporated all changes from the Ubuntu patch but please make sure! 3. What is the status of 284708? Regards, Kapil. -- signature.asc Description: Digital signature
Re: Help with watch file -- versions based on different libraries
Hello, On Wed, 13 Feb 2008, I wrote: I've been trying to write a watch file for flpsed. First of all sorry for hijacking the thread. Secondly, it is amazing how writing down one's problem makes it clear how to solve it! As far as I can see the author's logic for this somewhat bizarre numbering is the hope that by the time 0.5.x needs enough revisions to cross 0.6, everyone will be using fltk2.x anyway. Given this logic, I suppose the natural choice for the watch file would be to use 0.5.* as the pattern that needs to be matched! Thanks anyway. Regards, Kapil. -- signature.asc Description: Digital signature
Help with watch file -- versions based on different libraries
Hello, I've been trying to write a watch file for flpsed. The upstream home page is at http://www.ecademix.com/JohannesHofmann/flpsed.html This lists two versions of flpsed based on which version of the library fltk is being used. Since Debian only has fltk1.1.x at the moment, I can package only flpsed 0.5.0. However, any watch file I can cook up prefers 0.6.0 to this version. As far as I can see the author's logic for this somewhat bizarre numbering is the hope that by the time 0.5.x needs enough revisions to cross 0.6, everyone will be using fltk2.x anyway. Any solutions? Regards, Kapil. -- signature.asc Description: Digital signature
Re: Lintian: outdated-autotools-helper-file
On Mon, 11 Feb 2008, Bas Wijnen wrote: I suggest to mandate remove all generated files in the clean target (formulated in a way which includes generated by upstream, not only generated by the build target), which implies rebuild everything in the build target. With the current wording it is allowed to use shipped built files from the upstream tarball, as long as the source is present. It is even allowed to ship the build results (uuencoded, for example) in the diff.gz and use those. I suppose we all agree that this is unacceptable for normal build results. Now reread the previous paragraph while thinking of Makefile.in instead of normal build results. It is common practice to do exactly that: ship and use pre-built versions, or even ship them in the diff.gz (which then gets huge). Makefile.am is only present as source-file, but it isn't used at all during the build. Any changes the user makes will not be noticed by the build system. I'd like to hear why this exception is so important for people. Or better yet, I'd like to hear that everyone agrees with me, so we can make this change and finally to the Right Thing. :-) It is a good idea if one can use .orig.tar.gz to be the same as the upstream .tar.gz whenever it is DFSG-free to do so. One reason is that it becomes easier to verify that the .orig.tar.gz is the same --- has the same GPG signature, MD5SUM etc. Another reason (which is the same reason in disguise!) is that it is easier to see exactly what Debian is changing in the upstream source. Note that if the upstream's auto-generated files are deleted during the clean target, then the source *must* be re-packaged to avoid needless clutter in the .diff.gz which is of a negative nature. So all such source must come with a get-orig-source target and a README.Debian-source which explains the changes made. Regards, Kapil. -- signature.asc Description: Digital signature
Re: Lintian: outdated-autotools-helper-file
Hello, On Mon, 11 Feb 2008, Bas Wijnen wrote: Secondly, when the clean target removes all generated files, they are ignored when generating the diff.gz, so it doesn't actually clutter it. It does produce some warnings during make clean, but those are not a problem IMO. Oops. I'd forgotten this aspect --- files which have been deleted from the .orig.tar.gz do not show up in .diff.gz So my reason for running a proper clean is not valid and objection is withdrawn! Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: libx86 (adopted package)
Hello, On Sat, 09 Feb 2008, David Paleino wrote: You're right. Thanks for noticing this :) http://mentors.debian.net/debian/pool/main/l/libx86/libx86_0.99+ds1-1.dsc Looks like there is convergence! I'm currently away from my build machine. I'll upload as soon as I get there. Regards, Kapil. -- signature.asc Description: Digital signature
[uploaded] RFS: libx86 (adopted package)
Hello, On Wed, 06 Feb 2008, David Paleino wrote: I am looking for a sponsor for the new version 0.99-2+ds1 of the package libx86, which I want to adopt. On Sat, 09 Feb 2008, David Paleino wrote: http://mentors.debian.net/debian/pool/main/l/libx86/libx86_0.99+ds1-1.dsc Uploaded. Thanks for your work on this package. Please check http://buildd.debian.org/libx86 for further information on the results of buildd's. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: libx86 (adopted package)
Hello, Sorry for the delay in responding. I had less free time than I thought. gregor herrmann [EMAIL PROTECTED] ha scritto: So I suggest you use e.g. 0.99+ds-1 for your package. On Fri, 08 Feb 2008, David Paleino wrote: Now, after some reasoning, I believe that I should use something like 0.99+ds-1, (or 0.99~ds-1, but it results to be lesser than 0.99-1). I understand the ds part. Is there some reason why 0.99.ds1-2 was left out of the choices? This seems to be the practice for packages like sysvinit for example. The .tar.gz would then be named libx86_0.99.ds1.orig.tar.gz which is fine since it is the source which is being re-packaged by Debian. I have not yet done the rest of my review so you may want to wait a while before uploading a new version to mentors. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: libx86 (adopted package)
Hello, On Sat, 09 Feb 2008, Kapil Hari Paranjape wrote: I have not yet done the rest of my review so you may want to wait a while before uploading a new version to mentors. Since you are adding quilt, it is probably a good idea to modify/add the Makefile in a quilt patch. Once you take a decision on this and the name change please upload your file to mentors and I will upload it. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: libx86 (adopted package)
Hello, On Thu, 07 Feb 2008, David Paleino wrote: I've merged the Ubuntu patch, and mentioned it in debian/changelog: http://mentors.debian.net/debian/pool/main/l/libx86/libx86_0.99-2+ds1.dsc 2. You should perhaps request upstream author to maintain a clean tarball. I've done it, and also asked if he wants to co-maintain the package (or take it back), so as to reduce the delta between Debian and Ubuntu :) Good work. I will examine your package tonight (about 12 hours from now) and tell convey any further suggestions. Meanwhile, could you explain the logic behind the version number 0.99-2+ds1. (I suppose one could also look up policy on this but I'm being lazy!) Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: QA Upload - imlib - Two bug fixes, including RC bug
Hello, On Mon, 04 Feb 2008, Barry deFreese wrote: I've uploaded a version of imlib that fixes an important and RC bug. If someone has time to review/sponsor. Sune Vuorela wrote: On 2008-02-05, Moritz Muehlenhoff [EMAIL PROTECTED] wrote: I've uploaded a version of imlib that fixes an important and RC bug. If someone has time to review/sponsor. You should rather spend your time to get this package removed in favour of imlib2 than kept alive. Unfortunately, this is kind of blocked by kde as the kuickshow package in kde3 uses it. This is not the only one. Here are some relatively commonly used packages by that depend on imlib. icewm fvwm (uses gdk-imlib11) e16menuedit (depends on gdk-imlib11) Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libx86 (adopted package)
Hello, On Wed, 06 Feb 2008, David Paleino wrote: I am looking for a sponsor for the new version 0.99-2+ds1 of the package libx86, which I want to adopt. Thanks for this work. This package is quite important for people with laptops! Some remarks: 1. The Ubuntu package seems to have some additional patches are these relevant to Debian? 2. You should perhaps request upstream author to maintain a clean tarball. Regards, Kapil. -- signature.asc Description: Digital signature
Re: List of out-of-date packages on a given architecture.
Hello, On Tue, 05 Feb 2008, Charles Plessy wrote: So in conclusion, we have nothing else to do than hoping that the buildds will restart keeping up some day, or is it time to ask on debian-release that packages not up to date on these arches are allowed to migrate in testing anyway ? Or you could look for a suitable mips machine that could be used to help the existing buildd's! I did ask around here but no one seemed to have one. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: hashalot (updated)
Hello, On Fri, 25 Jan 2008, Adam Borowski wrote: Ok, I did this, then overwrote 0.3-5 on mentors. There's a watch file for uscan now as well. Good work. One last correction... Under the new policy apt-get installs all recommended packages by default. Moreover, Recommends: means that the package normally needs the recommended packages to do the things that the user wants done. So I think you can downgrade Recommends: cryptsetup, dmsetup to Suggests:. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
Hello, On Thu, 24 Jan 2008, Adam Borowski wrote: On Thu, Jan 24, 2008 at 09:10:11AM +0530, Kapil Hari Paranjape wrote: Has this patch been submitted upstream? Yes, albeit only a week ago. Is upstream still working on this package? The last upload seems to have been in 2004! On Thu, 24 Jan 2008, Luca Bruno wrote: I've seen that you've already found Kapil available, fine :). Luca Bruno: please consider sponsoring if you like. On Thu, 24 Jan 2008, Adam Borowski wrote: On Thu, Jan 24, 2008 at 09:25:05AM +0100, Luca Bruno wrote: Anyway your gzipped diff is 70K (almost as big as the original tarball), which seems to clash with your previous statement. Matthias Urlich enabled AM_MAINTAINER_MODE some time ago -- this stops _new_ unrequested autotoolization changes, but is a reautotooling by itself. It is indeed true that diff -ur hashalot-0.3-[45] | wc -c returns just about 5K. And these are the changes documented in the changelog. At a cursory glance it looks like this package may continue to need such large patches it it continues to be un-maintained upstream (if only for re-autotool-ing!). Is Adam willing to take up the task of being de-facto long-term maintainer of the package in this case? Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
Hello, Sorry about the delay in responding. Different time zones! On Thu, 24 Jan 2008, Adam Borowski wrote: Actually, it seems that reverting to upstream autotooling doesn't break anything (except obviously being unfriendly to those who want to update autotoolage themselves). I would need to rename a file by hand in debian/rules, that's all. Should I remove those parts from the diff? I think so. The package does not depend on anything substantial other than the C library and compiler. Updating the autotool-age should not be necessary. I notice that you have shifted the man page from section 1 (used by upstream) to section 8. Since hashalot is not just a command to be used by system administrators, I don't know why this has been done. Debian patches are small: -q for suppressing output, manpage and now the buffer overflow fix. Rather than include the manpage you should patch the upstream manpage. (Upstream seems to have included the manpage written by Matthias Ulrich at some stage but the Debian packaging hasn't taken this into account). In long-term, the package will most likely be absorbed into cryptsetup, Now that there is luks, there is some doubt about this! It's mostly there to avoid breaking people's setups. That is a very good reason indeed. Overall, it would be good if you simplified the Debian .diff.gz so that it is clear that it consists of (a) packaging (b) bug fixes to the upstream code. (Usually (b) is done by using dpatch or quilt but I won't insist on this). That way anyone wanting to utilise the code later would know exactly what parts to use. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
Hello, Some quick comments. On Thu, 24 Jan 2008, Adam Borowski wrote: * Buffer overflow on RMD160: It will cause only a crash instead of executing arbitrary code, and considering the typical usage this is nearly always harmless. Yet, in non-typical uses even wrong output can be pretty bad for a hash. A nearly-identical fix is already in Ubuntu (they move some functions around without an apparent reason). Has this patch been submitted upstream? * Vcs-Svn and Vcs-Browser. Shouldn't the Vcs-Svn entry start with svn: instead of http:? As the diff is small (except for file deletions), this shouldn't take much of your time. If someone could upload this, that would be cool. I will take a more detailed look at it. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dblatex: long term / current release 0.2.8-3
Hello, On Sat, 19 Jan 2008, Andreas Hoenen wrote: as my default sponsor recently has not found the time for sponsoring, and as he agrees I should better search another sponsor - well, here I am :-) and: To finalize my advertisement: the dblatex package is not very complicated (architecture all), with a frequency of at most one release per month. However, IMHO it's a useful and important package, being the sole DocBook-PDF tool in Debian main. And although I'm making packaging mistakes, usually I learn and avoid repeating them. My GPG key is signed by one DD, thus I'm basically connected to the web of trust. I hope to have given a picture clear enough to base a sponsoring decision upon. Thus, if someone is interested, I really would be glad. Since this package is based on python, it would probably be a good idea to ask on the debian-python mailing list. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: daloradius (updated package)
Hello, On Sun, 30 Dec 2007, liran tal wrote: Hey Richard, By the way you have sent HTML mail to the list which you should avoid. but it does bother me on some level that someone whose suppose to be a Mentor has taken such a lot of effort to discourage me from building a package (whatever it may be) and to explicitly ban it from Debian. Different mentors work differently... I did not see Neil mention banning your package from Debian. What he said was: 1. *He* would not sponsor your package. 2. In *his* opinion your statements indicate that your package may never be suitable for Debian. Other mentors *may* have a different opinion but it would be up to you to show that you have at least answered Neil's criticisms to the satisfaction of a new possible sponsor/mentor. All the best with your package, Kapil. (Who does know anything about PHP) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Finding out why a Build-Dependency is fetched.
Hello, On Thu, 20 Dec 2007, Kumar Appaiah wrote: In other words, if you specifically do not want atlas3-base-dev to be present during the build then you should put it in Build-Conflicts. I am aware, but want to avoid it. It may not be avoidable. See http://lists.debian.org/debian-devel/2007/07/msg00588.html Unless your package has the possibility of a configure option like --without-atlas, your only way to prevent atlas dependency being configured during the build is to conflict with it. Of course, it would be nice if pbuilder would avoid installing un-needed dependencies, especially when one is running the build on a small machine which does not have a very high-speed network link. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Finding out why a Build-Dependency is fetched.
Hello, On Thu, 20 Dec 2007, Kumar Appaiah wrote: Also, when I try to build the package on my machine outside a pbuilder, with the B-Deps installed, it works fine without atlas, and generates packages which don't depend explicitly on libatlas. However, the moment I try to use pbuilder on it, it fetches atlas3-base-dev for the build, and my package now depends on atlas3-base. The building of a package should not produce a different package if some additional packages not listed in Build-Conflicts are installed. In other words, if you specifically do not want atlas3-base-dev to be present during the build then you should put it in Build-Conflicts. I know that this does not explain why pbuilder is behaving the way it is but it seems to be a solution. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting created without signature
Hello, On Fri, 14 Dec 2007, iluvlinux wrote: Storing your passphrase in a file or ENV variable is never safe as told in documents and by mentors. True enough. Yet ... than here's what i found: gpg's default home dir is ~/.gunpg (you can change it using --homedir option, using this option will, upto some extent provides at-least some security as no one knows where your default directory is) create a file gpg.conf in that folder and edit it to contain text as passphrase your-passphrase ... here you are suggesting that you store the passphrase in a file! A much better option is to use the gpg agent. As far as signing packages is concerned, I would recommend that you never do this in the background. You need to verify the package *before* you sign it. Your signature on the package affirms that you have checked it as thoroughly as possible and are certifying this. So run lintian, piuparts and so on before you sign a package. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting created without signature
Hello, On Fri, 14 Dec 2007, iluvlinux wrote: but dpkg-buildpackage command asks for passphrase just before building the package (at dh_builddeb ). so how can i check it with lintian etc. Do you want that first i should build a package, check it and than use gpg separately for signing the package? Use no key --- look at the -uc -us switches to dpkg-buildpackage. Note that if you use pbuilder to build the package (which is recommended) then the package created is not signed since it is created within a chroot where your keyring is not present. Later you can sign the changes file using debsign. This is how I do things. If you work on a multi-user system then you may want to be more careful. Regards, Kapil. -- signature.asc Description: Digital signature
Re: mentors.debian.net reloading
Hello, On Fri, 26 Oct 2007, Christoph Haas wrote: That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) Perhaps this is not what your question is about but, ... One way is to use some package caching proxy like approx (which I use) to get the packages. Over time this builds itself a copy of the relevant portions of the Debian archive. Of course, since the builds are against unstable the cache gets out-of-date often but most of these caching tools are good at handling that. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: polipo (updated package)
Hello, On Thu, 11 Oct 2007, DS wrote: I am looking for a sponsor for the new version 1.0.3-1 of my package polipo. It builds these binary packages: polipo - a small, caching web proxy $ who-uploads polipo Uploads for polipo: 1.0.2-1 to unstable: Guus Sliepen [EMAIL PROTECTED] It is generally best if the previous sponsor (being the sponsor most familiar with your package) is asked first. Of course, sometimes new sponsors are required for a variety of reasons. Sponsees(?) should indicate in the RFS that they are looking for a new sponsor to replace an earlier one if that is the case. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kopete-otr 0.6-1
Hello, On Tue, 11 Sep 2007, Francesco Cecconi wrote: this is my last attempt :) You need to be more persistent than that :D All the best with your effort for which we are all grateful. Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: normalize-audio (updated package)
Hello, On Mon, 03 Sep 2007, Joachim Reichel wrote: I am looking for a sponsor for the new version 0.7.7-2 of my package normalize-audio. I haven't checked this in detail but a quick look shows additional build-dependencies: Build-Depends: debhelper (= 5), dpatch, autotools-dev, libaudiofile-dev, libmad0-dev, mpg321, vorbis-tools, flac as compared with: Build-Depends: debhelper (= 5), autotools-dev, libaudiofile-dev, libmad0-dev, vorbis-tools As far as I could see the build does not depend on mpg321, vorbis-tools or flac as no audio files are being converted during the build. Regards, Kapil. -- signature.asc Description: Digital signature
Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
Hello, On Mon, 27 Aug 2007, Luis Rodrigo Gallardo Cruz wrote: Ready. The new package at http://mentors.debian.net/debian/pool/main/s/stunnel4/stunnel4_4.20-4~2.dsc Uploading to master (via ftp to ftp-master.debian.org): stunnel4_4.20-4.dsc: done. stunnel4_4.20-4.diff.gz: done. stunnel_4.20-4_all.deb: done. stunnel4_4.20-4_arm.deb: done. stunnel4_4.20-4_arm.changes: done. Successfully uploaded packages. Please check http://buildd.debian.org/stunnel4 for further information. Regards, Kapil. -- signature.asc Description: Digital signature
debian .orig.tar.gz vs. upstream tar.gz
Hello, I got hit by this so I wanted to note it down where it might be of use to others. It *is* elementary but then ... Suppose pkg_123.45.orig.tar.gz is already in the Debian archive. To build a new version pkg_123.45-xxx of the Debian package. *Always* use the Debian version of the .orig.tar.gz by doing apt-get -d source pkg. Do *not* get the upstream .tar.gz which may have changed for some mysterious reason. Do *not* depend on a local .orig.tar.gz as it may also have changed for some other mysterious reason. Regards, Kapil. (Who is learning and so is living :) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian .orig.tar.gz vs. upstream tar.gz
Hello, On Mon, 27 Aug 2007, Neil Williams wrote: I'm confused. Is this related to the other messages in this thread or did you mean to start a new thread? I'm sorry that I posted to your thread and confused the issue. Many apologies for the hijack. On Mon, 27 Aug 2007, Neil Williams wrote: EVERY instance of repacking .orig.tar.gz needs to be explained in debian/changelog. Not just debian/changelog but README.Debian-source. However, the point of my mail was not about *how* pkg_123.45.orig.tar.gz turned out to be different from upstream's version but what to do *if* it turned out to be different. One has no control over pkg_123.45.orig.tar.gz if it is *already* in the Debian archive. This applies (e.g.) to the situation where a sponsee adopts a package. Do *not* depend on a local .orig.tar.gz as it may also have changed for some other mysterious reason. It should not have changed. It should not have changed but it may have. For example, at some point someone may have done: gunzip pkg_123.45.orig.tar.gz gzip -9 pkg_123.45.orig.tar.gz for all the wrong reasons. Or, for example, upstream may have moved the archive to a public repository, and since it was a large file did: gunzip pkg-123.45.tar.gz gzip --rsyncable pkg-123.45.tar.gz One of the reasons I started the original thread was so that I could rely on .orig.tar.gz only being downloaded once for each sponsorship run. The rule (for the sponsor) could be something like. While sponsoring a package *always* check that pkg_123.45.orig.tar.gz matches upstream. If the package is being adopted then also check the Debian archive version of pkg_123.45.orig.tar.gz. All differences must be sorted out and if necessary documented in README.Debian-source. To see some of my past mistakes coming back to haunt me have a look at par_1.52-3 and README.Debian-source in it. Regards, Kapil. -- signature.asc Description: Digital signature
Re: debian .orig.tar.gz vs. upstream tar.gz
Hello, On Mon, 27 Aug 2007, Jörg Sommer wrote: Do *not* get the upstream .tar.gz which may have changed for some mysterious reason. I don't think the upstream tar.gz have changed, but your orig.tar.gz is not the same as the upstream tar.gz. This happens if the orig.tar.gz was repacked to rename the top directory to package-version. dpkg-buildpackage -S does this as described by Policy C.4. Section C.4 describes how to unpack the source without dpkg-source not how it is repacked by dpkg-buildpackage --- at least in my local copy of debian-policy. If the upstream source package is already in the form of a .tar.gz there is little reason to repack the source. In particular, the manner in which dpkg-source unpacks the source ensures that rename the top directory to package-version is generally not a good enough reason to repack the source. For large enough packages, repacking with gzip -9 --rsyncable may be a good enough reason. (Though policy C.3 asserts that the Debian .tar.gz should *always* be gzip -9 compressed so I am probably wrong about the large enough part). In any case if this is done then it *must* be documented in debian/changelog and/or README.Debian-source. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian .orig.tar.gz vs. upstream tar.gz
Hello, On Tue, 28 Aug 2007, Kapil Hari Paranjape wrote: In any case if this is done then it *must* be documented in debian/changelog and/or README.Debian-source. The *must* in the above line is not supported by Debian policy. So I'll change that to a *should* :-) Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
Hello, On Sun, 26 Aug 2007, Luis Rodrigo Gallardo Cruz wrote: Should I upload with just the change from (1)? Yes. I agree with your reasoning. Regards, Kapil. -- signature.asc Description: Digital signature
Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
Hello, On Thu, 23 Aug 2007, Kapil Hari Paranjape wrote: Package looks fine. I'm currently updating my local pbuilder base and will upload when that is done. Unfortunately, I just realised that there are a few more changes that I think you should make! While looking through your debian/rules I found under the install rules: cd src; $(MAKE) install prefix=$(CURDIR)/debian/stunnel4/usr cd doc; $(MAKE) install prefix=$(CURDIR)/debian/stunnel4/usr ln doc/stunnel.8 doc/stunnel4.8 # Manpages will be installed by dh_installman rm -rf $(CURDIR)/debian/stunnel4/man rm -rf $(CURDIR)/debian/stunnel4/usr/man install -p -m 0644 tools/stunnel.conf-sample\ $(CURDIR)/debian/stunnel4/etc/stunnel/stunnel.conf # mv executables into /usr/bin, with propper names mv $(CURDIR)/debian/stunnel4/usr/sbin/stunnel \ $(CURDIR)/debian/stunnel4/usr/bin/stunnel4 mv $(CURDIR)/debian/stunnel4/usr/sbin/stunnel3 \ $(CURDIR)/debian/stunnel4/usr/bin/stunnel3 rmdir $(CURDIR)/debian/stunnel4/usr/sbin/ # Move docs into propper dir mv $(CURDIR)/debian/stunnel4/usr/share/doc/stunnel \ $(CURDIR)/debian/stunnel4/usr/share/doc/stunnel4 1. I think it is better to use $(MAKE) -C src and $(MAKE) -C doc instead of the cd src; $(MAKE) and cd doc; $(MAKE) constructs. 2. Since you use debhelper, I think it is better if you use debhelper's .install files to move/install files in the correct places (man dh_install). Sorry for the late realisation. Thanks and regards, Kapil. -- signature.asc Description: Digital signature
Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
Hello, On Wed, 22 Aug 2007, Luis Rodrigo Gallardo Cruz wrote: I have uploaded a new version with the suggested fixes. Following your sugestion I used 3:4.20-4~1 as version. If you consider it worthy of upload, please change it to -4. And please build with -v3:4.20-2 Thanks for pointing this (-v3:4.20-2) out or I might have forgotten! http://mentors.debian.net/debian/pool/main/s/stunnel4/stunnel4_4.20-4~1.dsc Package looks fine. I'm currently updating my local pbuilder base and will upload when that is done. I've been playing with both kinds of repositories, with and without upstream sources, in my packages, but I'm not sure yet which workflow is easier. Do you have some description on pros/cons from others, to help decide? I have moved towards repositories that contain *only* the debian/ directory. I find it easier to keep track of my own changes that way. As far as I know this is the recommended approach. It is relatively easy to setup something like debian/rules get-orig-source to get the upstream source (though I have not done this for some of my packages!). Regards, Kapil. -- signature.asc Description: Digital signature
Re: advice on maintainting packages on alioth ?
Hello, On Sat, 18 Aug 2007, Thomas Jollans wrote: In future, I would like to maintain my packages in Mercurial (or git) repositories. It seams the best place for these to be would be alioth, but I'm not sure where is the best place -- should I rather request a private sub-directory or apply for collab-maint membership and upload packages there ? I have some doubts about collab-maint though: Maintenance is unlikely to be collaborative, and I'm not in NM, which pretty much takes care of the point of collab-maint as outlined on the wiki [1]. If the package has an upstream and all that is being maintained on alioth is the packaging aspect then the simplest approach is to put things under collab-maint even if it is not being maintained collaboratively. The point is that it becomes easier: - to find co-maintainers if it becomes necessary - for people to offer patches - if the package is orphaned it is easier to take over - for upstream to figure out what you are doing to their package. Also, I'm not sure how readily private hg/git sub-directories are granted to non-DDs. If the package is in Debian or is soon going to be then you should give it a try. I've found the people at alioth quite helpful! Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
Hello, On Fri, 10 Aug 2007, Luis Rodrigo Gallardo Cruz wrote: I am looking for a sponsor for the new version 3:4.20-3 of my package stunnel4. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/stunnel4 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/stunnel4/stunnel4_4.20-3.dsc Looks nice. I have some fixes/suggestions for you. Since this would be the first package that I would sponsor, I hope we can learn from each other! General remark: === Please go through the package completely *as if* I were the person who had done the packaging and you were the person performing the sponsor-ship. Experience says that the time of adoption is probably the time when the maximum effort is/can be put into cleaning up packaging issues. Must fixes: == - The author of debian/StunnelConf-0.1.pl is not mentioned in the debian/copyright file. I have *not* checked all the files in your tree. Please check each file of the unpacked source and the debian/ directory to find relevant attributions. - Please fix the debian/copyright file. See http://lists.debian.org/debian-devel-announce/2003/12/msg7.html Specifically, one thing that *is* missing is the dates of the copyright assertion by the upstream author. - Avoid patching tools/script.sh in your diff. Use quilt instead. In fact your collab-maint repository should ideally only contain the debian/ directory. - linda complains about the empty directory /usr/share/lintian/overrides/ I am not sure what you are using overrides here for. - This changelog entry is not clearly written. * Use less cmd line args to debhelper commands in debian/rules. An alternative may be * Rewrite dh_* invocations in debian/rules. Or * Shorten dh_* invocations in debian/rules. Optional fixes: == - IMHO the README.Debian file needs better organisation. Perhaps three or four sections. One Upgrading from stunnel to stunnel4, two Sample Stunnel configurator, three Howto create Tunnels, four Howto create SSL keys for stunnel. - debian/StunnelConf-0.1.pl could perhaps be placed in /usr/share/doc/stunnel4/contrib/ as it is not a document but contributed code. - The preferred debian/changelog entry format seems to be. New maintainer. Closes: #416955. rather than Adopt package (closes: #416955). - I (have learnt to) prefer changelog entries that clearly indicate which files were changed rather than those that just describe the effect of the changes. Not sure aspects: === - I am not sure that the warnings in the doc/ directory are enough of a warning for those who have so far been using stunnel3. Since stunnel starts network tunnels through init.d or inetd someone could suffer quite a bit in the transition. We should think about this some more ... I hope some other mentor can clarify the last issue. Regards, Kapil. -- signature.asc Description: Digital signature
Re: stripping by upstream
Hello, On Mon, 13 Aug 2007, Kevin Coyner wrote: Such is the case with my packages. Upstream does strip in the Makefile. Aside from editing the Makefile using dpatch, is there anything else that is easily done to correct this? Different strokes for different folks. I got away with redefining the value of one flag which I redefined in debian/rules so I didn't require dpatch or quilt. Remember, in any case to *document* this so that mysterious breakage after upstream updates can be avoided. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Help with wrong upload
Hello, Could some mentors help me here?! I uploaded tex4ht version 20070717-1 to ftp-master.debian.org. Unfortunately, a couple of typos slipped in which make this package un-installable. I have now prepared a fixed version 20070717-2 which has been checked really properly (this time!) and uploaded. I want to avoid over-loading the mirrors because of 20070717-1 being propagated. Searching through various documentation I couldn't figure out whether there is some way I can do this. Is it enough to upload 20070717-2? Thanks and regards. Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: notifying the user about an incompatible upgrade
Hello, On Mon, 04 Jun 2007, Eric Cooper wrote: What is the best way to notify the user or administrator when a new version of a package changes the format of a configuration file in a backwards-incompatible way? These options occurred to me: Try to upgrade the user's old configuration automatically. Document it in NEWS. Print a warning on stderr. Use a debconf note. Send an email to root or some other system user. I don't think there is a generic answer. The answer would depend on the kind of service provided by the package. For example, if the package provides an important service and automatic upgradation of the old config files is likely to break, then it may even be a good idea to have the new package with a new name. Then you could keep both packages maintained for a while with a clear indication to the users that one is deprecated. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
Hello, On Fri, 13 Apr 2007, Steve Kemp wrote: Sure, I primarily thinking of pbuilder when I wrote that. Sorry! You can use unionfs wth a (pbuilder) chroot to test most things without damaging the pristine nature of the build environment. Secondly you need not run a full-fledged X server unless you are testing some accelerated X features. vncserver for example would be able to test most X-related packages. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libsbml
Hello, On Tue, 06 Feb 2007, Charles Plessy wrote: $ apt-cache show latex2html Package: latex2html Priority: optional Section: non-free/tex There are alternatives like hevea and tex4ht. Both of them work on generic LaTeX documents. Unusual uses of latex may require fine tuning to get the correct output. I maintain tex4ht and I think that its structure makes it less likely to fail than either hevea or latex2html. So if it fails to translate your document please file a bug report :-) I know of at least a couple of packages that used to depend on latex2html and have switched to tex4ht after it was found that some aspects of the latex2html license made it non-free. Regards, Kapil. -- signature.asc Description: Digital signature
