Re: How mature is Pkg-format 3.0 (git), yet?
On Mon, January 16, 2012 23:26, Paul Wise wrote: I just wanted to ask how mature Package-format 3.0 (git) became until now. It is not currently accepted by the Debian archive: http://bugs.debian.org/642801 My experience until now is that it's mature in dpkg. It does the job just like other source formats, for me. It's indeed not accepted in the Debian archive and also tools like Lintian don't support it. So it depends on your goals whether you can call it mature. It works very well for a local package I maintain. Thijs -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8054b018669e4f81a61abc780bf05594.squir...@wm.kinkhorst.nl
Re: RFS: subnetcalc
On snein 7 Juny 2009, Thomas Dreibholz wrote: thank you for your review of the SubNetCalc package. The updated package at http://mentors.debian.net/debian/pool/main/s/subnetcalc/ should fix the problems. I have removed the duplicate entries in changelog as well as the temporary file changelog-v2. Also, I have removed the Closes field from debian/control. Perhaps you can make it explicit in the description what this package offers over ipcalc which is already in the archive since a long time. Thijs signature.asc Description: This is a digitally signed message part.
Re: Added requirement for translation of debconf templates
On Sun, January 18, 2009 20:04, Mark Brown wrote: On Sun, Jan 18, 2009 at 05:24:05PM +, Neil Williams wrote: using debconf that requires sponsorship, that debconf translations are requested and updated by the maintainer on an ongoing basis. You mean that requires [my] sponsorship ? ... ... For the first upload I broadly agree but for other uploads I think it's worth considering other aspects of the tempo of development - is the effect of uploading without waiting for translations likely to be a long term thing or is it likely to be a brief interlude in unstable. Yes, in some circumstances I think it could be considered a good idea to first make an upload to unstable, and once you're sure that the new debconf template and the code associated with it has stabilised, only then ask for translations. Suppose it seems the template wasn't required afterall, or a change is needed, all translation work is wasted or has to be redone. Of course you're free to declare the boundaries of what you want to sponsor and make them as sharp as you see fit. I prefer not to post an elaborate set of rules, but rather judge a package on a case by case basis. Both are valid approaches, and have different tradeoffs in predictability versus flexibility. I would appreciate it if you would make it more clear that what your present are *your* requirements for sponsorship. Your mail reads like an annoucement rather than a change in what are your personal preferences. thanks, Thijs -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: whohas (new upstream)
Hi Jonathan, On Thu, January 8, 2009 07:26, Paul Wise wrote: On Thu, Jan 8, 2009 at 8:22 AM, Jonathan Wiltshire deb...@jwiltshire.org.uk wrote: I have uploaded whohas 0.22-1 to m.d.n, which is a new upstream integrating a lot of the bugs, and some tweaks to the packaging because of his changes. Great. As I think this can be very useful to Debian developers, I have added a news item to the DeveloperNews queue, which will be posted to debian-devel-annnounce sometime in the near future: http://wiki.debian.org/DeveloperNews Feel free to update/change it. I've also included a NEWS file detailing the patches that are still active. I don't think that is an appropriate use of NEWS.Debian, documenting them in the patch headers should be enough. Agreed; NEWS.Debian is for changes to the package that are relevant to end users. This information is indeed most appropriate in the individual patch headers. Listing all the distros supported may not be a good idea because this will change over time and thus add work for those translating Debian package descriptions. I think that's actually rather informative as it gives a good overview of the breadth of the package and what kind of distributions it searches. It's not critical that the list is exactly up to date, so I don't think it would be a problem if some translations were to get a little behind on the most recent version. So I would leave it in. cheers, Thijs -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: whohas (new upstream)
On Thu, January 8, 2009 11:19, Jonathan Wiltshire wrote: Devref mentions NEWS.Debian as a changelog supplement: This is the preferred means to let the user know [...] changes in a package [1]. I didn't use README.Debian as the same paragraph seems to discourage this, but if you think it would be better I will change it. Clarification of these files would be appreciated :-) An important distinction of NEWS.Debian is that it is shown to users on package upgrade. I think we should use this sparingly as to not devaluate the use of this functionality. Nearly every Debian package has patches relative to upstream, it is good that they are documented for those actively looking for it. README.Debian is in that sense also acceptable. On Thu, January 8, 2009 11:21, Jonathan Wiltshire wrote: http://wiki.debian.org/DeveloperNews Feel free to update/change it. Good idea, thanks. Should it mention that whohas is still 1.0 and being heavily developed though? Or is the BTS mention enough? I think that's not quite important - developers are not afraid of such software and keeping the text short means more people read it :-) Thijs -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: apt-proxy, apt-cacher approx
On Mon, September 22, 2008 08:11, Kel Modderman wrote: On Monday 22 September 2008 15:20:20 Cameron Dale wrote: On Sun, Sep 21, 2008 at 10:14 PM, Thomas Goirand [EMAIL PROTECTED] wrote: We've been using apt-proxy for about a year, and then found it quite buggy. So we moved to using apt-cacher. Now we have loads of problems with apt-cacher as well (like currently, a recurring tzdata size mismatch error). I was wondering if approx is any better than the other two. Did any of you try? I have also experienced similar problems with both apt-proxy and -cacher. I am now using approx, and I can report no errors with it at all. It may be slightly slower, but that could be my imagination. I would definitely recommend approx. I agree, approx has served myself well for quite some time. I had some caching issues with approx in etch. When I upgraded to the version from lenny in backports.org, that trouble went away and it runs smoothly. Just as a note there seems to be now a fourth alternative: apt-cacher-ng... Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: No sponsor found for weeks, what to do now?
On Wednesday 27 August 2008 20:23, Neil Williams wrote: Plus, I've surely not seen anyone being flamed [...] by the security team, let alone to crisp, (Some of that happened off-list and one of the people involved is well-known to me due to interests outside Debian. I can vouch that some of the off-list stuff was easily described as 'flaming to a crisp'.) let even further alone those many people you're talking about, and find the suggestion that we would act in such a way a bit offensive. Mentors might not, others certainly have done. It doesn't serve the list to pretend that security and PHP are not poor bedfellows or that PHP will not invite some very firm, very pointed and extremely critical responses outside this list. Whatever you personally think of PHP, I'm not charmed with you making allegations on a public forum that many people were flamed to crisp by the team I am a member of, but then fail to support that statement when asked where you base it on. If you want to make statements that put a team in a bad light in a public forum you'll have to be prepared to back them up. It seems to boil down to trust me, I once heard somewhere that a person was flamed by a security team member. I think it's evident that I'm not charmed by you postulating that many people were flamed by that team, suggesting structural issues, without presenting a piece of material on that. I believe that only helps to set a negative atmosphere around that team. Thijs pgpLQDFGm0UsX.pgp Description: PGP signature
Re: Lintian warning messages
Hi Richard, On Tuesday 5 August 2008 14:02, Richard Hurt wrote: I am getting quite a few lintian warnings that I would like to quell. Do we have any best practices on how to deal with these messages? W: package: debian-copyright-line-too-long -- As I understand it long lines are now OK. I am following the new, proposed guidelines for the copyright file (http://wiki.debian.org/Proposals/ CopyrightFormat) and it almost guarantees long lines. This warning has been scratched from the upcoming Lintian version so I would not worry about it. W: package: script-non-executable -- Since this is a scripted web application (RoR) there are quite a few scripts that are not executable directly in the shell. Can I turn this warning off for these files? Maybe you could find out why this warning is triggered. Probably, these scripts have shebang lines (#!/usr/bin/ruby perhaps?) but are not executable. That doesn't match, as the shebang line is useless if the script is not executable. So if they're not going to be executed on the shell anyway, upstream can remove those shebang lines. That said, I don't think it's necessary to be going through the effort to make a Debian-specific patch to the source for that. W: package: extra-license-file -- There are several LICENSE files scattered throughout the package and I have documented them in the copyright file. Do I need to do anything with these? Should I remove them or is there a way to ignore them? Just remove them when building the package (e.g. doing rm in debian/rules somewhere after the dh_install). It's useless cruft that we do not want to see installed on user's systems. In general it's worth the effort to put extra commands in your debian/rules file if that causes less unnecessary things on the user's system - a package is rarely built but after that installed on many systems. W: package: embedded-javascript-library -- Basically, prototype.js (versions 1.6.0.1 1.5.0) is being used in several places. Obviously it would be best to depend on the libjs-prototype package and remove the embedded versions. Once I get upstream using a single version of prototype do I just remove the original prototype.js files and symlink to the package version? Yes, that would probably work fine. Until then, just keep the warning to remind you and others that this isn't done yet. W: package: package-contains-empty-directory -- Some of these are necessary (cache, assets, etc.) and some aren't (test). Can I turn these off? You can remove the unnecessary ones (similar to the licence files above) and add overrides for the needed ones. cheers, Thijs pgpRQUMn2JWr6.pgp Description: PGP signature
Re: Developer names within debian/changelog
On Tuesday 13 May 2008 13:24, Ben Finney wrote: I'm less interested in strictness in Policy than I am in finding out how this is *specified* for all consumers, rather than merely *implemented* in specific programs. Maybe you can specify what problem you are trying to solve. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer names within debian/changelog
On Tuesday 13 May 2008 16:28, Ben Finney wrote: All the answers I've had so far indicate that there *is* no specification for developer names within a changelog entry, and that any format at all is allowed so long as the loose definition in Policy is followed. My issue with that is that it leads to this information being recorded in many, mutually-incompatible ways (which was, I believe, the existing state when the format was proposed), with no simple guide of how one *should* put the information in to be a good Debian citizen. Ok, so to answer your question: the information was until now only ever intended to be human-readable. That debchange generated is is a convenience measure so you don't have to type it, not a way to encode it specifically. Nearly all of the changelog is currently not machine-parsable, with notable exclusion of the first and last line (-- author), and the closes: statements. Everything else, like descriptions of files changed, bugs fixed, translations updated, release codenames and indeed maintainer names are there only for humans to read. If there were a concrete use case to standardising the format of any of them, of course we could do that. See debian/copyright, that has been freeform for many years, only when there was a use case for parsing did people start to standardise it. If you have this concrete use case, please present it so we can see if it's worthwhile to require everyone to use the format, or that the current free-for-all is just as sufficient. cheers, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer names within debian/changelog
On Monday 12 May 2008 06:17, Ben Finney wrote: In recent years I've seen entries in 'debian/changelog' that are broken up into sections by developer name. I'm referring to entries like this: The Policy section above is silent on this extension to the format, though I've seen Joey Hess discussing it in the past. I also know that 'debchange' can produce it, and 'dpkg' can consume it. Indeed debchange generates the format. I'm not sure what you mean that dpkg can consume it. I know of no special meaning that dpkg assigns to those names, as far as I know it just treats them like any other changelog line. If there's any specification to it, I think it's best found in debchange's source code. Thijs pgpkdQIHmDtx9.pgp Description: PGP signature
Re: Version number in rules
On Tuesday 6 May 2008 12:45, Sveinung Kvilhaugsvik wrote: Is there a way to get the Debian version as a variable in the rules file? Is there a standard way to remove the .dsfg from it? The following works well for me. I'm not sure but I don't believe there's a more 'standard' way. To remove the .dfsg, add some sed to this line. DEB_VERSION := $(shell dpkg-parsechangelog | egrep '^Version:' | cut -f 2 -d ' ') cheers, Thijs pgp1wLV1gTfCt.pgp Description: PGP signature
Re: RFS: remaining packages
Hi J.L., On Tuesday 18 March 2008 02:53, José Luis Tallón wrote: - Couriergraph - Bindgraph You got a sponsorship offer for these here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468134#15 Thijs pgpxdDBKoKrLS.pgp Description: PGP signature
Re: RFS: tcpser (updated package) (try 5)
Hi Peter, On Monday 10 March 2008 15:25, Peter Collingbourne wrote: I am looking for a sponsor for my updated package tcpser. I've uploaded this package for you now. Thanks for your work, and sorry that it took so long for someone to pick it up. One point: upstream has included all .svn dirs in their tarball. While this isn't really a problem for a package of this size, you may want to alert them of that, because it wastes space and can be inconvenient for someone wanting to import it into Subversion. svn export is the key here. Thijs pgpnUToiL9t0b.pgp Description: PGP signature
Re: RFS: some long-due updates
On Sunday 9 March 2008 13:14, José Luis Tallón wrote: * You accidentally left out the -10.2 NMU changelog entry. Please reinclude it so that an accurate overview of package history remains. You can see this when you do a debdiff between the archive version of imapproxy (apt-get source) and your new version. I prepared this update before 10.2 existed, and I overlook the fact that and additional NMU happened meanwhile. Thanks for fixing this in the updated package, I've now uploaded it. There was one problem during testing, that is that when the remote server has an IPv6 address but the local host does not have a globally routable IPv4 address, then the connection fails and does not fall back to IPv4. Maybe you can pass this on to upstream. thanks, Thijs pgpZ73DRu18hd.pgp Description: PGP signature
Re: RFS: some long-due updates
Hi J.L., On Sunday 9 March 2008 01:57, José Luis Tallón wrote: * imapproxy 1.2.6-1 http://devel.adv-solutions.net/debian/pool/main/mail/imapproxy/up-imapproxy _1.2.6-1.dsc I've taken a look at this one. It looks good in general, thanks for your work on this! There's just a couple of minor things I'd like to see resolved before uploading: * You accidentally left out the -10.2 NMU changelog entry. Please reinclude it so that an accurate overview of package history remains. You can see this when you do a debdiff between the archive version of imapproxy (apt-get source) and your new version. * The nl.po file seems to have completely vanished. * I still get one lintian warning: W: up-imapproxy source: debian-rules-ignores-make-clean-error line 52 * Optionally, you could consider adding a Homepage: field to debian/control. thanks, Thijs pgpSVJxaeX4xt.pgp Description: PGP signature
Re: RFS: some long-due updates
On Sunday 9 March 2008 13:14, José Luis Tallón wrote: Indeed. Make clean (as shipped by upstream) always fails, and so the error needs to be ignored for the build to succeed --- what it does is however needed for a package build to complete. I don't normally like lintian overrides, but this feels like a good candidate for one. Meanwhile, I can try and fix the problem (non-trivial, already took a look) and submit it upstream. Delaying this upload just for this reason is not a good idea, given that we are approaching a release. I'd rather have the package fully tested before inclusion. I agree that this lintian warning is not top priority. It seems fair to leave this one for now and get the other fixes into the archive first. When that's done, we can take a look at this issue. Let me know when new packages are available. bye, Thijs pgpLgzExKibxU.pgp Description: PGP signature
Re: Tests that take more than ten times build time.
On Wed, February 13, 2008 07:24, Charles Plessy wrote: Test time on arch (build time) 1h05 on sparc (3 min), 37 min on mipsel (2 min), 39 min on mips (3 min), 37 min on powerpc (2 min), 19 min on hppa (2 min), 6 min on amd64 (1 min)⦠Of course, if this is an exception, there is no need to argue. But in the Debian-Med packaging team, we have a few package whose tests are not yet enabled (bioperl, emboss,...); I do not know if it would be wise to do so systematically if they have a similar pattern of CPU usage... I don't see a problem here. Tests catch errors, we have enough build time available, so just run them. Time spent by users and developers when a problem slips through is a lot more expensive than the buildd time to run them. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tests that take more than ten times build time.
On Wed, February 13, 2008 11:34, Charles Plessy wrote: And another one, who was never built in mips, is number 509 in the queue (glam2). For njplot, the waiting time is already 29 days. Therefore, I am a bit doubtful that we have enough build power. Would we have, my original question would of course be pointless. That is a fundamental problem with that architecture, and should be fixed by porters of that architecture. If you can't handle the build times you posted in your previous mail, they can definately not handle a significant part of our archive. Which can be seen by the large queue for that arch. Either they can keep up or they are not a release architecture. We should not be sacrificing our package quality over some fringe arch, while all others can keep up just fine. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: many packages
On Mon, February 4, 2008 14:21, José Luis Tallón wrote: Any of you with upload powers has some time left to sign and upload some packages? I have a little too many bugs waiting for an upload to be fixed, some of them quite old already. My usual sponsors have been much too busy as of lately. Anyone wants to volunteer? If you have an update for up-imapproxy (which I see is one of 'yours'), I'm willing to take a look at it. Send me an URL to the .dsc and I'll check it out tonight. It may help to actually list the packages you're looking for sponsors for. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: workbone - QA Upload with RC bugfix
On Sunday 3 February 2008 17:04, Barry deFreese wrote: I've made a QA upload for workbone that closes the RC bug if someone could review/upload I would appreciate it. http://mentors.debian.net/debian/pool/main/w/workbone/workbone_2.40-8.dsc Thanks - I'm building this now and will upload it if all is well. Thijs pgp9YAxwADuGG.pgp Description: PGP signature
Re: RFS: hashalot (updated)
On Thursday 24 January 2008 04:40, Kapil Hari Paranjape wrote: * Vcs-Svn and Vcs-Browser. Shouldn't the Vcs-Svn entry start with svn: instead of http:? SVN can be run over a variety of protocols, next to svn including ssh and http(s). Which is an excellent feature if you ask me :-) Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: line6-usb
Hi Jelmer, On Saturday 19 January 2008 18:25, Jelmer Vernooij wrote: I am looking for a sponsor for my package line6-usb. The package looks good, I've uploaded it. Good work! Thijs pgp0zj8VBqUoo.pgp Description: PGP signature
Re: mentors.debian.net reloading
On Friday 26 October 2007 15:26, Lucas Nussbaum wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. I'm not sure if I understand this right, but what would be done with the result of the tests you'd run on mentors? My problem with piuparts is not the setting up, but the amount of false positives it gives, at least on my packages. If you flag packages as does not pass piuparts it may be percieved as a package being of inferior quality, but there may be many reasons to fail piuparts. Most notably piuparts can not discriminate between a problem in my package or in a package I depend on. That could have changed of course in the very recent past? To be clear, I think that piuparts is a very worthwhile tool, but not something to require of packages to pass, or to use as a binary quality measurement for a package. The results are very useful, but only if you thoroughly inspect the cause of failure. Which has to happen by hand. Thijs pgprpQLavkeRr.pgp Description: PGP signature
Re: RFS: php-numbers-roman
On Sunday 16 September 2007 01:56, Raphael Geissert wrote: I think you should talk to upstream and get them to use some other license like LGPL or BSD. The ftp-master's take a particularly hard line on this license and it may require justifying later on if they decide to get picky. I've uploaded quite some packages with a PHP-licence or that have components licenced under the PHP licence, but have not encountered any trouble with that to date. I really recommend asking upstream to change licences, because the PHP licence is admittedly a bit strange or awkward, and there's enough standard, widely known licences that accomplish the same goals. Most problematic is probably point 6, which requires you to state that this project includes PHP. Awkward, but not quite non-free. If upstream do not want to change licences, I recommend you just go ahead and upload it. I've not seen any so called hard line on this in recent times. Thijs pgpGN6LEZGyY6.pgp Description: PGP signature
Re: RFS: php-numbers-roman
Hi Yann, It's one of the packages suggested by the php-image-graph package which is already in Debian. Graphes can optionally have their axes graduated using roman numbers by using the Image_Graph_DataPreprocessor_RomanNumerals preprocessor. But in fact, I packaged it because it's a dependancy of centreon [2], a kind of nagios frontend I want to package for Debian. But you made me wonder if they didn't put as a dependancy because of Image_Graph without actually using it. I checked and indeed they don't use the RomanNumerals preprocessor. So I could drop the package but since I already done the work, I think it would be better to have a suggested package in the archive. What do you think ? I think that in principle the use case seems fair, so it could be uploaded. However, if you only packaged it as a dependency and it's not being used afterall, I'd not go through the trouble of uploading it. You say that the work is already been done, but every package has a maintenance cost associated with it. Because re-doing the packaging of this is not that difficult, I'd suggest to just leave the package for now. If someone actually wants to use the functionality they can make the upload, especially because of the highly specialistic purpose of this package. Of course, this is just my opinion. If you want to upload it nonetheless there's no fundamental problem with that. Thijs pgpaphsohRVBJ.pgp Description: PGP signature
Re: RFS: php-numbers-roman
Hi Yann, On Saturday 15 September 2007 13:22, Yann Rouillard wrote: It builds these binary packages: php-numbers-roman - Provides methods for converting to and from Roman Numerals Are there actual use cases for this package? From the discription it seems to be a bit of a toy, if you know what I mean? Thijs pgppX3hXW5W8a.pgp Description: PGP signature
Re: RFS: cvsps (updated package)
On Thu, September 6, 2007 09:48, Mario Iseli wrote: - dget http://mentors.debian.net/debian/pool/main/c/cvsps/cvsps_2.1-4.dsc 09:45:27 ERROR 404: Not Found. Sorry, I already uploaded this after an IRC conversation on #debian-mentors, I didn't realise that there was also a mailinglist mail about it. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed copyright format
On Thu, September 6, 2007 13:58, Manuel Prinz wrote: There don't seem to be any tools using it right now, and it's not policy. On the other hand, I really don't see any reason not to use it, knowing that some adjustments have to be made if the format changes. What are your thoughts on that? Is anyone using the new format already? debian/copyright is currently free form, there's only requirements on the content. So if you think that this is a good form for your debian/copyright, go right ahead. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mantis (updated package)
On Wednesday 29 August 2007 07:32, schönfeld / in-medias-res wrote: Dear mentors, I am looking for a (one-time) sponsor for the new version 1.0.8-1 of my package mantis, as it seems that the person who sponsors my uploads normally is not available. Hi Patrick, Thanks, I've uploaded it. Could you take a look at the open security issues for Mantis in the security tracker to see what applies to sarge, etch, sid? http://security-tracker.debian.net/tracker/source-package/mantis Thanks, Thijs pgp7AUFHtSXXq.pgp Description: PGP signature
Re: php4 in lenny and Depends
On Sunday 12 August 2007 21:33, Kevin Coyner wrote: I have a package that I maintain that has a dependency on php4-cgi or php5-cgi. If I remember correctly php4 will not be in lenny. Correct me if I was dreaming and misunderstood this. If I am correct, then in any future repackagings of my packages for lenny, do I no longer need to Depend on php4-cgi and now just on php5-cgi? Just want to make sure. This is no longer necessary, that's right. A common strategy I've seen is that: if you have php4 alternates, you can just leave them there for lenny, since it may be a bit easier for those wishing to use it with backported php4, but that there's no real use for adding them on new packages. So if you already have them: you're free to remove them now, but if they don't bother you, you can leave them in place until after lenny has been released. Thijs pgp5sAwhN8EPr.pgp Description: PGP signature
Re: RFS: Many php-* packages to be updated: php-auth-http php-compat php-config php-crypt-cbc php-event-dispatcher php-html-common php-html-select php-image-barcode php-net-ping php-net-portscan php-x
On Wednesday 8 August 2007 08:27, Thomas Goirand wrote: Why did you choose SVN? It's not any better than CVS, it has the same lacks, like not being able to manage unix rights, which is really the basic. Why don't you upgrade to Git or Mercurial which are REALLY a LOT better? Not wanting to get into such a religious discussion, I do think I can correct two things here: saying it's not any better than CVS is untrue, because SVN is (apart from a few details) a feature superset of CVS. It's strictly better, it does what CVS does and it does more (better branching, global revision numbers, file renaming/copying, ...). It manages UNIX rights not in detail but you can set files executable, which I think is the major usecase for UNIX rights in packaging. I'm not sure what other rights you'd need when packaging something, as everything will be reset in the .diff anyway. I plan to improve Requirements for PHP PEAR libraries[*] to have a common policy for all PHP PEAR modules (common packaging, short/long description, procedures to request a new PHP PEAR module package or updating) in order to facilitate team maintainance and have high-quality and uptodate PHP PEAR packages. [*] http://webapps-common.alioth.debian.org/draft-php/html/ch-php-libs.html#s -php-libs-pear This is a VERY good idea, and I think it will help a lot to improve the pear package. Thanks for writing this. I currently maintain some PEAR packages and would be interested in joining such a group. Can you add me to the Alioth group please? My login is 'thijs'. Thanks, Thijs pgpORGKPSqrQL.pgp Description: PGP signature
Re: Help with wrong upload
On Wednesday 8 August 2007 12:35, Kapil Hari Paranjape wrote: 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? Yes, it is. -1 has been propagated to the mirrors already at the most recent mirror pulse, but -2 will follow tonight. Only people whose mirror has been fully updated and have upgraded their system between now and tonight will have the -1 version. Nothing to do about that. Anyone who upgrades after tonight will have the -2 version, and the -1 version will be gone as soon as the next mirror pulse happens. There's always but one solution to a buggy upload that you already have an ACCEPTED mail for: upload a new version. Thijs pgp7I01Qsy2Q3.pgp Description: PGP signature
Re: RFS: Many php-* packages to be updated: php-auth-http php-compat php-config php-crypt-cbc php-event-dispatcher php-html-common php-html-select php-image-barcode php-net-ping php-net-portscan php-x
On Tuesday 7 August 2007 08:41, Thomas Goirand wrote: I knew them, and used them a lot in the past, but as I am doing the packaging using pear install and some rm, I thought it would be more consistent like this. Anyway, this is changed and now using dh_installdocs and dh_installexamples instead, but of course, the rest is still using pear install. If it was a problem, then php-net-ipv4 has it too (which was the example I took). I could have as well called pear install in a temporary build folder, and call dh_install later on, but I thought it was a bit too much. Let me know what you think about this. As it current is, is fine. You shouldn't jump through hoops only to be able to use the dh_ calls, but things for which an dh_ equivalent exists should use it. That was wrong and it's corrected. I first wanted to NOT maintain this package, but it was done, so I finally think it's a bit silly to to have the work uploaded... I have closed the ITP, should I re-open it, or is it all right the way it is ATM? This is fine. The problem was that the website links to the php license 3.01 when the sources notice a 2.02 license, so I did the mistake. Sorry, this is corrected. I have also separated License: and Copyright notice: which is IMHO better. Fine; I think we can best take the licence version as mentioned in the source code. It could be worthwhile to ask the upstream authors of each to sync the licence version in the code with that on the website, but as long as they don't, this is better. I've uploaded all now. Thanks for your work on this and good luck with getting h-inventory packaged. Thijs pgpUflErMkfqF.pgp Description: PGP signature
Re: RFS: php-http-upload
On Monday 6 August 2007 14:04, Nico Golde wrote: Hi, * Thomas Goirand [EMAIL PROTECTED] [2007-08-06 13:31]: [...] Thanks for having a look and if you can sponsor the upload. I am sorry but I won't sponsor any php package, but since the package is in a good shape I hope someone else will. I have. Thijs pgpgvwv6KGTqv.pgp Description: PGP signature
Re: RFS: Many php-* packages to be updated: php-auth-http php-compat php-config php-crypt-cbc php-event-dispatcher php-html-common php-html-select php-image-barcode php-net-ping php-net-portscan php-x
On Monday 6 August 2007 09:08, Thomas Goirand wrote: I would be glad if someone could uploaded these packages for me. Once again, don't get scarred by the amount of package, they are very small, and are built the same way. As I maintain a couple of PEAR modules aswell, I'll take a look at these. Thijs pgpTzNOlhr1wb.pgp Description: PGP signature
Re: Mentors upload not showing up
On Monday 6 August 2007 17:08, Jeremiah Foster wrote: u libcdk-perl_4.9.10-2.diff.gz upload.ubuntu.com Mon Aug 6 15:56:03 2007 upload.ubuntu.com? :-) Thijs pgphoRDEQ8wtG.pgp Description: PGP signature
Re: RFS: Many php-* packages to be updated: php-auth-http php-compat php-config php-crypt-cbc php-event-dispatcher php-html-common php-html-select php-image-barcode php-net-ping php-net-portscan php-x
Hi Thomas, First of all, thanks for your work on this set of packages. In general, they look ok. There's one remark: you seem to not use all the features of the debhelper system. For example you are using 'cp' or 'mv' to install files in different places, while there is dh_install, dh_installdocs, dh_installchangelogs etc. etc. You really should use those. Try dh_tabtab on the command line to see all possible dh_ commands, and use those which are most appropriate. php-html-select - A class for generating HTML form select elements http://mentors.debian.net/debian/pool/main/p/php-html-select/php-html-selec t_1.2.1-2.dsc This one does not exist in the archive - although the changelog mentions an initial release in December. Is that right? For the following packages the following applies: you are changing the licence in debian/copyright to the PHP 3.0 license while they are licensed under the PHP 2.0 license. The source file says so. That is of course not good. php-auth-http php-config php-crypt-cbc php-html-common php-html-select php-net-ping php-net-portscan php-xml-rss Since this concerns nearly all packages, I've also not uploaded the remaining ones for now. Could you please carefully review the licensing of each of the modules and make sure debian/copyright is consistent with the actual code? Let me know when I should review the updated packages. thanks, Thijs pgpyFhUK4Fy9J.pgp Description: PGP signature
Re: RFS: acr38 - 1.7.9-3 (minor update)
Hi, Could someone review and upload acr38 1.7.9-3 Your changes look fine, I've uploaded it. Thanks! Thijs pgputMoPlzDYu.pgp Description: PGP signature
Re: RFS: bmpx (updated package)
Hi Thierry, I am looking for a sponsor for the new version 0.40.0~rc3-1 of my package bmpx. Excellent work, I'm building it now and will upload it if no further problems arise. thanks, Thijs pgpsRU7kBlbxX.pgp Description: PGP signature
Re: RFS: switchconf
Hi Jose, On Thursday 26 July 2007 01:30, Jose Manuel dos Santos Calhariz wrote: I am the upstream author of switchconf package, that is in etch, and I have prepared a new version of switchconf. This version fixes an unreported bug introduced in the last version, add tests to check if switchconf still works as expected and a change to the copyrigth file to give atribution of my work to my employer. I've taken a look and have some minor comments: * In the 'dist' target of the makefile, you do not use maximum compression for the orig.tar.gz. You can consider compressing it with -9 or GZIP=--best * You've gotten a couple of typos into the package. Here's the ones I saw: - changelog: upstrean/upstream, rigth/right and midle/middle * The README file you install doesn't really contain much information over the information already present in /usr/share/doc/switchconf. Is it actually necessary? * You could consider to update the debhelper compat level to 5. Since it looks fine otherwise, I've uploaded your package. Maybe you can correct these points in your repository for a next upload. Thanks for your efforts! Thijs pgpziLghvodL3.pgp Description: PGP signature
Re: RFS: wotsap -- OpenPGP Web of Trust statistics and pathfinder
Hi Giovanni, I am looking for a sponsor for my package wotsap. This page looks good. I've got a few small comments: General: * Have you checked that you conform with the Debian Python Policy? debian/rules: * Why do you run dh_clean -k in the install target? I don't quite understand that. * You can remove the CFLAGS and configure-like stuff, since you're not really using it. * Shouldn't you be using the debian/control: * You depend on wget, but this is only used in one example (not installed binary). That should be a suggests, or recommends at most. If you can fix these items I'll sponsor the package. Thanks for your work! Thijs pgpmML0X9jiAB.pgp Description: PGP signature
Re: ampache security audit
On Wednesday 4 July 2007 06:28, Charlie wrote: Especially for such **insert curse words here** languages like php. Why do you feel that php is a **insert curse words here** language? If PHP is such a **insert curse words here** language, then why does Debian allow apps such as roundcube and gallery2, to mention a few, into the repos? Which language would you recommend using and why do you recommend it? I think Bernd has used unfortunate words to express that in his opinion, it's easier in PHP to create security bugs in your code. I only agree to that to a limited extent. The most important problem, register globals, has been resolved (Debian tells users not to use that setting or be on their own). However, it is true that it's easy to start coding in PHP so there's a higher level of inexperienced programmers. It's also true that web applications in general are more vulnerable to bugs, but this is not PHP-specific. A traditional language like C also has its own classes of security problems. You should be careful with any package you upload to Debian, and specifically web applications. I do not recommend other languages than PHP that are supposedly 'better', because the security of the app depends so much more on the programmers than on the actual language used. You could say that the easiness of PHP selects in favour of less experienced programmers, so an audit can be worthwhile. It helps no-one to be cursing at specific languages and I don't see the added value of that to this list. Thijs pgpKGBfe66l1i.pgp Description: PGP signature
Re: RFS: hwinfo (updated package)
Hi, On Tuesday 3 July 2007 10:11, William Vera wrote: I am looking for a sponsor for the new version 13.35-2 of my package hwinfo. Thanks for taking the time to adopt an orphaned package. I've checked it out and found: * You're adding a file .pc/.version, probably by accident? * There seems to be a new upstream version available. Have you considered packaging that? Thijs pgprXOQX0rehW.pgp Description: PGP signature
Re: RFS: secpanel (updated package)
Hi Bruno, On Sunday 1 July 2007 18:01, Bruno Costacurta wrote: Dear mentors, I am looking for a sponsor for the new version 0.41+0.4.2-4 of my package secpanel. Thanks for your effort to adopt an orphaned package. I've taken a look and have the following points: - Why the strange version number 0.41+0.4.2? - You've made two changes like this: -#!/bin/sh +#!/usr/bin/wish but do not document that in the changelog. - You seemed to have switched the package from non-native to Debian native, perhaps an accident? If you use debuild to build your package you will be warned of that. Otherwise it looks fine. Thijs pgpXdbdc0WTPP.pgp Description: PGP signature
Re: RFS: secpanel (updated package)
On Sunday 1 July 2007 18:12, Thijs Kinkhorst wrote: Otherwise it looks fine. One more thing: there's some bugs open against the package, including a wishlist bug regarding a new upstream version. Perhaps you want to take a look at those to see whether you can address them? Thijs pgpI0XF2rc02N.pgp Description: PGP signature
Re: ampache sponsor
Hi Charlie, On Sunday 1 July 2007 12:43, Charlie wrote: Dear mentors, I am looking for a sponsor for my package ampache. I've taken a look and have found the following remarks. * You install under /usr/share/ampache. The webapps policy (still draft, but not quite controversial) recommends /usr/share/ampache/www. I suggest to change it because changing it later can be bothersome. * Your debconf template reads: Ampache supports any web server that php and mysql does, but this automatic configuration process only supports Apache2. Please select which apache version you want to configure. It only supports Apache2 but you can indicate which version to configure? That doesn't make sense. You also sometimes write Apache and sometimes apache. * You depend on php5-common, is that really necessary or already satisfied by the other dependencies? * You depend on dbconfig-common but don't use it. * debian/copyright reads: This package was debianized by root [EMAIL PROTECTED]. * In debian/rules you do some loops to install your files. Can't you use the dh_install call to handle this for you? Otherwise it generally looks quite ok, thanks for your work! Thijs pgprCCp7T2dD4.pgp Description: PGP signature
Re: how to fix nmlist.php and other error in NM webpages?
On Thursday 28 June 2007 12:24, Rudi Cilibrasi, Ph.D. wrote: It seems that more should be less in the above sentence. The same error appears again on the New Maintainer's Page as well. I could not find a mailing list to report this. How do we report bugs against these pages? Best regards, This list is fine, the 'nm.debian.org pseudo-package in the BTS is even better. Send mail to [EMAIL PROTECTED] with Package: nm.debian.org on the first line and your report in the body. thanks for your help, Thijs pgpbBxerqSufR.pgp Description: PGP signature
Re: RFS: mantis (updated package w/ security fix)
Hi, On Wednesday 20 June 2007 04:12, Kevin Coyner wrote: I believe I've prepared this appropriately. In debian/changelog I set urgency to 'high'. I know this will get it into unstable on an expedited basis, but am unsure how to get the fix into stable. It looks good, I've uploaded your package. A small detail I would change for the next time: your patch under debian/patches also contains a hunk only changing whitespace at the end of the file. I would leave that hunk out. I read: http://www.us.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-sec urity-building and my impression is that the next step is to contact [EMAIL PROTECTED] Please let me know if this is correct. It should normally be correct, but as it seems the security team has been proactive about this and have already made an upload to stable-security yesterday evening (DSA-1315-1). So that's taken care of. You were right that you indeed would have to contact [EMAIL PROTECTED] to make uploads to stable-security. They mostly can also sponsor your upload for stable-security if that's needed. thanks, Thijs pgpgFgxh904eY.pgp Description: PGP signature
Re: Adopting boa
Hi François-Denis, I'm looking into adopting the small webserver boa. The package has received a number of NMU over the years and has recently been uploaded by Debian-QA. I know the proper procedure if I adopt boa would be to close the bugs fixed by NMU, but that seem as simple to me as adding close entries to the changelog. Am I wrong on that? I assume we're talking here about the bugs tagged as fixed but not yet closed. It used to be common practice to include these in the changelog and close them in the next maintainer upload, and that still works. However, with the version tracking in the BTS, the best way is to send a message [EMAIL PROTECTED] with a Version: nmu-version pseudo-header. This is because the bugs in question were actually fixed in the nmu-version so closing them with that version would be the most accurate expression of their status. Thanks for your interest in getting boa properly maintained. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About md5sums of debian sources
On Tuesday 5 June 2007 06:54, Roberto C. Sánchez wrote: Yes. But then what of projects like OpenOffice.org and gcc? No one has said that bzip2 should be *required* as a compression format, only a possibility. I see the use in that: I've seen several upstreams shifting from gzip to providing only bzip2 tarballs. In many cases these tarballs are quite small, and I don't see much added value in repackaging those to .gz. Thijs
Re: ITA or ITP, for former Debian packages?
On Wednesday 23 May 2007 13:30, Neil Williams wrote: If the package is in Debian and orphaned: ITA If the package is not in Debian (whether it ever was before or not): ITP. It makes sense to base your work on the previous package anyway, since that might have solved some issues that you didn't think of yet, and it would be a pity if those resurfaced. Packages removed from releases are still in current testing or unstable, and packages removed from Debian entirely can often still be found on snapshot.debian.net. Good luck! Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pastebinit
Hi, I am looking for a sponsor for my package pastebinit. I've taken a look. pastebinit is a command-line tool to send data to a pastebin. . It can receive data from a pipe or from a file passed as argument. . It actually supports these pastebins: - http://paste.stgraber.org - http://1t2.us - http://pastebin.com - http://pastebin.ca This does not say what a pastebin actually is. Please explain that briefly in the description. I'm also not sure about the use of the word actually, maybe you mean currently? Or better just leave that word out: It supports these pastebins is just as clear. As to the package, it looks good in general but I'm a bit concerned about you taking the orig.tar.gz from Ubuntu and building a package around it. This means that the upstream author has already made a .deb package, but that you are re-doing his work for Debian, right? To me it would make more sense to collaborate with the maker of the Ubuntu package to make sure the package gets into Debian and can then be imported by Ubuntu, rather than both maintaining separate instances. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: phpesp
Hi, I am looking for a sponsor for my package phpesp. I've taken a look at your package. I've got the following comments: The phpesp package uses webapps-common (and through it dbconfig-common) to configure the web server and database. Webapps-common, implementing the draft Debian web applications policy, should be uploaded to Debian soon (according to Sean Finney, its author). You can find the webapps-common .deb I've used (built from svn head) at http://www.vanbest.org/janpascal/debian/phpesp/webapps-common_0.7_all.deb * This is indeed a great development, but your package cannot be sponsored until webapps-common has also entered the archive, because it depends on it. So it's not that useful to ask for a sponsor now... * The debian dir contains a file 20070427.232755.cc9b68a5.en.html with the ITP. What's that about? * debian/changelog has UNRELEASED as the distribution, not unstable. * You write - After you've installed the packaged, log in as 'root' with the admin password you've entered during package configuration. The default password is 'phpesp'. When will the default password be used and when the one you entered during installation? That's not quite clear to me. And: s/packaged/package/ * debian/rules has a lot of install calls. Why not use dh_install? * You should send the nl.po to debian-l10n-dutch for review, as is the procedure for Dutch translations. I've spotted a tiny spelling error. Otherwise it generally looks good, please feel free to ask again once your dependences are all available in Debian! Before that there's not much to do. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Copyright issues GPL-PHP license
On Sunday 6 May 2007 17:43, David Paleino wrote: Now, as Steve Langasek pointed out in that bug report: PHP is GPL-incompatible. You cannot distribute GPL software together with GPL-incompatible software that it depends on without a license exemption from the copyright holder of the GPL software. Although it's usually safe to assume that Steve Is Right, I think he's made a mistake in this specific case. Note that the application is written in PHP, and not *based on* PHP. Based on PHP it would be if you'd take the C-code of the PHP interpreter and change it to create some new software. I do not think that things like phpmyadmin, squirrelmail or phpbb are license violations. It's comparable to software written in C++: that's also not affected by the licence of the C++ compiler you use. There have never been problems with phpmyadmin in the archive and I don't think there will be. What do you think about this? Should I file an ITP (the package is ready)? However, I think his second point is still very valid. What does this package add to the archive? Is there actual use to it, that can't be provided by the webservers already present? Is it at all useful to write a webserver in PHP? Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Copyright issues GPL-PHP license
On Sunday 6 May 2007 18:22, Alex Queiroz wrote: This is a very sad opinion. Is Debian censoring programming languages now? Challenging whether some software would be an asset to Debian is not cersorship by any definition of the word, but voicing an opinion. I'm glad that that is possible in Debian. Thijs
Re: Copyright issues GPL-PHP license
On Sunday 6 May 2007 20:20, David Paleino wrote: I think the situation in Ubuntu is different because there is no real security support for universe (please correct me if I am wrong). Universe corresponds to? Contrib? There's no direct matching here. While in Debian all software in main is fully supported, Ubuntu only supports a relatively small set of software which they call main aswell, and the rest is what is called Universe. Software in Universe does not have guarranteed security support for example. See here for more details: http://www.ubuntu.com/community/ubuntustory/components Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Copyright issues GPL-PHP license
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. Right. The main question for me that is not answered here yet, is: what does this http server add to Debian, which already has a dozen of http servers of great variety? Does it have a real world advantage over others? Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: php-adodb
On Friday 4 May 2007 10:56, Neil McGovern wrote: I am looking for a sponsor for my package php-adodb. Hi there, How is this different from libphp-adodb? Have even read his message? | php5-adodb - Extension optimising ADOdb database abstraction library | * This package is the PHP extension, not the actual library written | in PHP (which is already packaged as libphp-adodb). Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Removing an obsolete symlink
Hi all, I could use some advice on how to handle the following situation. I adopted a web application package that used to set a symlink under /var/www: /var/www/phpmyadmin - /usr/share/phpmyadmin. This was not good: we shouldn't touch /var/www and not enable phpmyadmin without asking. So now I have the better way of asking the user which webserver to configure, and drop a symlink under the respective /etc/apache-flavour/conf.d dirs. My question is how to deal with this legacy symlink. I can just rm it on upgrade, but the admin might have put a different symlink there, or depends on the symlink to keep phpmyadmin configured. Shall I just leave the symlink there for upgrades, or do something with it, if so, what? Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: avelsieve
Hi! I am looking for a sponsor for my package avelsieve. I've taken a look at this package. It looks very good in general! I have some comments though: * 01_foldersort_bugfix.patch: the patch does not contain a description, neither in the DP-header nor in the code itself. What does it do? Did you forward it to upstream? * Why don't you disable the plugin on package removal/purge? * Make sure your postrm also works correctly if squirrelmail and/or debconf have already been purged. * It makes sense to install doc/NEWS not as a doc but as the upstream changelog, by changing dh_installchangelogs to dh_installchangelogs doc/NEWS. I'm willing to sponsor it if you could review these items. thanks, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: avelsieve
On Tue, April 24, 2007 12:40, Jan Hauke Rahm wrote: * 01_foldersort_bugfix.patch: the patch does not contain a description, neither in the DP-header nor in the code itself. What does it do? Did you forward it to upstream? Well, I don't know where to describe that. The upstream author works on squirrelmail, too. He said the bug was in squirrelmail itself and he tries to fix it there. If that does not work correctly he will include my patch in the next version of avelsieve. The patch just sorts the mailbox folders when creating new rules. So it's nothing heavy ;) Yes, Alexandros indeed works on SquirrelMail aswell. You can describe what a patch does in the lines that start with ## DP: in the patch file. That makes sure that if someone else takes a look at your package they'll know what the patch is about. Okay, testing for squirrelmail-configure is no problem, i've done that now. But how do I change the script that it's working correctly without debconf? Testing on db_input and db_go, too? And what could I do with db_purge? That is needed when purging after usage of debconf, isn't it? In the rare case that debconf is purged before your package, your package should make a best effort to purge as much as it can. Try something like this: if [ -f /usr/share/debconf/confmodule ]; then . /usr/share/debconf/confmodule [do debconf stuff] fi or if necessary, do only this for including the debconf confmodule and use || true to make sure db_purge does not fail when the confmodule is missing. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing an obsolete symlink
On Tue, April 24, 2007 13:10, Daniel Leidert wrote: we shouldn't touch /var/www and not enable phpmyadmin without asking. Why? What is so bad with this symlink? - It touches /var/www which is under the administrator's control; - It does not make sense, since the document root might be somewhere else; - The administrator might want to run the webapp on some vhost and specifically not on the host that is served from /var/www; - It enables the webapp automatically with no good way to disable it; - It's not conformant with the Debian webapps policy. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: avelsieve
On Tue, April 24, 2007 13:34, Jan Hauke Rahm wrote: Okay, I changed that, too. You can find the new package again at http://downloads.jhr-online.de/avelsieve/ It looks fine, thanks for the quick response. I have one question remaining: you depend on cyrus being installed. Is it actually necessary to have cyrus on the local host, or can it also be remote? Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: avelsieve
On Tue, April 24, 2007 14:10, Jan Hauke Rahm wrote: Thijs Kinkhorst schrieb: It looks fine, thanks for the quick response. I have one question remaining: you depend on cyrus being installed. Is it actually necessary to have cyrus on the local host, or can it also be remote? I'm not sure about that. Sieve is connected through port 2000, I guess that's possible remotely, too. I changed that dependency to recommends, you're probably right... Uploaded, thanks for your work! Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Searching doc about debian dir in upstream release
On Wed, 2007-04-18 at 08:40 +0200, Maximilian Wilhelm wrote: Hi! I was ask by a upstream author about the debian-dir in upstream (release) thing where to find documentation about this. I did not find anything on the debian pages or via google by myself. Is there any text, paper, whatever piece of text officially available on this? I'm not really sure what you mean, but I guess that by debian-dir in upstream (release) thing you mean the issue that upstream includes a debian/ dir in released tarballs. That is generally considered a bad idea. I'm not aware of documentation about this in the strict sense of the word, but here's some explanation. You can store the debian/ dir in upstream's VCS, but is is very undesirable to put it into released tarballs. It may seem handy now, but it will create a strange situation when you're no longer part of upstream, or when someone takes over package maintenance, does an NMU or a security update. You will then get a diff.gz that diffs the old and new debian directory. So: keeping it in your upstream version repository is fine, but make sure it's not released. When packaging a new upstream version, combine the tarball with the debian dir at that point. I'll have this added to the Debian Mentors FAQ. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: debian-sec
Hi Tim, It builds these binary packages: debian-sec - debian-sec packages security-client - debian-sec protocol specific client packages security-develop - debian-sec tool and exploit development packages security-emulate - debian-sec host emulation packages security-encrypt - debian-sec data encryption packages security-enumerate - debian-sec host enumeration packages security-fuzz - debian-sec protocol fuzzing packages security-host - debian-sec local host packages security-misc - debian-sec miscellaneous packages security-server - debian-sec protocol specific server packages security-sniff - debian-sec traffic sniffing packages security-tunnel - debian-sec traffic tunneling packages security-wardrive - debian-sec bluetooth and wifi wardriving packages This resembles much of what is already known as a Custom Debian Distribution: a Debian-subproject that aims to make Debian better suitable for a specific application (Children, Medicine, or in this case Security Research) from within Debian itself. What such a CDD does is in short: - Bring people together that are interested in this subject; - Work together on packages for this subject and work to get relevant new packages introduced; - Create a way to easily install collections of those packages, e.g. as per the meta packages above, and/or debtags and/or a customized installer, etc. Here's more background on the subject: http://people.debian.org/~tille/cdd/ http://wiki.debian.org/CustomDebian I would really suggest that you try to create some kind of (potential) group to maintain e.g. the packages above, for example with an Alioth Project, a mailinglist and some announcement about it. Even if you're the only one at first, that makes it easier for other people to join in. If you need more help, there's also a debian-custom mailinglist and channel. Good luck! Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: roundcube
On Fri, 2007-02-16 at 20:20 +0100, sean finney wrote: but for clarity: are these tmpfiles left in /tmp or /var/tmp, or are they in /var/cache somewhere? there are two seperate issues here really: (1) where does the data belong and (2) how should it be managed/deleted? The answer to (1) is that it's in /var/cache/squirrelmail/ and to (2) is to use the same tool that manages /tmp since desired behaviour is the same, so no need to reinvent the wheel. Keep the code in one place. Thijs signature.asc Description: This is a digitally signed message part
Re: new package splix
On Thu, 2007-02-15 at 18:09 -0300, Carlos Pasqualini wrote: SpliX is a set of CUPS printer drivers for SPL (Samsung Printer Language) printers. If you have a such printer, you need to install and use SpliX. Moreover you will find documentation about this proprietary language on the splix website at http://splix.ap2c.org/. Note that only SPL2 and SPLc printers are currently supported! However we are looking for people who have a SPL printer to implement it as soon as possible. I do not understand the situation with this package. You do claim to support some SPL printers, but the last sentence asks for people with a (any?) SPL-printer to implement it as soon as possible. Implement what? This description could be improved. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: roundcube
On Tue, 2007-02-13 at 21:54 +0100, Vincent Bernat wrote: OoO En ce début de soirée du mardi 13 février 2007, vers 21:34, Thijs Kinkhorst [EMAIL PROTECTED] disait: As for the binary package, that depends on the installed size. For both phpBB and SquirrelMail we did not split the translation up, because each translation is quite small sized. How much space would it cost to install all translations? Less than 1MB. It doesn't seem worthwhile to split all out then. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: roundcube
On Tue, 2007-02-13 at 07:23 -0600, Gunnar Wolf wrote: Vincent Bernat dijo [Tue, Feb 13, 2007 at 01:22:36PM +0100]: MAX_TMPFILE_LIFETIME=15 Do these files really need to stick around for 15 days? I don't think. But it is a safe value. Maybe you should depend on (or recommend at least) tmpreaper for this? It's a neat tool, specialized for the task, and with no ad-hoc and hard to find configurations. Agreed. With SquirrelMail we do not include a cron job, but refer the user to install a package like tmpreaper. No need to be duplicating code all over the place. Thijs signature.asc Description: This is a digitally signed message part
Re: alioth project creation problem
On Tue, 2007-02-13 at 12:54 +0800, Thomas Goirand wrote: Am I blind and missing something real basic, or does alioth have a problem at the moment? I tried to create a new user without success too. If you have trouble with Alitoh, I find the following options to be very helpful: * Ask on #alioth on irc.debian.org. The admins are mostly helpful and respond quickly. * File a support request on Alioth itself: http://alioth.debian.org/tracker/?atid=21group_id=1func=browse Doesn't work for the account creation issue since you need to be logged in, but does for creating new projects. * Mail to [EMAIL PROTECTED] See also the wiki on Alioth: http://wiki.debian.org/Alioth Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: roundcube
On Tue, 2007-02-13 at 11:31 -0800, Richard Laager wrote: Personally, I think repacking the tarball would be the lesser of two evils. I'd unpack all the language tarballs into some subdirectory, creating something like this (using two random language tarballs that I looked at as examples): With phpBB we have the same issue, and decided to package all into one source tarball instead of creating 20+ source packages of a very small size each. I definately see the repackaging as a far lesser problem (the concrete problem with that is quite minimal) than creating many source packages, which all need to be stored separately on the mirrors, and would also get treated separately by all Debian tools. As for the binary package, that depends on the installed size. For both phpBB and SquirrelMail we did not split the translation up, because each translation is quite small sized. How much space would it cost to install all translations? Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: videomanager
Hi Lionel, It builds these binary packages: videomanager - An application for managing your movie collection Thank you for your work. I've reviewed your package and it looks generally ok. I have the following comments: * The program is only in French, but your description in debian/control does not mention that. You need to mention it very clearly. * The watch file gives a 403 error. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: swftools - a collection of SWF utilities
On Fri, 2007-02-02 at 21:44 +0200, Simo Kauppi wrote: The new files are in http://www.mediasitomo.com/debian-swftools/ Thanks, I've uploaded it! Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: swftools - a collection of SWF utilities
Hi Simo, The debian package files are in http://www.mediasitomo.com/debian-swftools/ Thanks for your work! I've reviewed the package. * debian/copyright does not seem to list that most of the contents of the lib/ dir are licenced under the LGPL. * debian/compat: Since you depend on debhelper =5, you could increase the compatibility level to 5 aswell. * debian/patches: your patch filenames have some very generic names, like 05-bugfix.dpatch, and the patches themselves do not have a description inside it. Might be useful to add a description of the patch, so it's clear to anyone else looking at the package what the intention is. Otherwise, it looks ok, but at least the first point needs to be addressed to make the package suitable for upload. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: softbeep (updated package)
On Sat, 2007-01-27 at 00:08 +0100, Florent Rougon wrote: IMHO, this is something that makes 3.7.2.0 and 3.7.2.2 two non-equal Policy versions. I wonder why wasn't this 3.7.3.0 instead? Hmmm... maybe because the should in 3.7.2.0 was actually obviously a must for security reasons? Exactly... since it's plain stupid to have these files world-writable, it is a bug in the text that it was not written that way, not a change of what you should do. You should already not make these world-writable of course. Thijs signature.asc Description: This is a digitally signed message part
Re: extra-license-file best pratices
On Fri, 2007-01-26 at 13:56 +0100, Andrea Bolognani wrote: 1. Being upstream for the software, just edit the original Makefile so the `install' target skips COPYING.gz 2. Edit the Makefile only in the Debian package, commenting out the offending lines 3. Remove the file in debian/rules, *after* installing it I use the third option. Personally I prefer not to make changes to the upstream sources when I can solve it just as well with my Debian scripts. I also see no drawbacks in the third option. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: elinks (updated package)
Hi Ahmed, On Fri, 2007-01-26 at 14:20 +0200, Ahmed El-Mahmoudy wrote: Dear mentors, I am looking for a sponsor for the new version 0.11.1-1.3 of my package elinks. Thanks for your work. I will not upload for the following reason: you're NMU'ing a package, but not for fixing a bug that is in the BTS. The developer's reference prescribes to only NMU for bugs that are already reported. This is to give the maintainer a chance to comment on it or fix it him/herself. If there's a particular urgency for the bug, then you can file it *and* NMU it right afterwards. You need a bug to attach the diff to anyway. So file the bug you want to fix first. The maintainer looks very Missing In Action from a first look. I suggest you have the package orphaned by the QA team, see the developer's reference for more information on this. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: softbeep (updated package)
Hi, On Fri, Jan 26, 2007 at 02:18:56PM +0100, Thijs Kinkhorst wrote: * There are open bugs in the bts for softbeep, which have no response yet, and might have some merit. Have you looked at the bugs? Can they be fixed in this upload? If not, you could respond to the reporters why it will not (yet) be resolved. Ok, will look at it. * You install the upstream file RELEASES as documentation, but it is some sort of a changelog. I propose to have it installed by dh_installchangelogs instead. Well, that's how the package was. Anyways, I just read the manpage of dh_installchangelogs, but I don't understand how to use it to specify RELEASES as a changelog. Try this: dh_installchangelogs RELEASES * Your patches have very generic names: 01-shlibs.dpatch 02-sb.dpatch 03-sb-beep.dpatch, and there's multiple unrelated changes per file. I'd prefer if the filenames describe what the patch does, and that you separate the patches per subject. This makes it easy to add, update or remove a specific patch. Again that's how the package was, I only added 03-sb-beep.dpatch. Ok, it's not a blocker for uploading, and mostly your preference. I do think that mixing unrelated changes in one patch can be inconvenient. The nice thing about a patching system is that you can easily add, edit and disable a specific change. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
On Mon, 2007-01-22 at 19:51 -0500, Roberto C. Sanchez wrote: I disagree. How do I know that r91 was committed two days ago? This also does not hold for regular, released versions. I don't see why this should be conveyed in the version number of snapshot packages and not for regular releases: how fresh is version 2.1.8 of a package? Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: jabbin
On Tue, 2007-01-23 at 19:46 +1100, Andrew Donnellan wrote: I'll have a look at the patches that were suggested earlier - I may apply them upstream as I have access to their repo. I'm also going to prepare a new version very soon. Just to let you know - your package looks very good otherwise. Thijs signature.asc Description: This is a digitally signed message part
Re: native packages
On Tue, 2007-01-23 at 21:34 +1100, Andrew Donnellan wrote: What exactly are the advantages and disadvantages of making a Debian-native package, and is there any real policy or practice? I think this is a good rule: If the source is published outside of Debian, do not make a native package. The disadvantage of a native package is that there's no clear separatation of what is upstream and what changes are made by Debian. There's no clear advantage of using a native package as far as I know. You only use a native package when there just isn't such a thing as an upstream tarball (i.e.: there is no upstream, the package is only developed within Debian). Thijs signature.asc Description: This is a digitally signed message part
Re: native packages
On Tue, 2007-01-23 at 21:45 +1100, Andrew Donnellan wrote: In this particular project I am a member of upstream (packager, proofreader and copywriter for English website) and I want to store my debian/ directory in upstream's SVN as it makes it much easier for me to manage snapshots, updates, and so on. If debian-native packages are discouraged then is there a good way to keep the debian/ dir with upstream's VCS? You can store the debian/ dir in upstream's VCS, but is is very undesirable to put it into released tarballs. It may seem handy now, but it will create a strange situation when you're no longer part of upstream, or when someone takes over package maintenance, does an NMU or a security update. You will then get a diff.gz that diffs the old and new debian directory. So: keeping it in your upstream version repository is fine, but make sure it's not released. When packaging a new upstream version, combine the tarball with the debian dir at that point. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: ballview - A free molecular modeling and moleculargraphics tool
On Tue, 2007-01-23 at 11:52 +0100, Andreas Moll wrote: I don't think the 'deb-ball-source' dir belongs in a clean source package. I guess you are right. Could you tell how to delete it with the deb-helper tools? What created that dir originally? Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: ballview - A free molecular modeling and molecular graphics tool
On Mon, 2007-01-22 at 11:46 +0100, Andreas Moll wrote: I am looking for a sponsor for my package ballview. The changelog says: * Initial release (Closes: #) is the bug number of your ITP So you probably forgot to replace '' :) See also the file README.Debian, it still has possible notes regarding this package - if none, delete this file. The docs file is empty, so can be removed. I'm quite surprised by the two scripts in your debian dir: createBALLVIEWDEB and debian-ball-install. Why are you using these, and not place the commands in debian/rules? The latter is the place for commands that build your package. Many of the things you do in those scripts can be done by the available debhelper dh_* scripts. I don't think the 'deb-ball-source' dir belongs in a clean source package. The licence statement in ./STRUCTURE/numericalSAS.C seems very incompatible with Debian: * An academic licence agreement for the package ASC/GM or its parts * is granted if you make the following commitments: * 1) In using this software, the user will respect the interests of * the author. * 2) The use of the software in commercial activities is not allowed * without a prior written commercial licence agreement. * 3) Other interested research groups will be redirected * to the author. The user will not redistribute the code outside * his immediate research group. * 4) The copyright messages will not be modified or suppressed. * 5) The reference given below will be cited in any publication * of scientific results based in part or completely on use of the * program. * 6) Bugs will be reported to the author. This must be mentioned in debian/copyright, and, if this stays this way, I think the package must be in non-free. However, it's of course possible to contact the upstream author to see whether either this code can be removed (it seems only a small part), or the original copyright holder can be contacted for relicencing. I get the following error while building the package in a clean environment (cowbuilder): checking for libpython... No libpython*a found in /usr/lib/python2.4/config/. Please specify the path where your Python library resides using --with-python-libs=DIR or ensure that libpython is installed in the correct directory (sys.prefix is /usr) Lintian still shows a native-package-with-dash-version warning. Could someone please explain me how to solve this issue? That is because you have packaged it as a native package, probably by accident. Make sure that the upstream tarball is correctly named and in the right place: it should be ballview_1.2.orig.tar.gz. The 'debuild' command warns if this is not right. Please rebuild it as a non-native package. If you need help resolving any of these problems, just ask! Thanks for your work so far. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: whitedune : Graphical VRML97 viewer, editor, 3D modeller and animation tool
Hi Philippe, On Sat, 2007-01-20 at 00:35 +0100, Philippe Coval wrote: I am looking for a sponsor for my package whitedune. Thank you for your work. I've taken a look. I've got the following comments: debian/changelog: * The changelog mentions two previous versions from 2002, but I can't find these anywhere (in the archive or on snapshot.d.n). Have they been in Debian? Does your package share any history with those? * You may want to close the ITP bug in your changelog entry. debian/control: * The extended description for whitedune could use some formatting newlines to make it easier to read. While you're at it, I find it to be a bit confusing. The program seems to be called white_dune some of the times and Dune otherwise. It may be better to start the description with what whitedune specifically can do, and then use later paragraphs to go into detail on what VRML is for those who don't know. Information about where to find information on translating is a bit overkill for the extended description. You should consider that this text is meant to be read before installing the package, to know whether it will be useful to you. The details can be contained in the /usr/share/doc dir which is available after installation. * You provide a whitedune-doc package, but the whitedune package does not Suggests it. * You are Suggests-ing other tools that seem to provide similar functionality to whitedune. If you have whitedune, how would installing those other packages improve the way you use whitedune? * The package does not build because aclocal is needed. You might need to depend on automake1.9 to make this work (try pbuilder or cowbuilder to test whether your packages build in a clean environment). debian/docs: * You install quite some docs in the regular whitedune package. Why are these not in whitedune-docs? * You duplicate some of the files here in whitedune.docs which does the same (docs means: docs to be installed in the first binary package, which is whitedune). You can safely drop whitedune.docs. When reviewing the changes you made to the upstream software, I see you (accidentally) dropped the word rights. from COPYING. You also seem to make whitespace-only changes to the upstream source, e.g. in Makefile. Is that necessary? Did you forward your changes to upstream code and docs to the upstream authors? Good luck with your package! Thijs signature.asc Description: This is a digitally signed message part
Re: What to do if my package doesn't build on some architecture
Hi Kumar, On Fri, 2007-01-19 at 20:47 +0530, Kumar Appaiah wrote: Now, I would like to know how to bail the package out of this situation. Do I try to fix the problem, referring it to upstream, or is it that I should somehow block this architecture now and keep my fingers crossed hoping it gets solved automagically later? How am I to act? Besides, I don't have access to such a machine! It definately needs to be fixed. Debian is releasing on a set of architectures, and for those architectures Debian will provide all packages where reasonably possible. Blocking or excluding an architecture is only suited for cases where support by the package is really unfeasible, which seems not the case here. Possible solutions are indeed to check this with upstream to see if they can solve it. Debian Developers also have access to every supported architecture, so you can ask for their help in debugging. Especially the porters for the given architecture should be able to help. So, check whether upstream can solve it and/or tag the bug 'help' and send a mail to the relevant porters list. Good luck! Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: sshproxy
Hi Bernat, On Sat, 2007-01-20 at 14:38 +0100, Vincent Bernat wrote: I am looking for a sponsor for my package sshproxy. There is currently one bug in the package due to a problem in cdbs : bug #386970. I don't know wthat the correct work around is. I'm sorry, I can't help you with this. The package is almost lintian free. I have put an override for INSTALL which contains post-setup instructions. Maybe it makes sense to move these instructions to a file called README.Debian for example, because the naming of INSTALL doesn't make it clear that it contains things other than installation instructions. And it is compiled as a native package but numbered as a non native package. In fact, the author quickly incorporate the changes I do on the debian package into the upstream source. Therefore, I am not sure if I have to make this a native package or not. Please do not make it a native package. The author might incorporate things now but this may not happen in the future. Someone NMU'ing the package probably does not have contact with the upstream maintainer. What advantage do you have to make it native anyway? I think this is a good rule: If the source is published outside of Debian, do not make a native package. Thijs signature.asc Description: This is a digitally signed message part
Re: Tone-of-voice used by sponsors
On Sun, 2007-01-14 at 16:43 +0100, Bart Martens wrote: On the other hand, the sponsor is completely free to choose which packages he wants to sponsor. And it is good that sponsors encourage new packagers to have an eye for the little things too. Let's not shoot Daniel for being just a bit more strict than other sponsors, and be happy that he sponsors so many packages. And keep in mind that the tone-of-voice in e-mails is always more harsh when read than when written. :) I would recommend that any sponsor keeps that last thing in mind. Debian-mentors is supposed to be the friendly resource to get acquainted with Debian packaging. I often find the lists that Daniel posts to resemble commands remove this., do not do that, this is bogus, that is useless but lacking of background or guidance. If you take a look at some other sponsors, you will see that if they have some criticism on a package, they will often include *why* it is a problem, and/or how to solve it. This doesn't have to be long. Compare: * do not build a native package. with: * The package is Debian native, but the software is not Debian specific. The customary way to package software that has an upstream is to use the non-native packaging, which makes the package consist of a .orig.tar.gz from upstream and a .diff.gz for Debian. This clearly separates what modifications are done by Debian. There's a bit of text about this in the FAQ: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html (example from this list) I think the latter is the form that suits the Debian Mentors list best. Of course there's no rules, but I'd prefer it nonetheless. Thanks for considering. Thijs signature.asc Description: This is a digitally signed message part
Re: Tone-of-voice used by sponsors
On Sun, 2007-01-14 at 15:11 -0400, Muammar Wadih El Khatib Rodriguez wrote: He imposes a high quality standard when he sponsors a package. I'm not sure about this reference to a quality standard multiple people in this thread are making. I did not question anything about the quality, just about communications. I think Daniel's quality standards are not exceptionally high, or low, compared to other sponsors. That is, if you don't consider a newline in a textfile a quality measure of course. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: poco
On Sat, 2007-01-13 at 22:12 +0100, Krzysztof Burghardt wrote: and, are you going to package the docs (assumed they are redistributable, i didn't check for that)? Yes, but if it is another upstream tarball should I make another source package? Yes, that's right. Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: podget
Hello Dave, It builds these binary packages: podget - Podcast aggregrator/downloader optimized for cron The package is lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/podget - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/podget/podget_0.5.8.dsc I would be grateful if someone would upload this for me. I've checked it out, and have the following comments: * The package is Debian native, but the software is not Debian specific. The customary way to package software that has an upstream is to use the non-native packaging, which makes the package consist of a .orig.tar.gz from upstream and a .diff.gz for Debian. This clearly separates what modifications are done by Debian. There's a bit of text about this in the FAQ: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html * The upstream tarball contains a debian dir. This is not desirable at all; there have been quite some discussions on this list about that. Please ask upstream to not release tarballs with a debian dir in it. Keeping the debian dir in upstream cvs is not a problem, as long as its clearly separate and not in released code. * debian/docs and debian/dirs are empty, they can be removed. * debian/rules looks good, but you make a bit of a mix between invoking the debhelper tools and doing things directly (mkdir, dpkg-deb, etc). I wonder why not use the existing debhelper tools, like dh_installdeb ? thanks for your work! Thijs signature.asc Description: This is a digitally signed message part
Re: Opinions on CDBS amongst sponsors
On Wed, 2006-12-13 at 10:29 +0200, Jari Aalto wrote: Especially adding the EXAMPLES sections would greatly improve all the manual pages by listing the typical usage cases. Here is an exerpt. Patches are probably most welcome ;) Thijs signature.asc Description: This is a digitally signed message part
Re: Subject: RFS: mantis (updated package)
Eric Lavarde - Debian wrote: Hi, * debian/copyright is incomplete, you need to list all copyright holders and their licenses. e.g. adodb and phpmailer is missing (and likely also others, stopped after finding these two). Hmm. Do i really need to do this? Because my debian/rules don't install them, as i patched the sources (with patch 01 and 02) to use the debian packages of them instead. I just did not want to change the orig tarball for this. You need to clean up the orig tarball (written somewhere in the policy). And then the copyright question is solved as well. No, you don't! You *only* modify the source tarball to remove things that are not free. The software is free but you don't install it into the deb. That's fine, but still notice it in debian/copyright: that file covers all licences, whether stuff is installed into the deb or not, since we are distributing the source tarball. It would make sense though to make it explicit that this only applies to the source package. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Subject: RFS: mantis (updated package)
Hello Patrick, I am looking for a sponsor for the new version 1.0.6-1 of the package mantis. Package is orphaned, i am the adopter of this package. It builds these arch-independent packages: mantis - web-based bug tracking system Good to see that Mantis is getting a new maintainer. Please note that there have been numerous security issues with Mantis in the recent past. So you must be willing to dilligently backport any issues that may arise to the stable release. It's not that hard, but there have been problems with this in the past. Please be prepared :) thanks, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: sqwebmail-de: german templates for sqwebmail (fixes RC-bug)
On Sun, 2006-11-19 at 12:21 +0100, Daniel Baumann wrote: Neil Williams wrote: Why is this double space seen as mandatory? - it is not. Single spacing is fine in most cases. roumors has it that some automatic tools are in need of having two leading spaces. This is way too vague, because I have yet to see one (1) concrete tool to be mentioned that actually breaks when not doing this. If you look at common tools like aptitude and packages.debian.org, they work just fine... look at policy, as long as it is not fixed there, it should be kept as it is (with two leading spaces). Maybe you should be the one looking at policy, because it's not in there :) The devref spends 5 paragraphs on specifying the format of this field, that itself is contained in the description field. Way overengineered, and there's no concrete problems with the simple way. Let's stop with this extra space thing that serves no advantage. It you think there is, please provide us with a concrete real-world description + tool that breaks on it. Thijs signature.asc Description: This is a digitally signed message part
Re: Question: piuparts and mysql-server
Hello Kevin, On Wed, 2006-11-15 at 16:06 -0500, Kevin Coyner wrote: Here's the catch: I presently have mysql-server listed as a Recommends: because mysql can be run on another box other than the localhost. This seems to be the approach of many similar packages like drupal, diogenes. O.k. Yes, this is correc. So if mysql-server is a Recommends:, then running piuparts will always fail. Is this just a limitation of piuparts? I wonder why your installation fails without a MySQL server available. I could go into details about the way you configure databases, but the following question seems more appropriate: why don't you use dbconfig-common as the way to configure your database? It concentrates code for packages wanting to configure databases into one place, making sure such issues as these are not solved again and again for every package. Thijs signature.asc Description: This is a digitally signed message part
Re: Help with updating nco package?
On Sat, 2006-11-11 at 13:26 -0800, Charlie Zender wrote: Damyan Ivanov wrote: nco is currently maintained by Debian QA Group. Are you willing to take over? If so, you should tell them. Yes, I would like to take over nco maintainance, if it's OK with them. I'm not a debian developer (yet) so I would need a mentor. If you want to take over an orphaned package (maintainer Debian QA Group) you are normally free to do so. The process of adopting a package is detailed in the Developer's Reference. I see you have found the WNPP bug. It's currently titled as if Daniel Baumann is planning to take it over. You should discuss with him who is going to be the maintainer (or use some kind of co-maintenance - I've found it to be very useful if a package is co-maintained by someone with Debian knowledge and someone with upstream knowledge). As with the specifics of your package the following: - You have put the debian/ directory into upstream CVS. This is no problem, but it must *not* be in any released tarballs. There's detailed information / discussion about this to be found in the -mentors list archives, but in short: this gets weird if someone changes the package within Debian without committing it to upstream (e.g. a later NMU). - Your package is Debian native while there's no reason to. You should make it a regular package, i.e. with an orig.tar.gz as it is released upstream, and a .diff.gz containing Debian-specific changes. Good luck with packaging! Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: renrot - a program to rename and rotate files according to EXIF tags [EMAIL PROTECTED]
On Mon, 2006-11-06 at 18:43 +0200, Andy Shevchenko wrote: And it's a Perl script. The arch is all and not any, since it's not an arch specific binary. Oh, thanks. I've rebuilt the pacakge. In general it looks good, but I have the following comments: * The description can be improved. Description: A program to rename and rotate files according to EXIF tags A program to is superfluous and should be removed. Renrot renames files according the DateTimeOriginal and FileModifyDate EXIF tags, if they exist. Otherwise, the name will be set according to the current timestamp. Additionally, it rotates files and their thumbnails, accordingly Orientation EXIF tag. accordingly - using the There's also the problem that your description does not contain references to JPEG or photos. If I'm looking for rotate and photo or rotate and JPEG I will not find it. I propose the following revised short- and long description: Description: Rename and rotate photos according to EXIF tags Renrot renames JPEG files according the DateTimeOriginal and FileModifyDate EXIF (metadata) tags, if they exist. Otherwise, the name will be set according to the current timestamp. Additionally, it rotates images and their thumbnails, using the Orientation EXIF tag. * In debian/watch, replace update with uupdate. * In debian/rules, you call the distclean target but your upstream makefile doesn't contain that target. Otherwise, it looks good. Good luck with your package! Thijs signature.asc Description: This is a digitally signed message part
