Re: RFS: gsoap (updated package)
On lördagen den 18 april 2009, Stefano Canepa wrote: Dear mentors, I am looking for a sponsor for the new version 2.7.13-1 of my package gsoap. I know this package is not lintian clean but I'm waiting for news from upstream and I'll glad if some one can upload it even with 2 lintian warnings. It builds these binary packages: gsoap - SOAP stub and skeleton compiler for C and C++ The upload would fix these bugs: 489264, 519898 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gsoap - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gsoap/gsoap_2.7.13-1.dsc * You've made a lot of changes that should be documented in debian/changelog. New upstream release and New maintainer isn't enough. * The Debian diff is huge due to the patch to remove mod_gsoap for Apache 1.3. Does it have to be removed or can you patch some Makefile so that it doesn't try to build it? Otherwise I think you should consider repacking the upstream tarball without it. * Ignore the warning about misc:Depends being unknown. You should not create debian/substvars yourself. * There's an rm -f command without arguments in debian/rules. * Build-Depends: debhelper ( 4.0.0) doesn't match debian/compat (5). * Please fetch current versions of config.guess and config.sub before running configure and remove or restore them in the 'clean' target. The old package fetched them in the 'clean' target, which is wrong. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: Taking care of existing packages
On söndagen den 30 augusti 2009, Ben Finney wrote: Thanks for addressing the questions and helping make the process clearer. Charles Plessy ple...@debian.org writes: The maintainer of bk2site has been inactive for more than one year (I just checked with the mia-query tool). The “echelon” information indicates that he posted somewhere in May 2009 a message with the ID e1m1bp9-eo...@junior, but I did not find anything in our archives, nor in Gmane or Google. Okay. In the spirit of the initial exercise and the example you posted, I've been trying to understand the procedure you recommend. Are you saying the package needs additional requests for removal, or that Luk's comment is sufficient? Is there another request for removal I've missed? If there is, where is it? A package can be removed (hinted for removal) from testing by the release managers without anyone requesting it if it's been RC buggy for too long and no packages (in testing) depend on it (if it's extremely buggy and not too many or too important packages depend on it I guess those can be removed too). A package can be removed from unstable after someone files an RM bug against the ftp.debian.org pseudopackage. It will then automatically disappear from testing, again once no packages in testing depend on it. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: RFS: kio-ftps (updated package)
On torsdagen den 16 april 2009, Paul Wise wrote: 2009/4/16 Laurent Léonard laur...@open-minds.org: So .dfsg is a bad suffix ? And +dfsg should be used in priority ? If 1.2+dfsg/1.2-dfsg/1.2dfsg sort before 1.2.1 why are there different suffixes ? I don't find clear informations about that on the Debian policy... Yes (but not very), yes (or the others), the versions are chosen by people and people don't think alike. I think I prefer the plus variant but I'm not fully sure why. Perhaps the -dfsg-1 might get confused with a Debian version somewhere and perhaps the plus makes it more clear that the version is modified. The hyphen, just like the hyphen that separates the Debian revision from the upstream version, nicely indicates that dfsg is not part of the upstream-designated version number, although it's technically part of the upstream version. The drawback is that - is, somewhat counter- intuitively, greater than +. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: Dash and dot in package version
On lördagen den 16 maj 2009, Felipe Sateler wrote: When adding a dfsg or whatever suffix, always use ~ to avoid problems like the one Jan pointed out. So your version would be 2.2~rc3~dfsg1, and then you bump to 2.2~rc3+hg123~dfsg1. However, that won't work if you have already uploaded e.g. version 1.2-3 of a package, and then somebody files a bug that the tarball contains some non-free file, and you'd like to upload 1.2~dfsg-1 to fix it without waiting for a new upstream release. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: debian/copyright verbosity
On tisdagen den 14 april 2009, Ben Finney wrote: Matthias Julius li...@julius-net.net writes: Would it be acceptable to condense this to: Files: foo.c bar.c Copyright: 2006, 2008 Mr. X License: GPL2+ Files: baz.c Copyright: 2005 Mr. Y License: GPL2+ or even further to: Files: *.c Copyright: 2006, 2008 Mr. X Copyright: 2005 Mr. Y License: GPL2+ Neither of these are true statements of the copyright; you have *altered* the copyright claim so that it now makes a false claim (e.g., you now state that ‘bar.c’ is “Copyright 2006 Mr. X”, which is contrary to what the original source claims). I don't think it's acceptable to make false copyright claims in the ‘debian/copyright’ file. I think it's acceptable and the only practical solution. It's far better to over-attribute than to under-attribute. If someone wants to reuse only some parts of the code, and perhaps ask the authors for permission to use the source in a proprietary product, they can read the copyright statements of the individual files. But there is no guarantee that those are complete, and *we* certainly can't guarantee that. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: Building localy
On måndagen den 23 mars 2009, Jaromír Mikeš wrote: Od: tony mancill tmanc...@debian.org Can somebody help me with this error please? $ sudo dpkg-buildpackage -S is runnig fine... $ sudo dpkg-buildpackage -nc giving me this error Any reason you're using sudo instead of -ffakeroot? No I will use -fakeroot You don't even need -rfakeroot; dpkg-buildpackage uses fakeroot by default (since Etch, I think). -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: RFS: mpview
On torsdagen den 26 mars 2009, Michal Čihař wrote: Dne Thu, 26 Mar 2009 15:21:29 +0100 Adam Ziaja a...@ziaja.name napsal(a): The package appears to be lintian clean. It does not: I: mpview source: debian-watch-file-is-missing W: mpview source: dh-clean-k-is-deprecated W: mpview source: out-of-date-standards-version 3.7.3 (current is 3.8.1) Hang on a second. When does mentors.d.n put The package appears to be lintian clean in the RFS template? When lintian reports no errors or warnings, or as soon as there are no errors? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Lintian clean? (was: Re: RFS: mpview)
On lördagen den 2 maj 2009, Dmitrijs Ledkovs wrote: 2009/5/2 Magnus Holmgren holmg...@debian.org: On torsdagen den 26 mars 2009, Michal Čihař wrote: Dne Thu, 26 Mar 2009 15:21:29 +0100 Adam Ziaja a...@ziaja.name napsal(a): The package appears to be lintian clean. It does not: I: mpview source: debian-watch-file-is-missing W: mpview source: dh-clean-k-is-deprecated W: mpview source: out-of-date-standards-version 3.7.3 (current is 3.8.1) Hang on a second. When does mentors.d.n put The package appears to be lintian clean in the RFS template? When lintian reports no errors or warnings, or as soon as there are no errors? I think it's not running lintian at all, that text is just boilerplate which assumes mentees did run lintian. Of course; mentors.d.n doesn't build anything, for obvious reasons. Seems to me that that assertion should be omitted until someone implements a step where mentees have to confirm that they have indeed run lintian and that it didn't report any errors or warnings. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: simultaneous installation lib and lib-mpi
On torsdagen den 26 februari 2009, Gerber van der Graaf wrote: I came across this problem when packaging my own libgpiv3 / libgpiv-mpi3 (recently accepted and uploaded). These libraries are used by the other packages gpivtools / gpivtools-mpi from a single upstream source (not yet available on Deb). When testing the packaging of gpivtools(-mpi) with pbuilder it only can be done if libgpiv3 and libgpiv-mpi3 are to be installed simultaneously. Otherwise the building of one of the packages gpivtools / gpivtools-mpi is impossible. While working on the packaging of gpivtools(-mpi) I am getting across a similar problem with other libraries that are available in seriel and -mpi (libhdf5-serial-dev libhdf5-openmpi-dev to be more specific). Only one of these can be installed at once. As I also work with Paraview, which depends on libhdf5-openmpi, packaging and the use of gpivtools (that depends on libhdf5-dev) is impossible. (It is preferred to have the dependancy on libhdf5-dev, even in gpivtools-mpi as the .h5 files are quite small and don't need to be stored/retrieved in parallel way.) My question is why isn't it possible to package such libraries in a way they can be installed simultaneously? Am I doing something wrong here? If not, a suggestion might be to provide this possibility by filing a 'feature request' bug against all -mpi libraries. If this really is a weak point in packaging such libs, shouldn't it become a formal packaging policy? There are more examples, such as cyrus-sasl2, which contains two Kerberos GSSAPI modules, one using MIT Kerberos 5 and one using Heimdal. But because those libraries can't be installed simultaneously, there is a separate source package, cyrus-sasl2-heimdal, with a copy of the upstream tarball, which only builds the Heimdal module packages. Currently I don't think there is any other solution to this problem, and solving it for real would require rather serious changes to how packages are built, but it might still be meaningful to bring it up on -devel, which I've done now. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: Added requirement for translation of debconf templates
On söndagen den 18 januari 2009, Neil Williams wrote: Every time the debconf templates change, I expect the RFS to include a link to the call for translations sent to the debian-i18n mailing list (use podebconf-report-po for that support) and include a statement that the upload to Debian must wait until after a new upload is made to mentors after the translation deadline has passed. The deadline must be more than 10 days and should be between two and three weeks. Packages that use debconf should not expect to be uploaded until a call for translations has been made and the deadline for that call has expired. So, new strings should be translated from the start. I guess that's a good thing. Even when templates do not change, I expect to see some evidence that new translations are being sought on a fairly regular basis (at least annually, preferably bi-annually) and that incomplete translations are being pursued via the relevant language team and/or debian-i18n. If the debconf templates have not changed, I expect the RFS to include a statement to this effect. But we have http://www.debian.org/international/l10n/po-debconf/, which shows the translation status for every package. Is there any point nagging the translation teams also? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: lintian complaining about modified files
On onsdagen den 19 november 2008, Andreas Tscharner wrote: I use the dpatch system to make the requested changes in the sources (only 1 dpatch changing only one source file). Now lintian complains that config.guess and 1 more are changed, but not by dpatch. I suppose that these files get changed in the build process. What is the correct way to get this problem solved? You can simply gunzip /usr/share/doc/dpatch/examples/dpatch/01_config.dpatch.gz and put it in debian/patches (and list it in 00list) and it will take care of things. -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Re: RFS: nemesis (updated package)
On torsdagen den 18 september 2008, Noel David Torres Taño wrote: Epochs often cause more problems than they solve, one should not use them too lightweight, as you will never be able to get rid of them again. That 1.4 is after 1.32 (and not 28 releases before) means that upstream seems to use some strange numbering sheme based on decimal fractions. There are good chances this will happen again in the future, so instead of using an epoch, normalizing that to usual natural numbers by making that a 1.40 could have expressed the situation more clearly (and avoid similar problems in the future). But alas, it is to late, the epoch is in the archive, it can never ever go away now... I agree, I see now that problem is the epoch Maybe a package renaming would eliminate epoch? Renaming the package can be used to get rid of the epoch, but will necessitate a transitional package (with a different version number than the new real package), so if you don't have a better reason for renaming it's definitely not worth it. You shouldn't be afraid of epochs, but it would be a bit silly if you had to increment it each time upstream releases a new one-digit minor version, so I suggest that you try to convince upstream that version strings aren't decimal numbers and that subsequent releases should be called 1.4.1, 1.4.2 and so on. (If you succeed you might try to convince Donald Knuth next. :-) -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
On måndagen den 23 juni 2008, George Danchev wrote: On Monday 23 June 2008, Cyril Brulebois wrote: George Danchev [EMAIL PROTECTED] (22/06/2008): In order to shorten my appendix with one line I decided on key ID only instead, which is enough for public key diggers. Even shorter: Sign your mails. Bleh 3 words 3 failures ;-) is it really so hard to realize that these hints are for people who don't have my public key at hand and want to dig it up somehow. If you sign your mail, the recipients' mail software can automatically fetch the key, like mine does. I also disagree that signed mails are shorter, and you would probably that I don't have my secret key at hand any time I post to mailing lists. The body that we see is shorter. Either way it's not a big deal. -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Re: bits from the DMs/NMs/AMs?
On tisdagen den 4 mars 2008, Paul Wise wrote: If you are in NM, a DM, an AM, just having packages sponsored by DDs or maybe recently became a DD, I'd love to hear from you. My AM, Santiago Ruano Rincón (santiago), recently submitted his report to the DAMs, and I thank him for his work. I think the procedure was relatively smooth, but I'm getting a bit worried looking at the queue for DAM approval and the New Maintainers list. The last time a new account (actually, 26 accounts in that batch) was created was on 12 December. Some of the applicants then had waited almost 6 months for DAM approval after the completeness check, and then another 1-3 months for the account to be created. Right now one applicant has waited 8 months for DAM approval, but that may be due to reasons not documented in the DAM/FD Comments section. The DAMs are of course very busy and I don't doubt that they are doing their best processing applications carefully. However, I'm wondering if there might be reason to change some priorities, considering that getting new Developers approved as quickly as possibly (without sacrificing quality), hence increasing manpower, ought to mean time well invested. Also, I note that by getting as far as being recommended by my AM, I should fulfil all the requirements of becoming a DM: * As part of PP, I have digitally signed a statement that I agree to the social contract, the DFSG, and the DMUP, * I have an Advocate and a recommendation by my AM, * my AM has checked that my PGP key is signed by at least one DD. therefore I think that everyone who has got to the DAM approval stage should automatically (or semi-automatically) gain DM status. Earlier steps of the NM and DM procedures could also be integrated. -- Magnus Holmgren[EMAIL PROTECTED] / [EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans signature.asc Description: This is a digitally signed message part.
Package clobbering
A quick question I dare not ask -devel: When a certain version of a certain binary package has been uploaded to unstable, can a lower version be uploaded after the offending version has been removed by the FTP masters, or is it absolutely necessary to add an epoch? Normally, when uploading the wrong version of your own package, you'd use the epoch, but in this particular case a package, dkim-milter, was allowed through NEW despite building a binary package of the same name as one from a similar but unrelated package, libdkim. (The offending binary packages were later renamed.) See http://packages.debian.org/sid/libdkim-dev for the resulting mess. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans signature.asc Description: This is a digitally signed message part.
Re: Package clobbering
On söndagen den 27 januari 2008, Neil Williams wrote: On Sun, 2008-01-27 at 17:27 +0100, Magnus Holmgren wrote: A quick question I dare not ask -devel: Don't be scared of -devel (it's usually -private or -policy where the real flamefests happen). :-) It's not that I'm afraid of -devel, it's just that I thought that this particular question might be to basic to ask there. -- Magnus Holmgren[EMAIL PROTECTED] Note: No Cc of list mail needed, thanks signature.asc Description: This is a digitally signed message part.
Re: ITA: libdbi + libdbi-drivers (updated packages)
On onsdagen den 24 oktober 2007, Thomas Goirand wrote: I am looking for a sponsor for the new version 0.8.2-1 of my package libdbi and for for the new version 0.8.2-1-1 of my package libdbi-drivers. [...] I've been searching for the bug number that announce that the package is orphaned, but sorry, I can't find it any more in my (huge) mail log. Did you look at http://www.debian.org/devel/wnpp/orphaned ? You should take ownership of http://bugs.debian.org/24 and http://bugs.debian.org/25. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) signature.asc Description: This is a digitally signed message part.
RFS: lsh (updated package)
Dear mentors, I am looking for a sponsor for the new version 2.0.4-dfsg-1 of our package lsh. It builds these binary packages: lsh-client - Secure Shell v2 (SSH2) protocol client lsh-doc- Secure Shell v2 (SSH2) client / server / utilities documentation lsh-server - Secure Shell v2 (SSH2) protocol server lsh-utils - Secure Shell v2 (SSH2) protocol utilities This is my third attempt at finding a sponsor for this package (maybe using mentors.d.n will increase my chances...). As I've explain previously, I've communicated with the current maintainers and they're pretty OK with me as a co-maintainer, but after the initial email exchange (three months ago) they've shown next to zero interest. Sure, almost everybody uses OpenSSH today, but I think LSH still deserves to exist. The package appears to be lintian clean. Note however that I've made some rather big packaging changes, as well as renaming the source package (from lsh-utils - the question I still haven't got the answer is whether the PTS will be confused by the fact that there is a different lsh still in oldstable) and the -doc package (from lsh-utils-doc - I didn't make a transitional package since I didn't think it's that important for a documentation package). Also, the package is not exactly the same as at the time of my previous RFS - I went ahead with some more restructuring that I had planned. The upload would fix these bugs: 340354, 408490, 412138, 417426, 421108, 422199 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/lsh - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/l/lsh/lsh_2.0.4-dfsg-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) signature.asc Description: This is a digitally signed message part.
Re: RFS: pyscrabble
On tisdagen den 2 oktober 2007, Piotr Ożarowski wrote: First of all: well done! Consider joining PAPT[1] and moving your package there Thanks! Comments: * You still need python-setuptools in Build-Depends, I know that you've patched setup.py to not use pkg_resources, but clean-patched rule doesn't depend on patch (test it in pbuilder and you'll know what am I talking about) *bonk* I think the most natural solution is to let clean-patched depend on the patches being applied, as the name of the target suggests. * If you start server twice in a row, you cannot stop it later (pyscrabble-server.pid contains wrong PID, start-stop-daemon should handle this, but apparently it doesn't) Always this problem with script daemons, where /proc/pid/exe isn't the program you started. I've solved it with --startas now. When I was at it, I also LSBized the init script. I also improved the README.Debian for pyscrabble-server, explaining why the log isn't automatically rotated, and then I added -r to the dh_installinit call for the same reason. Finally I fixed the bug that the Close button in the About dialog didn't work. An updated package has been uploaded to mentors.d.n. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) signature.asc Description: This is a digitally signed message part.
RFS: pyscrabble
Dear mentors, I am looking for a sponsor for my package pyscrabble. * Package name: pyscrabble Version : 1.6.2-1 Upstream Author : Kevin Conaway [EMAIL PROTECTED] * URL : http://pyscrabble.sf.net/ * License : GPLv2 Programming Lang: Python Section : games It builds these binary packages: pyscrabble - a multiplayer scrabble implementation written in Python - client pyscrabble-common - a multiplayer scrabble implementation - common files pyscrabble-server - a scrabble implementation written in Python - server part The package has been rather meticuously split in three, primarily in order to keep the dependencies of the client package down. The upstream source wasn't written with this in mind, so it's not too pretty, but python-central seems to handle it well. The server is patched to work as a system daemon (by default started under a dedicated uid, of course). The package appears to be lintian clean. No wait. It is free from lintian errors, but the mentors template seems to leave out the warnings. There are two binary-without-manpage warnings, which I intend to remedy eventually (lazy upstream! :-). It is possible that this package should be put in experimental initially. All review efforts are appreciated. I'm aware that the author has just put the GPLv2 in the tarball as LICENSE.txt, but not explicitly stated that it's the license that applies to the work. I have contacted the author about this. Finally, there may be a trademark issue, but maybe that should be left to the ftpmasters to decide. The upload would close the ITP: http://bugs.debian.org/416137 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pyscrabble - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/p/pyscrabble/pyscrabble_1.6.2-1.dsc I would be glad if someone checked and perhaps even uploaded this package for me. Kind regards, -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) signature.asc Description: This is a digitally signed message part.
Re: RFS: lsh (formerly lsh-utils) (new version: 2.0.3-1) -- SSH2 server and client
Since I still haven't get any feedback from the current maintainers (they seem
to lack time or interest, unfortunately), I'm again looking for someone
willing to review, endorse, and sponsor my changes.
LSH is an implementation (client and server) of the SSH protocol, version 2.
It is written by Niels Möller and predates OpenSSH.
The URL of the DSC is:
ftp://ftp.kibibyte.se/debian/pool/main/l/lsh/lsh_2.0.3-1.dsc
For reference, my previous post follows:
On Sunday 27 May 2007 13:27, Magnus Holmgren wrote:
Hello, mentors!
Even though I don't really want to, I'm looking for a mentor to upload the
new version of lsh that I've prepared.
I've been in contact with its current maintainers (three weeks ago), and
they didn't mind me co-maintaining it. Three days later I mailed them my
changes, but I still haven't heard a word despite two additional pings, the
second one sent this Monday.
Technical question: Will things get messed up by renaming the source
package now? The old lsh (the light or baby shell lsh) is still in
oldstable - do we have to wait until sarge is archived?
Here is the changelog entry:
* New upstream release (Closes: #422199)
- Drop 01_fix_manpages.dpatch; incorporated upstream.
* New co-maintainer added.
* Rename source package lsh, as the previously clashing package is
gone (Closes: #340354).
* Drop the tarball-in-tarball format and ship a normal .orig.tar.gz.
- Drop 02_fix_perms.dpatch.
- Add some extra cleanup in debian/rules.
* Increase Standards-Version to 3.7.2. No changes needed.
* Fix spelling error lshc and its manpage (Closes: #417426).
* Put some more docs in the packages: README and ChangeLog is now in all
packages, AUTHORS in lsh-utils. Update debian/copyright to refer to
/usr/share/doc/lsh-utils/AUTHORS (Closes: #421108).
* debian/control: Use ${binary:Version} substitution variable instead of
${source-version}.
* Review Build-depends: Drop patchutils, dpatch (temporarily),
comerr-dev (redundant), po-debconf (redundant), xutils (makes no
difference); add autotools-dev, scsh-0.6 (as alternative to
guile-1.6).
--
Magnus Holmgren[EMAIL PROTECTED]
(No Cc of list mail needed, thanks)
Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack) -- Dave Evans
pgpDWOZelrOyN.pgp
Description: PGP signature
Re: Nagios version
On Friday 20 July 2007 22:53, Christoph Haas wrote: David, please use your real email address. workaround.org is a domain hosted by myself and I'm pretty positive I didn't give you a freedotfr hostname in that domain. Dudu obviously sent a mail with an unqualified address in the From: field, which your mail server (and mine) qualified with the local domain. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgpF4zIDYN9Mg.pgp Description: PGP signature
RFS: nettle -- a low level cryptographic library (new versions)
Greetings mentors, I'm looking for a sponsor to upload two new versions (unstable and experimental) of nettle, a low level cryptographic library. Package files can be found in ftp://ftp.kibibyte.se/debian/pool/main/n/nettle DSC is ftp://ftp.kibibyte.se/debian/pool/main/n/nettle/nettle_1.15-2.dsc and ftp://ftp.kibibyte.se/debian/pool/main/n/nettle/nettle_1.16~cvs20070603-1.dsc. nettle (1.16~cvs20070603-1) experimental; urgency=low * Upstream CVS snapshot splitting off public-key algorithms as libhogweed1. - Drop 10_cleanup.dpatch; incorporated upstream. - Rename libnettle-dev as nettle-dev. * No longer install sexp-conv as an alternative; conflict with lsh-utils ( 2.0.3-2, which is anticipated to stop shipping an identical sexp-conv and depend on nettle-bin instead). * Link with --as-needed to avoid unnecessary NEEDED tags. -- Magnus Holmgren [EMAIL PROTECTED] Wed, 06 Jun 2007 15:28:29 +0200 nettle (1.15-3) unstable; urgency=low * Use dh_install instead of dh_movefiles. * Run make check by default. * Ship nettle.pdf in libnettle-dev. * Include PDF and Info formats in doc-base control file. * Clean up the libnettle-dev examples directory. There should only be source files. Note that most of the examples aren't made to be compiled outside of the nettle source tree, except sha-example.c, which is the example found in the documentation. * Move descore.README and TODO from libnettle2.docs to libnettle-dev.docs, and also add README and NEWS to the latter. * Make debian/copyright more correct. * Add pkcs1-conv to nettle-bin package description. -- Magnus Holmgren [EMAIL PROTECTED] Wed, 06 Jun 2007 14:35:13 +0200 I'd be happy it if someone would upload this package for me, and even more so if someone would accept to sponsor it in the future (updates are quite rare). Long description: Nettle is a cryptographic library that is designed to fit easily in more or less any context: In crypto toolkits for object-oriented languages (C++, Python, Pike, ...), in applications like LSH or GNUPG, or even in kernel space. It tries to solve a problem of providing a common set of cryptographic algorithms for higher-level applications by implementing a context-independent set of cryptographic algorithms. In that light, Nettle doesn't do any memory allocation or I/O, it simply provides the cryptographic algorithms for the application to use in any environment and in any way it needs. -- Magnus Holmgren[EMAIL PROTECTED] / [EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpjkGcMRBm9X.pgp Description: PGP signature
Re: RFS: nettle -- a low level cryptographic library (new versions)
On Thursday 07 June 2007 00:13, Jens Peter Secher wrote: On 6/6/07, Jens Peter Secher [EMAIL PROTECTED] wrote: On 6/6/07, Magnus Holmgren [EMAIL PROTECTED] wrote: I'm looking for a sponsor to upload two new versions (unstable and experimental) of nettle, a low level cryptographic library. I will take a look at it. Thanks. WRT 1.15-3: There are two manpages missing: nettle-lfib-stream, pkcs1-conv. There does not seem be any documentation for these programs anywhere. I know. They are a bit mysterious, actually. I'll fix it eventually, with some help from upstream. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpzkW0n3BZMd.pgp Description: PGP signature
Re: package name conflicts with oldstable [was: RFS: lsh...]
On Sunday 27 May 2007 18:49, The Fungi wrote: I'm in a similar situation with the weather-util package. Upstream (also me) releases it as just weather and the package installs a command line utility /usr/bin/weather (though a weather-util symlink is added so as not to confuse people who assume package name == what you run). The only reason I packaged it as weather-util is that there's already a completely unrelated weather package in sarge/non-free (interactive fiction data in the games section). The difference is that in your case the other source package is called if-transition, so there should be no technical reason stopping you from renaming your package weather. Only perhaps that weather may be too generic a name. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpB31nAkoj9W.pgp Description: PGP signature
Re: RFS: lsh (formerly lsh-utils) (new version: 2.0.3-1) -- SSH2 server and client
On Sunday 27 May 2007 13:27, Magnus Holmgren wrote: Even though I don't really want to, I'm looking for a mentor to upload the new version of lsh that I've prepared. Oh, and here is the DSC URL: ftp://ftp.kibibyte.se/debian/pool/main/l/lsh/lsh_2.0.3-1.dsc -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp7R1WsFkrol.pgp Description: PGP signature
RFS: lsh (formerly lsh-utils) (new version: 2.0.3-1) -- SSH2 server and client
Hello, mentors!
Even though I don't really want to, I'm looking for a mentor to upload the new
version of lsh that I've prepared.
I've been in contact with its current maintainers (three weeks ago), and they
didn't mind me co-maintaining it. Three days later I mailed them my changes,
but I still haven't heard a word despite two additional pings, the second one
sent this Monday.
Technical question: Will things get messed up by renaming the source package
now? The old lsh (the light or baby shell lsh) is still in oldstable - do
we have to wait until sarge is archived?
Here is the changelog entry:
* New upstream release (Closes: #422199)
- Drop 01_fix_manpages.dpatch; incorporated upstream.
* New co-maintainer added.
* Rename source package lsh, as the previously clashing package is
gone (Closes: #340354).
* Drop the tarball-in-tarball format and ship a normal .orig.tar.gz.
- Drop 02_fix_perms.dpatch.
- Add some extra cleanup in debian/rules.
* Increase Standards-Version to 3.7.2. No changes needed.
* Fix spelling error lshc and its manpage (Closes: #417426).
* Put some more docs in the packages: README and ChangeLog is now in all
packages, AUTHORS in lsh-utils. Update debian/copyright to refer to
/usr/share/doc/lsh-utils/AUTHORS (Closes: #421108).
* debian/control: Use ${binary:Version} substitution variable instead of
${source-version}.
* Review Build-depends: Drop patchutils, dpatch (temporarily),
comerr-dev (redundant), po-debconf (redundant), xutils (makes no
difference); add autotools-dev, scsh-0.6 (as alternative to
guile-1.6).
--
Magnus Holmgren[EMAIL PROTECTED]
(No Cc of list mail needed, thanks)
Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack) -- Dave Evans
pgpK4SmTo9vcY.pgp
Description: PGP signature
Done: RFS: nettle (1.15-2) -- a low level cryptographic library
On Wednesday 16 May 2007 20:35, Magnus Holmgren wrote: I'm looking for a sponsor to upload a new version of nettle, a low level cryptographic library. The upload would fix the serious bug #415034. vorlon took care of this. Thanks. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpi8YAdz2tDJ.pgp Description: PGP signature
RFS: nettle (1.15-2) -- a low level cryptographic library
Greetings mentors, I'm looking for a sponsor to upload a new version of nettle, a low level cryptographic library. The upload would fix the serious bug #415034. Package files can be found in ftp://ftp.kibibyte.se/debian/pool/main/n/nettle DSC is ftp://ftp.kibibyte.se/debian/pool/main/n/nettle/nettle_1.15-2.dsc * Fix serious regression: The -lgmp added in 1.8-1 fell off in 1.15-1 (Closes: #415034). * Use dpatch to handle patches. * Make package binNMUable. * Add XS-Vcs-* fields to debian/control. * Make dependencies on libnettle2 versioned. It's possible that urgency=high isn't warranted. None of the packages already in testing seem to be affected, and introducing dpatch is perhaps not to be taken lightly, but I've tested carefully. I'd appreciate it if someone would upload this package for me, and even more so if someone would accept to sponsor it in the future (updates are quite rare). Long description: Nettle is a cryptographic library that is designed to fit easily in more or less any context: In crypto toolkits for object-oriented languages (C++, Python, Pike, ...), in applications like LSH or GNUPG, or even in kernel space. It tries to solve a problem of providing a common set of cryptographic algorithms for higher-level applications by implementing a context-independent set of cryptographic algorithms. In that light, Nettle doesn't do any memory allocation or I/O, it simply provides the cryptographic algorithms for the application to use in any environment and in any way it needs. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp5SzAs41VBj.pgp Description: PGP signature
Re: bugs on specific arch
On Thursday 10 May 2007 17:09, Thierry Randrianiriana wrote: I have 2 bugs only on alpha and ia64 and I don't have these arch. I need help to debug these bugs on these machines :) what can I do? Thanks in advance ! Did you read and compare the buildd logs from all architectures? http://bugs.debian.org/415638 The same error (Expected X11 driver: /usr/lib/gnuplot/gnuplot_x11) appears on all or most architectures, but is fatal only on arm, ia64, powerpc, and hppa. The error message comes from term/x11.trm, and is provoked when running make -C docs/psdoc. The Makefile there runs $(top_srcdir)/src/gnuplot ps_symbols.gpi, and my guess is that something goes wrong there. http://bugs.debian.org/410565 Seems that you already fixed this, right? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpiAzTLz3xtD.pgp Description: PGP signature
Re: Copyright issues GPL-PHP license
On Sunday 06 May 2007 20:49, Mike Hommey wrote: On Sun, May 06, 2007 at 08:29:37PM +0200, Thijs Kinkhorst [EMAIL PROTECTED] wrote: On Sunday 6 May 2007 20:23, David Paleino wrote: Why? And a web server written in awk, then? Is that of any real-world use? I've seen implementations of that on the Internet. I admit that this is not enough reason to package it though. There's even one in Postscript. What about packaging it ? http://bugs.debian.org/185958 http://www.godisch.de/debian/pshttpd/ -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpIQ3D6nYTJM.pgp Description: PGP signature
Re: please, review and enhance How to split a package into several smaller packages
On Sunday 29 April 2007 16:08, André Felipe Machado wrote: I am studying Debian packaging (someday I will ask for a sponsor and start the nm process) and some time ago realized a lack of documentation about spliting a package into multiple binaries. Since them, collected many hints and links, by searching net and from mentors, and now wrote a small how-to at the wiki. Please, review and enhance the page http://wiki.debian.org/PkgSplit Actually, I think your example is unnecessarily complicated. In most cases, one can simply let make install do its job with DESTDIR=$(CURDIR)/debian/tmp, call dh_install with --sourcedir=debian/tmp, make sure that all the debhelper installation list files in debian/ (install, docs, examples, manpages etc.) are named $package.$type (package1.install, package2.docs etc.), and, *if* the source packages builds arch-specific *and* arch-independent packages, that the debhelper scripts called from the binary-indep and binary-arch targets are called with -i and -a, respectively. There's generally no need for one target per binary package (unless one wants to do away with *all* the list files), and generally just one install target. Although it's nice if one can run, say, debian/rules binary/package1 to build just package1, that's not required. All tips and tricks beyond the basic level should be presented separately, IMHO. The dpatch section seems to be outside the scope of your tutorial. There's nothing about dpatch that makes it particularly better suited for multi-binary source packages, and nothing in that text is specific to this kind of packages. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgpvVKx1xEnkG.pgp Description: PGP signature
Re: make or $(MAKE) ?
On Saturday 07 April 2007 13:36, Charles Plessy wrote: As one of the program I package was recently automakified, I had to change debian/rules to deal with this. While comparing with other packages, I realised that often $(MAKE) is used instead of make in debian/rules. In case of trivial packages which do not seem to expect something fancy from the enviroment, are both commands equivalent ? Reading the documentation, the difference between make and $(MAKE), apart from the obvious difference when $(MAKE) is set to something other than make, is that using $(MAKE) ensures that the --touch, --just-print, and --question options work as you'd want them to, namely by recursively calling $(MAKE) despite the fact that those options mean that no commands actually be executed. Thus, in normal build invocations the difference doesn't matter, but it helps with some manual uses. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpEjTBAWJpNz.pgp Description: PGP signature
Re: where find multiple packages from one source guide
On Tuesday 03 April 2007 19:07, andremachado wrote: I am trying to create a multiple binaries debian package. Unable to find enough documentation at policy, maintainers guide and site. Examined some source packages and then found clamav, that seems to leverage debhelper. Tried to modify my previous monolithic package to split. But found some weird things. It's not too hard. Read the manpages for the debhelper commands and learn what the -i, -a, and -ppackage parameters do. For clarity, create one .install file, one .docs file etc. per binary package. A file named just install or docs, without a package name, applies to the first package in debian/control. I don't think it's good packaging style to mix file-lists-in-files and file-lists-on-commandline too much (except for specifying the upstream changelog name to dh_installchangelogs). But if you do specify files to install on the command line, dh_install* will generally operate on the first package specified. 1- why the dh_install java.ini mono.ini etc/php5/conf.d line cross rule limits when in multiple packages Found that must be one file and one dest per line. dh_install java.ini mono.ini etc/php5/conf.d should work. Can you explain more what happens when you try? 2- unable to find yet documentation about phony rules not having - character in name. Maybe I misunderstood or did not read some fine print. That shouldn't be a problem either. 3- why -p$@ sometimes is needed sometimes is not. the lintian seems to not catch this thing. If I use -p$@, do I need to create the package_name.dir, .docs, .install files. obscure for me. Is there documentation. I think clamav might be unnecessarily complicated as an example. It has one make target per package, which explains the [EMAIL PROTECTED] The reason it's not on all the debhelper command lines has to do with what the various debhelpers *do*. Please read the manual pages (man debhelper, man dh_install, man dh_checkroot etc.). But usually you just need two targets: binary-arch and binary-indep. In the binary-arch target, all the debhelpers should be called with -a, and in the binary-indep target they should be called with -i. Please, examine the /debian directory of http://php-java-bridge.cvs.sourceforge.net/php-java-bridge/php-java-bridge/ debian/ First, I don't think the -docs packages contain any architecture-specific files. At least they shouldn't. Thus they must have Architecture: all in debian/control. Second, you should remove all the unneeded, commented-out debhelper commands. And third, if you put the lists of files to install in files instead of on the command line, you only need two targets and debian/rules becomes cleaner (on the other hand, providing a way to build just a single binary package, just compiling exactly what's needed, is a nice service to users that want to build a customized package, especially if the source package is big). -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpaPggJtF9ER.pgp Description: PGP signature
Re: how pass variables from files for dh_install into rules?
On Wednesday 04 April 2007 15:52, andremachado wrote: I tried to use variables in package_name.install file to be read into the /debian/rules , presuming they could be read as is and then expanded into rules. But it failed and I had to write directly inside the rules. Is there a way to accomplish this in the file read? What kind of variables? What do you want to do? package_name.install etc. are simply read by dh_install etc. and doesn't have anything directly to do with debian/rules, besides the fact that dh_install etc. are usually run from there. Commonly when you have a multi-binary source package you set DESTDIR=$(CURDIR)/debian/tmp and let make install install everything there. Then you just use dh_install to separate the files into the right packages. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpRRGMSRB37H.pgp Description: PGP signature
Re: A french developper want help you :)
I'd like to add a point: On Thursday 29 March 2007 17:33, Andreas Tscharner wrote: A more general approach: * Check if any open source project you like is already in Debian * If it's not, check if there is a request for it already (http://www.debian.org/devel/wnpp/prospective), and if so, follow the relevant procedure from http://www.debian.org/devel/wnpp/. * If it's not: File an ITP and create a package of that project * Ask one of the DDs here to upload your package -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpdIPZ0i2v1a.pgp Description: PGP signature
manpage tools
What tools do you prefer for writing manpages (e.g. for commands that lack one from upstream)? A DocBook XML file is modern, maintainable, can be converted to other formats as well, and is suggested by dh-make. But I don't quite like the output of the docbook-xsl template: for example, the spaces on either side of the vertical bar between args in groups can't readily be omitted. Moreover, you have to write a *lot* of tags due to, IMHO, unnecessary limitations as to which elements can be contained in which, and the autogenerated Authors section clashes with the common This manual page was written ... for the Debian ... Authors section. So what other alternatives are there, not counting help2man and pod2man? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpgZArXZObt1.pgp Description: PGP signature
Re: ITA/RFS: libspf2 -- Sender Policy Framework library, written in C
On Friday 23 March 2007 20:23, Magnus Holmgren wrote: I have created a new version of libspf2 and intend to adopt it if I can find a sponsor (and/or co-maintainer). It fixes (hopefully) all outstanding bugs except one. 20_64bit_types.patch may need some testing. I hope that some DD is interested enough in SPF to take the time, and that he or she will find the package satisfactory. Martin Zobel-Helas has agreed to help me with this, so I no longer need a sponsor. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpQnizreqy34.pgp Description: PGP signature
Re: ITA/RFS: libspf2 -- Sender Policy Framework library, written in C
On Friday 23 March 2007 20:50, Martin Zobel-Helas wrote: Hi, I am a bit irritated by the following sentence in README.Debian-source: | It's completely out of date anyway. Could you please explain? Well, it is. It's an expired I-D from 2004, and nowadays there's even a real RFC. But I could change the wording. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpSAgOjgFqEZ.pgp Description: PGP signature
ITA/RFS: libspf2 -- Sender Policy Framework library, written in C
retitle 372629 ITA: libspf2 -- Sender Policy Framework library, written in C owner 372629 [EMAIL PROTECTED] thanks I have created a new version of libspf2 and intend to adopt it if I can find a sponsor (and/or co-maintainer). It fixes (hopefully) all outstanding bugs except one. 20_64bit_types.patch may need some testing. I hope that some DD is interested enough in SPF to take the time, and that he or she will find the package satisfactory. The dsc, for download with e.g. dget, is at ftp://ftp.kibibyte.se/debian/pool/main/libs/libspf2/libspf2_1.2.5.dfsg-1.dsc Description: Sender Policy Framework library, written in C libspf2 implements the Sender Policy Framework, a part of the SPF/SRS protocol pair. libspf2 is a library which allows email systems such as Sendmail, Postfix, Exim, Zmailer and MS Exchange to check SPF records and make sure that the email is authorized by the domain name that it is coming from. This prevents email forgery, commonly used by spammers, scammers and email viruses/worms. Homepage: http://www.libspf2.org/ License: GPL/BSD Changelog entry: * New maintainer (Closes: #372629). * Repacked .orig.tar.gz without non-free (and obsolete) IETF Internet Draft (Closes: #393390). * Merge updates from Ubuntu: - Add debian/compat and Build-depend on debhelper = 5. - Add alternatives handling for /usr/bin/spfquery (Closes: #306875). - Conflict on libmail-spf-query-perl 1:1.999.1-3. - Add postinst and prerm scripts. - debian/copyright: update author address. - debian/control: add final newline. * debian/control: * Change description of spfquery (Closes: #410592). * Add homepage to package descriptions. * Reduce Debian diff by changing line endings with sed instead. * Further reduce Debian diff by eliminating config.sub and config.guess from there. Build-depend on autotools-dev to ensure up-to-date versions instead. * The autogenerated spf_lib_version.h was put in the wrong directory, while there was a static spf_lib_version.h in the right directory. Fix that with some rules in debian/rules. * Use simple-patchsys.mk to manage patches. * Apply 20_64bit_types.patch to hopefully prevent segfaults on 64-bit architectures (Closes: #392793). Thanks to Thomas Jacob, Carsten Koch-Mauthe and Herbert Straub. * debian/watch: added. * Update Standards-Version to 3.7.2 without changes. * Apply 20_spf_dns_include_std_headers.patch: Include arpa/nameser.h and netdb.h from spf_dns.h instead of defining the constants needed unless certain HAVE_ macros are defined (Closes: #405885). -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpSKTQ6FXThn.pgp Description: PGP signature
Re: ITA/RFS: libspf2 -- Sender Policy Framework library, written in C
On Friday 23 March 2007 20:53, Mike Hommey wrote: On Fri, Mar 23, 2007 at 08:23:38PM +0100, Magnus Holmgren [EMAIL PROTECTED] wrote: (...) Have not taken a look at the package, but does the short description Description: Sender Policy Framework library, written in C really have to say written in C ? Perhaps not. But it was like that when I got it. :-) Possibly it should say what it does instead of simply what SPF stands for. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgprzGeApiUBk.pgp Description: PGP signature
Re: Native package versus orig
On Sunday 18 March 2007 21:49, Roberto C. Sánchez wrote: Also, a native package means that there is no .diff.gz. That means that every version creates a new .orig.tar.gz which consumes more mirror space. (Except that it isn't a .orig.tar.gz but just a .tar.gz.) -- Magnus Holmgren[EMAIL PROTECTED] pgpoud4PDmPKt.pgp Description: PGP signature
RFS: pmk (adopted): utility to configure software sources
Hello, dear mentors!
I have finished my work for now with the package pmk and would be grateful
if a sponsor would upload it. It is of course lintian and linda clean, and
should be of a considerably better quality than the previous version - I've
made quite a few changes.
One is that the configuration file, which is dynamically created, is now
handled with the help of ucf. Please check if I've done that right.
Unfortunately I don't have access to the old static configuration file, but
that is pre-sarge, and almost nobody uses pmk anyway.
I'd also like to know which variants of the name of a configuration file to
delete in addition to the file itself, in order to do like dpkg. I've used
file~, #file#, file.bak, and file.ucf-{old,dist,new}.
URL of the DSC: http://www.kibibyte.se/download/debian/pmk_0.10.1-1.dsc
--
Magnus Holmgren[EMAIL PROTECTED]
(No Cc of list mail needed, thanks)
pgpTXnD3RAesB.pgp
Description: PGP signature
Repost: RFC and preliminary RFS: prayer webmail
I try this again since I never got any response back in November... I have now created a working prayer package. It's not finished, but good enough to show you, fellow list subscribers. You can find it at: http://www.kibibyte.se/download/debian/ DSC: http://www.kibibyte.se/download/debian/prayer_1.0.18-1.dsc Please see the ITP at http://bugs.debian.org/392823 for the full story. The source package builds two packages: prayer and, for completeness, prayer-accountd, although the latter is still pretty useless outside Cambridge. Note: the prayer binary package uses libc-client2006b from experimental, but the dependency is missing from the control file. You will probably want to build the source package, after inspecting it, anyway. 2. Support for other character sets than ISO-8859-1 is non-existant. Conversion of various mail text to UTF-8 has to be added. I have now addressed this as well as modified UTF-7 encoding and decoding. See README.Debian. 5. At least minimal man pages have to be written. I have not addressed this yet. Please disregard for now. Something I've been thinking about: If two packages share a /var/(lib|run|log) subdirectory, how do you know when to remove it? I reckon that it should be removed when the last of the packages has been purged. Both packages place files there at runtime, so dpkg won't remove it since it's nonempty. But you can't just remove it in postrm if it's empty. Do you: a) leave it alone; let root delete it manually when it's no longer needed b) use dpkg -S to see if it's still in use c) use dpkg -l to see if the other package is still installed d) avoid sharing directories under /var e) do something else? Thank you for your interest! -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpy36P5BBFo6.pgp Description: PGP signature
Re: Repost: RFC and preliminary RFS: prayer webmail
On Saturday 10 March 2007 21:37, Justin Pryzby wrote: On Sat, Mar 10, 2007 at 08:05:55PM +0100, Magnus Holmgren wrote: Something I've been thinking about: If two packages share a /var/(lib|run|log) subdirectory, how do you know when to remove it? I reckon that it should be removed when the last of the packages has been purged. Both packages place files there at runtime, so dpkg won't remove it since it's nonempty. But you can't just remove it in postrm if it's empty. Do you: a) leave it alone; let root delete it manually when it's no longer needed b) use dpkg -S to see if it's still in use c) use dpkg -l to see if the other package is still installed d) avoid sharing directories under /var e) do something else? The easy thing to do is to include it in the package, rather than creating it in maintainer scripts. Then dpkg leaves it alone if another package also includes (and in recent releases may even succeed in not warning you). I think there are cases where it is advantageous not to include it, but they don't occur to me presently.. The directory is included in the packages, that's why I wrote that dpkg won't remove it. The problem is that postrm purge is called after dpkg removes the last of a package's files. Thus we have to delete not only the files, but also the directories, that are not deleted already in postrm remove. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgptCZeun87T4.pgp Description: PGP signature
RFS: nettle (adopted) 1.15-1
Hello, dear mentors. I'm looking for a sponsor for completing adoption of nettle, a low level cryptographic library. The files can be downloaded from http://www.kibibyte.se/download/debian/ DSC URL: http://www.kibibyte.se/download/debian/nettle_1.15-1.dsc Changelog entries: * New maintainer (Closes: #411677). * New upstream version. The non-free IETF RFC has been removed by upstream. * Updated Standards-Version to 3.7.2 without any changes. * Converted doc-base and copyright files to UTF-8. * Added extra cleanup to clean target of debian/rules so that dpkg-buildpackage can be run more than once. + added homepage URL to package descriptions. The previous maintainer created a fake upstream version 1.14.1 as the DFSG-cleaned version of 1.14, instead of the more standard 1.14.dfsg(.1) or similar. I'm wondering if I should prepare a 1.14 upload aimed at Etch with the above changes (except the New upstream version, of course), and if so, whether I should rename the .orig tarball. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpMgHkbPsstp.pgp Description: PGP signature
Re: Multiple upstream changelog files
On Tuesday 30 January 2007 08:52, Marcus Better wrote: Magnus Holmgren wrote: I maintain a package where the upstream author has two changelog files: A brief one called Changes, summarizing the changes, and a detailed one called ChangeLog, which contains a detailed list of changes made to the various source files. This is common with Java packages built with Maven, where a detailed commit log is automatically generated and included in the sources. In that case I prefer to leave out the commit log altogether since it's mainly useful for developers. But what if Changes says see ChangeLog for details? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgpBvvfqxBxpa.pgp Description: PGP signature
Re: Multiple upstream changelog files
On Tuesday 30 January 2007 01:54, Magnus Holmgren wrote: I maintain a package where the upstream author has two changelog files: A brief one called Changes, summarizing the changes, and a detailed one called ChangeLog, which contains a detailed list of changes made to the various source files. Which one should be installed as changelog? OK, so now I have three different bids: 1) Distribute the brief changelog as changelog.gz and the detailed one as is; 2) distribute the detailed changelog as changelog.gz and the brief one as is; 3) only distribute the brief changelog in the binary package. Any more opinions? The package in question is libmail-dkim-perl, BTW. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp5Gh5uSyveP.pgp Description: PGP signature
Multiple upstream changelog files
I better ask this once and for all... I maintain a package where the upstream author has two changelog files: A brief one called Changes, summarizing the changes, and a detailed one called ChangeLog, which contains a detailed list of changes made to the various source files. Which one should be installed as changelog? I'd guess the brief one, since it's the one users are most likely to want to read first, but on the other hand it looks a bit confusing with both a changelog(.gz) and a ChangeLog. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpdBDek3enMc.pgp Description: PGP signature
changelog has a useless empty line (was: Re: RFS: speedometer)
On Saturday 13 January 2007 23:59, Daniel Baumann wrote: Jari Aalto wrote: http://cante.net/~jaalto/tmp/debian/speedometer/speedometer_2.4-1.dsc * changelog has a useless empty line at the end of the file. The dh_make template includes that empty line - no wonder almost all RFS's you comment on have that deficiency, if it is one. In addition, can't it be said that the final blank line is part of the format of a changelog.Debian entry? 8- $package ($version) $distribution; urgency=$urgency * $change[0] * $change[1] * ... -- $Maintainer $maintainer_address $date 8 There is always a blank line after the maintainer line before the following (chronologically previous) entry. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpjRGuQ27dfC.pgp Description: PGP signature
Re: Frozen Etch
On Tuesday 09 January 2007 22:57, Paul Cager wrote: Can I just check that we are still allowed to upload to unstable while testing is frozen? (Or rather, in my case, to ask a sponsor to upload). Of course we're allowed to upload to unstable. The point of the freeze is that packages don't enter testing without manual intervention. However, bear in mind that if you upload disruptive changes to unstable, then RC bug fixes and other updates of the kind that will be allowed into testing during a freeze will have to go through testing-proposed-updates, which isn't the preferred way. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpXjoATd1zQh.pgp Description: PGP signature
Re: RFS: array-info
On Friday 15 December 2006 18:49, Daniel Baumann wrote: Raphaël Pinson wrote: http://mentors.debian.net/debian/pool/main/a/array-info/array-info_0.12-1 .dsc please build-depend on the linux-headers package, and do not include them into your orig.tar.gz. Absolutely. Never add anything to the .orig.tar.gz tarball. However, I believe linux-kernel-headers is the right package to depend on for linux/cciss_ioctl.h. But (cpqarray.h ida_cmd.h ida_ioctl.h) aren't directly in any package, only in the bzip2ed tarball in linux-source-2.6*. What's the correct way of building then? If your supposed to use those header files to compile user-space programs, then perhaps the Linux guys should put them in ./include instead of ./drivers/block? do strip of the CVS dirs from orig.tar.gz and ask upstream to remove them in the next release. This old debate again... I'm of the impression that it's more important that the orig tarball is pristine. I've found this thread: http://lists.debian.org/debian-devel/2005/10/msg1.html. It doesn't quite settle the issue, but it seems that CVS directories in the upstream tarball is no issue even if one wants to import the package into one's own CVS and use cvs-buildpackage, for example. btw, just a hint: it would be simpler using dpatch than applying the patches 'on your own'. And with the right build-dependencies the patch probably won't be needed at all. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgpNGnBVDjLSP.pgp Description: PGP signature
Re: RFS: sa-exim -- Use spamAssassin at SMTP time with the Exim v4 MTA
On Saturday 02 December 2006 18:05, Amaya wrote: Magnus Holmgren wrote: it would be most kind if one or more of you could take a look at the new sa-exim package I've prepared, thereby adopting it. (But don't upload it yet; I'd like upstream to acknowledge that he knows that I'm adopting it first.) I'll upload this. Thanks for giving sa-exim some love! Just a sec ... I just remembered that I should upgrade the Standards-Version. There are also a couple of issues with the greylistclean script. I think I'm gonna move it from /usr/sbin to /usr/share/sa-exim to avoid having to supply a manpage for it (it's not supposed to be run manually anyway). Further, the greylistclean crontab expects spamd to be run as, and therefore the greylisting tuplets in /var/spool/sa-exim to be owned by, nobody, who shouldn't own any files at all. That's of course configurable, but it's not a recommended default. I don't think sa-exim should put greylisting tuplets and archived mail under /var/spool, but /var/lib. I don't know if the maintainer script hacking needed is worth it, though. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgpgIV10KjJhk.pgp Description: PGP signature
RFS: sa-exim -- Use spamAssassin at SMTP time with the Exim v4 MTA
Dear mentors, it would be most kind if one or more of you could take a look at the new sa-exim package I've prepared, thereby adopting it. (But don't upload it yet; I'd like upstream to acknowledge that he knows that I'm adopting it first.) It can be found at http://www.kibibyte.se/download/debian/, or downloaded directly with dget http://www.kibibyte.se/download/debian/sa-exim_4.2.1-3.dsc From changelog.Debian: * New maintainer (Closes: #352533). * Updated package description to explain what SA-Exim can do that exim-daemon-heavy can't, and vice versa (Closes: #378732). * Added German debconf template translation (Closes: #399963). Thanks to Matthias Julius. * Updated Swedish debconf templates. * Repackaged against pristine upstream tarball. * Encourage use of ACL variables in sa-exim.conf. Also exclude ::1 from SA scanning. There are no changes in executable code at this time. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpc86j8EuLK4.pgp Description: PGP signature
Re: Which script to install file in /etc/default
On Tuesday 31 October 2006 15:56, Andreas Tscharner took the opportunity to say: At the moment, this lock server is started with an init.d script regardless if the user installs cvsnt as server or not. My idea is to create a file /etc/default/cvsnt which contains a variable that controls whether or not the lock server is stared. Is there any dh_* script that installs a given file or do I need to make it in some other way? From dh_installinit(1): If a file named debian/package.default exists, then it is installed into etc/default/package in the package build directory, with package replaced by the package name. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp29YyHSOpDl.pgp Description: PGP signature
Re: RFS: exaile
On Tuesday 17 October 2006 08:38, George Danchev took the opportunity to say: * Upstream changelog says exaile uses gamin to monitor directories, but your package doesn't depend on it. The code seems to cope with lack of python-gamin, so the package can merely recommend or suggest it. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpQo6j0HANDw.pgp Description: PGP signature
Re: RFS: libmail-dkim-perl
On Sunday 08 October 2006 00:10, Magnus Holmgren took the opportunity to say: Hello, dear mentors! I'm looking for a temporary sponsor of my package libmail-dkim-perl. Hamish Moffatt [EMAIL PROTECTED] has previously shown interest, but now when I'm hoping to get at least one DK/DKIM package into Etch in the last minute I have to try to reach a greater number of developers. He has taken care of this now. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpBxjpuvswyx.pgp Description: PGP signature
RFS: libmail-dkim-perl
Hello, dear mentors! I'm looking for a temporary sponsor of my package libmail-dkim-perl. Hamish Moffatt [EMAIL PROTECTED] has previously shown interest, but now when I'm hoping to get at least one DK/DKIM package into Etch in the last minute I have to try to reach a greater number of developers. Download location: http://www.kibibyte.se/download/debian/ dget http://www.kibibyte.se/download/debian/libmail-dkim-perl_0.19-1.dsc Read the ITP at http://bugs.debian.org/378046 for the description. It's a perl package of the simplest sort. It's lintian clean. The reason for the delay is the legal questions. But after a lot of pondering I believe that at least this package should be safe: Copyright: perl license, no dependencies or linkage that cause license incompatibilities Trademarks: none Patents: to the extent that Yahoo's patents are valid and affect DFSG-freeness, they quite surely aren't going to go after us/you. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpLZMUtTadS0.pgp Description: PGP signature
Re: RFS: beep-media-player-musepack -- Bmp plugin to read Musepack (MPC) files
On Monday 28 August 2006 11:01, Daniel Baumann took the opportunity to say: Adam Cecile (Le_Vert) wrote: It builds these binary packages: beep-media-player-musepack - Bmp plugin to read Musepack (MPC) files This package should't be uploaded because beep-media-player will be removed soon. If it works with audacious or bmpx, please rename the binary package. It will? Why is that? There is no Serious bug filed against it. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpzXFX2Fpzbj.pgp Description: PGP signature
Re: plea to sponsees about announcing location of packages
On Tuesday 25 July 2006 13:16, Damyan Ivanov took the opportunity to write: It would be good if this is used in mendors.d.n-generated RFS templates. (Christof Haas CC-ed). Something like: Or just dget http://mentors.debian.net/debian/pool/main//pkg.dsc instead of the paragraph speaking about apt-get source. What's wrong with apt-get source? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpFfbTlTAWzH.pgp Description: PGP signature
Re: plea to sponsees about announcing location of packages
On Thursday 27 July 2006 12:28, martin f krafft took the opportunity to write: also sprach Magnus Holmgren [EMAIL PROTECTED] [2006.07.27.1124 +0100]: Or just dget http://mentors.debian.net/debian/pool/main//pkg.dsc instead of the paragraph speaking about apt-get source. What's wrong with apt-get source? You have to add a line to /etc/apt/sources.list to make it work. Yes, but only once. It's still a useful alternative for anyone that checks out source packages from mentors.debian.net regularly. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp8LJrao2Re5.pgp Description: PGP signature
Re: plea to sponsees about announcing location of packages
On Thursday 27 July 2006 12:59, Thijs Kinkhorst took the opportunity to write: On Thu, 2006-07-27 at 12:48 +0200, Magnus Holmgren wrote: What's wrong with apt-get source? You have to add a line to /etc/apt/sources.list to make it work. Yes, but only once. It's still a useful alternative for anyone that checks out source packages from mentors.debian.net regularly. Only once for every possible repository where a sponsor might have stored their packages. Mentors is far from the only one. On Thursday 27 July 2006 12:58, Eddy Petrişor took the opportunity to write: As oposed to none?! And you don't have to do that with every package that is self hosted. The vast majority of RFSes on this list, at least lately, seem to use mentors.debian.net though. As a wannabe DD it seems like a good place to stick to *if* I want to give potential sponsors the apt-source option -- I can't expect every DD to add tens of apt-src lines to their sources.list. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpAPpHpOPjQr.pgp Description: PGP signature
Re: Build-depend on source of a debian package
Tim Dijkstra wrote: A debian package I'm making has as part of its source a (almost) verbatim copy of the source of a package that is already in debian. It works perfectly like this and it's only 916K, but it feels a bit of a waste to include it in the source package. I can't however build-depend on the source of another debian package, can I? Should I ask for the other package to make an -dev package containing the source? This also doesn't feel right, because it's not a proper library... can make it into one of course... Comments? Can you reveal the name of that other source package? It sounds like it would be better if the package you're making were built from it instead. -- Magnus Holmgren -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
