Re: How to write emacs dependency ?
Craig Small wrote: On Wed, Nov 11, 2009 at 06:51:01PM +0100, Sven Joachim wrote: On 2009-11-11 16:43 +0100, Christoph Egger wrote: Depends: emacs21 | emacs22 | emacs23 | xemacs21, gnus | emacs22 | emacs23 | xemacs21 This does not give you any guarantee that somebody trying to run darcsum on emacs21 has the gnus package installed. It does, let's say you have emacs21 installed but not gnus. The first clause matches emacs21, so its satisfied. The second, nothing matches, so you have an unmet dependency. For instances off emacs22, emacs23 and xemacs21 then whatever is installed meets both clauses. No it doesn't, if you have both emacs21 and emacs22 installed AND run darcsum on emacs21 (for whatever reason) you don't necessarily have gnus. So no guarantee with this string. Paul signature.asc Description: OpenPGP digital signature
Re: How to write emacs dependency ?
On Thu, 12 Nov 2009 11:26:35 +1100 csm...@debian.org(Craig Small) said: How about simply dropping support for emacs21? It's an obsolete Emacs flavor version that has been removed from sid already. That is possibly the better idea in that case. I choice this idea. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- 谷口 貴紀 (TANIGUCHI Takaki)tak...@asis.media-as.org http://takaki-web.media-as.org/ tak...@debian.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Building pdf from odt files noninteractively?
Eugene V. Lyubimkin wrote: Felipe Sateler wrote: I have a source package that has pdf documentation, which is generated with openoffice.org. Is it possible to generate said pdf without user interacion (that is, for autobuilding in the buildds)? Or maybe I can just ship the also-included pdf files? AFAICS, the license is not violated. Try unoconv or jodconverter. Some time ago I tried unoconv for my package, but it had issues as can be seen in the bts: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491456#102 Do you know a way to get it done? (I have to look into jodconverter). Paul signature.asc Description: OpenPGP digital signature
Re: insserv: warning: current stop runlevel(s) ... overwrites defaults
Michael Hanke wrote: [...] Can anyone please point me to the problem and its solution? When making changes to the runlevels either via update-rc.d or the lsb header, the init script needs to be removed first (via update-rc.d, as simply removing the symlink won't work in the case of file-rc). In other words: you need to check if the user is upgrading from an affected version (probably anything lt the new version) and then do an update-rc.d remove. All that before the #DEBHELPER# mark so that the rest is done for you. And like Rogéiro Brito said, remove the S runlevel. First of all, S is only used by some special cases where the script only needs to be run once, second, syslog daemons are only available from post-rcS (which at some point would render your package uninstallable because of unmet init script dependencies). Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Sun, 4 Oct 2009, Paul Wise wrote: Write an article for debaday.debian.net about lbzip2 to promote it and get more users/testers. The DebADay Team has reviewed and published my article under [0]. Many thanks to Ana Guerrero, Martín Ferrari, and the rest of the DebADay Team! Also thank you, Paul, for the suggestion. Cheers, lacos [0] http://debaday.debian.net/2009/11/12/lbzip2-parallel-bzip2-utility/
Re: Building pdf from odt files noninteractively?
Paul Gevers wrote: Some time ago I tried unoconv for my package, but it had issues as can be seen in the bts: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491456#102 Do you know a way to get it done? (I have to look into jodconverter). Yes, I saw this bug as well, but worked around it by issuing unoconv several times, so it successfully started the listener on 2nd or 3rd time, but this is indeed unreliable. I cannot say something about jodconverter, I used it many years ago when it was not yet packaged into official archive and don't remember details. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer signature.asc Description: OpenPGP digital signature
Re: insserv: warning: current stop runlevel(s) ... overwrites defaults
On Thu, Nov 12, 2009 at 09:03:59AM -0600, Raphael Geissert wrote: Michael Hanke wrote: [...] Can anyone please point me to the problem and its solution? When making changes to the runlevels either via update-rc.d or the lsb header, the init script needs to be removed first (via update-rc.d, as simply removing the symlink won't work in the case of file-rc). Ah! Thanks a lot, that explains it. In other words: you need to check if the user is upgrading from an affected version (probably anything lt the new version) and then do an update-rc.d remove. All that before the #DEBHELPER# mark so that the rest is done for you. And like Rogéiro Brito said, remove the S runlevel. First of all, S is only used by some special cases where the script only needs to be run once, second, syslog daemons are only available from post-rcS (which at some point would render your package uninstallable because of unmet init script dependencies). Well, the respective package is a firewall. I'd say it should run once in S pretty much right after networking becomes available. It may even not be necessary to run it again when switching to a runlevel other then 0 1 6, correct? So instead of removing S I should remove 2 3 4 5, I guess. Additionally, as you mentioned syslog is not available at that early stage. The question is now whether I should sacrifice the startup log-message for the sake of establishing the firewall as early as possible -- or not? Oppinions very much appreciated! Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: congruity
Dear mentors, I am looking for a sponsor for my package congruity. * Package name: congruity Version : 13+dfsg-1 Upstream Author : Stephen Warren s-t-concorda...@wwwdotorg.org * URL : http://sourceforge.net/projects/congruity * License : GPL-3+ Section : misc It builds these binary packages: congruity - graphical utility to configure Logitech Harmony remotes The package appears to be lintian clean. The upload would fix these bugs: 512599 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/congruity - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/congruity/congruity_13-1.dsc I would be glad if someone uploaded this package for me. Kind regards Mathieu Trudel -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: swami - libgtk1.2
Jaromír Mikeš wrote: Od: Paul Wise p...@debian.org Get upstream to port it to GTK+ 2.0 and ensure that it will be compatible with GTK+ 3.0 (which will remove a bunch of deprecated stuff from GTK+ 2.0). An alternative would be to send upstream a patch for that. If upstream is not active you could take over the upstream project: http://sourceforge.net/apps/trac/sourceforge/wiki/Abandoned%20Project%20Takeovers -- Thank you for help. Just going contact upstream. regards mira Hmm, sorry this is so late but I just ran across this. The newer versions of swami from upstream do use GTK2 but seem to be in a developmental state. Have you talked to them? Thanks, Barry deFreese Debian QA -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: congruity
OoO Lors de la soirée naissante du jeudi 12 novembre 2009, vers 17:28, Mathieu Trudel-Lapierre mathieu...@gmail.com disait : Dear mentors, I am looking for a sponsor for my package congruity. * Package name: congruity Version : 13+dfsg-1 Upstream Author : Stephen Warren s-t-concorda...@wwwdotorg.org * URL : http://sourceforge.net/projects/congruity * License : GPL-3+ Section : misc Hi Mathieu! In debian/copyright, you say that remote.png is CC-BY-SA-2.5. Is it the original remote.png (the one removed from the archive to get the DFSG-free version) or the new remote.png? In the first case, you should specify the license of the new one. In the second case, CC-BY-SA-2.5 does not comply with DFSG. You should also build-depends on sharutils to get uudecode. -- panic(Oh boy, that early out of memory?); 2.2.16 /usr/src/linux/arch/mips/mm/init.c pgp2WUxPD1cAK.pgp Description: PGP signature
Re: RFS: congruity
Hi, It builds these binary packages: congruity - graphical utility to configure Logitech Harmony remotes Nice I just bought one yesterday. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/congruity - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/congruity/congruity_13-1.dsc This link doesn't work it should be dget http://mentors.debian.net/debian/pool/main/c/congruity/congruity_13+dfsg-1.dsc Did you test it with pbuilder? Cause it needs sharutils : uudecode debian/remote.png.uu make: uudecode: Command not found Regards, Martijn van Brummelen signature.asc Description: OpenPGP digital signature
Re: RFS: congruity
On Thu, Nov 12, 2009 at 11:56 AM, Vincent Bernat ber...@debian.org wrote: In the first case, you should specify the license of the new one. In the second case, CC-BY-SA-2.5 does not comply with DFSG. You should also build-depends on sharutils to get uudecode. Indeed, I'm still good too fast. I knew it needed sharutils, and that I needed to add it to Build-Depends... I just re-did my upload to mentors with these changes. CC-BY-SA-2.5 was the license for the old file. The new one is GPL-3. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/congruity - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/congruity/congruity_13-1.dsc Regards, / Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: php-net-ipv6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package php-net-ipv6. * Package name: php-net-ipv6 Version : 1.1.0b2-1 Upstream Author : Alexander Merz kont...@alexander-merz.com * URL : http://pear.php.net/package/Net_IPv6 * License : BSD Section : web It builds these binary packages: php-net-ipv6 - Check and validate IPv6 addresses The package appears to be lintian clean. The upload would fix these bugs: 555948 My motivation for maintaining this package is: Working in an ISP environment as systems and network engineer, I see a growing need for tooling to administer and maintain the IPv6 protocol. Having used PHP for most of the tools within my company, I am happy to see this PEAR package being added to Debian. I am confident that I have the time, skills, and most importantly the will to keep this package in good shape for this great distribution. The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/p/php-net-ipv6 - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/p/php-net-ipv6/php-net-ipv6_1.1.0b2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Bas Roos -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr8ei4ACgkQavJDIBG+R54LsgCfRscHDcFXJvK9mYn7JpCxQIea S2UAoNB1nA+bUc3rjxIo9Hk3xw8HTWG5 =SN/L -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to write emacs dependency ?
Paul Gevers p...@climbing.nl writes: Craig Small wrote: On Wed, Nov 11, 2009 at 06:51:01PM +0100, Sven Joachim wrote: On 2009-11-11 16:43 +0100, Christoph Egger wrote: Depends: emacs21 | emacs22 | emacs23 | xemacs21, gnus | emacs22 | emacs23 | xemacs21 This does not give you any guarantee that somebody trying to run darcsum on emacs21 has the gnus package installed. It does, let's say you have emacs21 installed but not gnus. The first clause matches emacs21, so its satisfied. The second, nothing matches, so you have an unmet dependency. For instances off emacs22, emacs23 and xemacs21 then whatever is installed meets both clauses. No it doesn't, if you have both emacs21 and emacs22 installed AND run darcsum on emacs21 (for whatever reason) you don't necessarily have gnus. So no guarantee with this string. Paul dpkg can not express that. The dependency will always be fullfilled by emacs22 being there. Only way out is to go dirty and use plain Depends: gnus | emacs22 | emacs23 gnus already depends on (x)emacs21. MfG Goswin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
scrollkeeper/rarian
Hello, I'm trying to package some manual with a package of mine (of which I'm also upstream), and I'm having big (and unexpected) problems in installing it correctly. Basically, I have the manual files, and then the omf, which, when installed correctly, work fine. However, in the .omf file the path of the manual must be insterted. Now, as upstream I have no problem in doing it in the setup.py. But as packager, this doesn't solve my problem, since setup.py will get as path the fake one. I've read at [0] that scrollkeeper-preinstall should take care of that. Then I found dh_scrollkeeper... and discovered it's obsoleted by rarian, which for being a system of managing documentation seems to be really short of it. In the end: what to do? I saw a package - Jokosher - patching the omfs at build time. I saw many other packages use complex - and, I fear, obsolete - makefiles. I'd really like to avoid both those. thank you for any hint Pietro Battiston [0]: http://scrollkeeper.sourceforge.net/documentation/writing_scrollkeeper_omf_files/ar01s05.html signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Lintian experimental tags (was: RFS: ampache (updated package))
Raphael Geissert geiss...@debian.org writes: Well, experimental checks are not to be considered irrelevant chatter, hence my question. The current experimental checks are: Tag: spelling-error-in-binary Severity: normal Certainty: wild-guess It is based on the output of strings(1) so it can't tell for sure whether a string is actually displayed or it is just a symbol or something else, or whether it is really an error or not (although it is pretty accurate in most cases). I've removed the experimental tag on this for the next release of Lintian. I think it's reasonably mature, and the certainty is wild-guess, which is about right. I changed the severity to minor, since by definition in our BTS spelling errors are minor bugs. minor/wild-guess will make this an info-level tag. Tag: template-uses-unsplit-choices Severity: normal Certainty: possible Erm, IIRC this one should no longer be marked as experimental ever since lenny was released. Will no longer be experimental in the next upload. Tag: embedded-pear-module Severity: normal Certainty: possible PEAR modules are a bit tricky to detect properly without making it too specific, in which case the check itself wouldn't be of much use. Left experimental for the time being. Tag: shlib-calls-exit Severity: wishlist Certainty: possible There's no way for lintian to tell whether the usage of exit or _exit is correct at all in the shared library, and it is based only by looking at the symbols. I'm considering removing this one entirely. It has very serious false positive problems due to generic helper libraries that could call exit but never use that code path in the library code. We have this because it's something that rpmlint checks, but most of the cases of it that I've seen are actually wrong or at least not interesting. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian pickiness and packaging improvements
Manoj Srivastava sriva...@debian.org writes: Ah. I have a few of those. For example, take this warning from Lintian: description-synopsis-might-not-be-phrased-properly This is not policy, but dev-ref, Fixed the cross-reference, which was simply wrong. and when it was proposed, it was argued that if we had a non clause, the front ends can make it look nicer, by completing the sentence, adding the period, etc, (perhaps by showing Package is a short description . That was around 6 years or so ago. [...] And why is this a warning as opposed to an informational message? How is the package impacted by having a gosh darned period in the short description? This is the same level of impairment as the other non info warnings? seriously? Thisis not a severity normal bug. It is not even a severity wishlist bug. It is a style issue. I think an argument could be made that it's a severity: minor bug from a consistency perspective, but not normal. I've therefore now downgraded it to severity: minor, which I think more accurately represents how important it is. Since it's also certainty: possible, this downgrades it to an info-level tag. Things like that are why I take every lintian warning with a huge grain of salt. Any others? :) Ideally, Errors should correlate to important+ bugs, and must violations, I think, warnings are bugs (minor and normal) and should violations, and everything wishlist ought to be a informational message. Style things belong in experimental. And, to give credit where it is due, the majority of the tags are listed at their proper severity. But by no means all of them are. Style things belong in pedantic, unless they're fairly widely agreed-on, in which case they belong as severity: minor. In general, though, I agree with the above. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: congruity
On Fri, Nov 13, 2009 at 2:00 AM, Mathieu Trudel-Lapierre mathieu...@gmail.com wrote: On Thu, Nov 12, 2009 at 11:56 AM, Vincent Bernat ber...@debian.org wrote: In the first case, you should specify the license of the new one. In the second case, CC-BY-SA-2.5 does not comply with DFSG. You should also build-depends on sharutils to get uudecode. Indeed, I'm still good too fast. I knew it needed sharutils, and that I needed to add it to Build-Depends... Now that the archive accepts them, it would be better to switch to the v3 source package format, which converts the diff.gz into a debian.tar.gz, so you don't need sharutils at all. See the dpkg-source manual page, search for 3.0 (quilt) and here: http://wiki.debian.org/Projects/DebSrc3.0 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
