Re: RFS: aspell-id ; second try
Mahyuddin Susanto udi...@debian-id.org writes: Dear mentors, I am looking for a sponsor for my package aspell-id. * Package name: aspell-id Version : 1.2-0-4 Upstream Author : Benitius Brevoort benitius.brevo...@kapusin.org * URL : http://translationproject.org/team/id.html * License : GPLv2+ Section : text It builds these binary packages: aspell-id - Indonesian (id) dictionary for GNU aspell The Provides: aspell-dictionary is still missing... -- Captain Logic is not steering this tugboat. -- 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/8739qar0nl@bignachos.net
Re: RFS: aspell-id
Jonathan Nieder jrnie...@gmail.com writes: Hi, Mahyuddin Susanto wrote: * URL : ftp://ftp.gnu.org/gnu/aspell/dict/id [...] - dget http://mentors.debian.net/debian/pool/main/a/aspell-id/aspell-id_0.1-2.dsc The .orig.tar.gz seems to be a git clone of git://github.com/udienz/ispell-id.git, though the files match aspell5-id-1.2-0.tar.bz2. I would suggest: - setting the version number in debian/changelog based on the upstream version: aspell-id (1.2-0-1) unstable; urgency=low * Initial package for Debian (Closes: #604557). * Add simple rules file (using cdbs, based on such-and-such documentation), a control file describing the binary package, and an appropriate compat file. -- Mahyuddin Susanto udi...@gmail.com ... whenever ... - putting a copy of aspell5-id-1.2-0.tar.bz2 named aspell-id_1.2-0.orig.tar.bz2 in the parent directory to your build dir when building the package. Perhaps this package should Provides: aspell-dictionary? Brian Nelson might have more advice; cc-ing him. Yes, aspell dictionary packages should Provides: aspell-dictionary. The dictionary packaging otherwise looks OK with a very quick glance. -- Captain Logic is not steering this tugboat. -- 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/871v6ao843@bignachos.net
Re: RFS: go
Ivan Wong ivan...@gmail.com writes: Hi Dominique, Yes I can see the confusion. go-lang sounds good to me. But I would like to have a little poll about which one is better, go-lang or golang? Any other suggestions? '-lang' is commonly used in package names to refer to spoken languages (e.g. texlive-lang-*). I actually prefer the google-go suggestion since I think that's the least ambiguous. -- Captain Logic is not steering this tugboat. -- 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/877hp9zl1w@bignachos.net
Re: RFS: aspell-hsb
Jan Jeroným Zvánovec j...@zvano.net writes: Dear mentors, I am looking for a sponsor for my package aspell-hsb, aspell dictionary for Upper Sorbian language. * Package name: aspell-hsb Version : 0.01.1-1 Upstream Author : Eduard Werner (Edward Wornar) e.wer...@rz.uni-leipzig.de * URL : ftp://ftp.gnu.org/gnu/aspell/dict/hsb/ * License : GPL2+ Section : text It builds these binary packages: aspell-hsb - Upper Sorbian dictionary for GNU Aspell [...] I would be glad if someone uploaded this package for me. At a quick glance, the package looks fine. I should be able to sponsor this. -- Captain Logic is not steering this tugboat. -- 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/878waeqpwy@bignachos.net
Re: RFS: qt-program-starter (new package)
Christian Metscher hakai...@web.de writes: Brian Nelson p...@debian.org writes: This looks interesting for a 216-line program ;). I thought about writing something similar a few years back but never got around to it. I should be able to sponsor it if no one else has stepped up yet. I would have never thought that someone would look at qt-program-starter... It would be great if you would sponsor it for me (no one else has stepped up). I've just made a update for qt-program-starter to version 1.2.4, since the file path in the debian/qt-program-starter.1 was wrong. And I've added some key shortcuts for the checkboxes. It would make more sense to distribute the manpage in the orig.tar.gz instead of in the debian diff since it isn't specific to Debian. That wouldn't actually matter for sponsoring the upload though. There is something I'd like to ask. Do I need for each package another sponsor, or may I ask you to throw a look at qt-shutdown-p? - Just in case you want to look at it: - URL: http://mentors.debian.net/debian/pool/main/q/qt-shutdown-p - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qt-shutdown-p/qt-shutdown-p_1.7.2-1.dsc Since this is a rather similar (and also very small) tool with identical build dependencies, I think you should merge these into a unified tarball. You might also consider using a little less generic name for these tools, especially since 'qt-*' package names are normally used for tools from the Qt package itself. -- Captain Logic is not steering this tugboat. -- 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/87fx4suj53@bignachos.net
Re: RFS: qt-program-starter (new package)
Christian Metscher hakai...@web.de writes: I am looking for a sponsor for my package qt-program-starter. * Package name : qt-program-starter Version : 1.2.3-1 Upstream Author : [Christian Metscher hakai...@web.de] * URL : [https://launchpad.net/~hakaishi/+archive/qt-program-starter] * License : [GPL-3] Section : utils It builds these binary packages: qt-program-starter - Qt4 program to start a program or process [...] I would be glad if someone uploaded this package for me. Kind regards Christian Metscher This looks interesting for a 216-line program ;). I thought about writing something similar a few years back but never got around to it. I should be able to sponsor it if no one else has stepped up yet. -- Captain Logic is not steering this tugboat. -- 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/87ocjgvr6c@bignachos.net
Re: anyone give me some advice about split scim-bridge
ZhengPeng Hou [EMAIL PROTECTED] writes: hi all, I've already splited scim-brodge into scom-brodge-agent scim-brodge-client-gtk, scim-bridge-client-qt, and scim-bridge(a dumy package for upgrade), but now the upstream has added qt4 support, so shall I split it into five? likde -agent, -client-gtk -client-qt3, and -client-qt4? is this scheme ok? Is there any significant difference between the two to give a reason to justify having both? If not, I'd just pick the best supported one and just package that. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell-uz: new upstream release
Mashrab Kuvatov [EMAIL PROTECTED] writes: On Monday 16 January 2006 20:52, Mashrab Kuvatov wrote: Hi all, I updated aspell-uz to a new upstream release. It is available from http://www.uni-bremen.de/~kmashrab/aspell/deb/aspell-uz_0.5-0-1.tar.bz2 Could anyone please upload it? First time Brian Nelson helped me and uploaded it. Could someone else please do the same this time, if Brian is not available? Sorry for bugging, I have no idea on how to proceed. I'm having key troubles at the moment--my key expired, and for some reason keyring.debian.org seems to ignore my updated key. I have to have my own uploads sponsored at the moment. :( If anyone else can sponsor it, I checked the package with these files: 96a99b1b0e67157c352e8d211e5ecdb4 391 text optional aspell-uz_0.5-0-1.dsc a2a171e5126f8cdecf96eea21d73197c 90498 text optional aspell-uz_0.5-0.orig.tar.gz c30692b7258844dfb9a1256f67e95187 2432 text optional aspell-uz_0.5-0-1.diff.gz and it looked fine to me. -- Captain Logic is not steering this tugboat. pgp2oHczJZiMf.pgp Description: PGP signature
Re: Please take a look over aspell-ro_0.50-2-1
Eddy Petrişor [EMAIL PROTECTED] writes: On 10/5/05, Brian Nelson [EMAIL PROTECTED] wrote: Christoph Berg [EMAIL PROTECTED] writes: you might want to use the new Archticture: all packaging variant, see for example #319675, otherwise you need to Provides: aspell6-dictionary aspell6a-dictionary, actually (dictionary file locations moved after the sarge release). so I need either Architecture: all or Provides: aspell6a-dictionary ? You need either: Architecture: all Provides: aspell-dictionary or: Architecture: any Provides: aspell6a-dictionary The former is strongly preferred, provided you use the aspell-autobuildhash system properly. I looked over the bug specified, but there are some unclear things to me. How should I provide a gzipped version or the word list? If I gzip it before packaging then the diff.gz will be huge, right? (As the original package does not have a compressed word list.) Include them just in the .deb at build time, and not in the source package (.diff.gz). See aspell-en, for example. -- Captain Logic is not steering this tugboat.
Re: Please take a look over aspell-ro_0.50-2-1
Christoph Berg [EMAIL PROTECTED] writes: Re: Eddy Petrişor in [EMAIL PROTECTED] Could somebody take a look over it and tell me if I need to make any changes before I list it on sponsors.d.n ? changelog: remove the [ ] part get an ITP and insert it here control: old Standards-Version you might want to use the new Archticture: all packaging variant, see for example #319675, otherwise you need to Provides: aspell6-dictionary aspell6a-dictionary, actually (dictionary file locations moved after the sarge release). -- Captain Logic is not steering this tugboat.
Re: Sponsor request for aspell-uz
On Tue, Jul 26, 2005 at 12:19:27AM +0200, Mashrab Kuvatov wrote: Hi Brian, thanks for reply. I've rebuilt aspell-uz taking into account your feedback. Please have a look, it is at http://www.uni-bremen.de/~kmashrab/aspell/deb/ Almost there, just a few more things: * The urgency should be set to low, not high. * Why have you deviated from the upstream version? * Your aspell-uz.info-aspell is not correct. See http://dict-common.alioth.debian.org/dsdt-policy.html#infofile for more info. * The 1_make.dpatch is obsolete now that you aren't using make at all. * You probably shouldn't repack the .tar file so that the md5sum will match the upstream version. Usually for an upstream that distributes a .tar.bz2, you just want to do bunzip2 foo.tar.bz2; gzip -9 foo.tar and then use the resulting .tar.gz. It passed lintian -i test, but linda -i complained about l-uz.cmap file being installed into /usr/lib. Safe to ignore. It's an aspell upstream issue if anything. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor request for aspell-uz
Mashrab Kuvatov [EMAIL PROTECTED] writes: On Wednesday 27 July 2005 08:27, Brian Nelson wrote: * Your aspell-uz.info-aspell is not correct. See http://dict-common.alioth.debian.org/dsdt-policy.html#infofile for more info. I added language name in Uzbek into Language section. Is it correct now? Well, you should also specify Casechars, Not-Casechars, and Coding-System. Otherwise, AIUI, emacs won't find the correct word boundaries... It passed lintian -i test, but linda -i complained about l-uz.cmap file being installed into /usr/lib. Safe to ignore. It's an aspell upstream issue if anything. The message is W: aspell-uz; File /usr/lib/aspell/l-uz.cmap contained in /usr/lib of Architecture: all package. The file shown above is installed into /usr/lib, but the package that contains it is a architecture-independent package. This file should be installed into /usr/share instead. BTW, there are many other *.cmap and *.cset files in /usr/lib/aspell Yep, it's an aspell upstream thing. Don't worry about it... The updated files are at http://www.uni-bremen.de/~kmashrab/aspell/deb/aspell-uz_0.04-0-1-deb.tar.bz2 If you want to update the info-aspell file before I upload, let me know. Otherwise it looks ready to go. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor request for aspell-uz
Mashrab Kuvatov [EMAIL PROTECTED] writes: On Thursday 28 July 2005 00:34, Brian Nelson wrote: Mashrab Kuvatov [EMAIL PROTECTED] writes: I added language name in Uzbek into Language section. Is it correct now? Well, you should also specify Casechars, Not-Casechars, and They are optional, aren't they? Anyway, ... (see below) They are optional, but the defaults aren't correct for the language. Coding-System. It has been specified as utf-8. Is it OK? Otherwise, AIUI, emacs won't find the correct word boundaries... this dictionary is for Uzbek written in Cyrillic i.e. utf8. Does Emacs support utf8? Can I fill those fields with utf8 chars? Uhhh, I think so. You should ask the dictionaries-common maintainers to be sure though. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor request for aspell-uz
Mashrab Kuvatov [EMAIL PROTECTED] writes: Hi all, I've filed an ITP bug report #319775 for aspell-uz and uploaded the files I've built into http://www.uni-bremen.de/~kmashrab/aspell/deb/ Could anybody please sponsor it? No, this package is quite broken: debian/changelog: aspell-uz (0.60-1) testing; urgency=high [...] You *must* target unstable for uploads. Also the package is incompatible with the aspell in unstable. Also, pretty-please make the package use aspell-autobuildhash to build the dictionary hashes at install time. I desperately want to faze out dictionary packages that have the hashes packaged in the .deb, because it's an absolute nightmare to NMU 30-odd dictionaries whenever the dictionary format changes in a new aspell release. If I had any ftp-master power to reject packages (which sadly I don't), I would reject all new aspell dictionary packages that don't use aspell-autobuildhash. Attached is a document describing how to update dictionary packages for the latest aspell package. -- Society is never going to make any progress until we all learn to pretend to like each other. Needs repackaging for latest aspell Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common = 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell = 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change Provides: aspell6-dictionary to Provides: aspell6a-dictionary 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (= 0.60.3-2). [New-style autobuilt hashes] 1. Change Provides: aspell6-dictionary to Provides: aspell-dictionary (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to all 4. Add binary package dependency on aspell (= 0.60.3-3) 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. en) 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws - /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file /usr/share/aspell/$DICT_LANG/.contents. The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to /usr/sbin/update-dictcommon-aspell--the easiest way to do this is to build-depend on dictionaries-common-dev (= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list.
Re: how use dpatch for binary files ?
On Tue, Jul 12, 2005 at 07:51:18PM -0300, Jose Carlos do Nascimento wrote: Im making one package using dpatch. I changed some binary files (images) and created one patch in debian/patches When I rum dpkg-buildpackage -rfakeroot -us -uc I receive message below. 10_testpatch.dpatch is a patch for one image. Im thinking use uuencode and uudecode to solve this problem, but I would like to know if have other option to solve it. You could make use of the new format supported by dpkg-source. See: http://lists.debian.org/debian-devel-announce/2005/06/msg00010.html I'm not sure if it's OK to upload packages using the new format yet though. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Overriding shlibs dep for some packages with higher versions
On Mon, Jun 27, 2005 at 02:54:04PM +0200, Loïc Minier wrote:
[...]
In summary, what I want is something like:
debian/control: Depends: ${shlibs-depends}, libfoo (= x.y)
debian/substvars: shlibs-depends: libfoo (= x.0)
= DEBIAN/control: Depends: libfoo (= x.y)
Although I didn't find any lintian warning on double depends, I presume
they're not particularly welcome.
W: aspell-bin: package-has-a-duplicate-relation depends: libaspell15 (=
0.60),libaspell15 (= 0.60.2+20050121-3)
N:
N: The package seems to declare a relation on another package which is
N: already implied by other relations it declares, and is therefore
N: redundant.
N:
N: Note that when using ${shlibs:Depends}, this is sometimes unavoidable
N: (unless you're in a mood for ugly kludges), feel free to
N: ignore/override this warning in that case, as it can only be fixed at
N: the package-tools level (e.g., in dpkg)
Side note: this would be particularly useful if I forget to bump the =
x.y dependency (which is generated anyway).
If this can't be done easily, I'll resort to double-depends.
As the above indicates, that's pretty much the only solution for now...
PS: in case you wonder why the shlibs aren't bumped, this is because
upstream guarantees its interfaces, but might use some non-declared
functions internally, ie. functions that are not in API headers, and
expects binary packages not to mix upstream versions.
I found the exact same problem in my package above.
--
Society is never going to make any progress until we all learn to
pretend to like each other.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian QA system lecture at Haifux - help needed
On Tue, May 10, 2005 at 09:57:17AM +0300, Shachar Shemesh wrote: [...] Subjects I'm going to cover are: 1. The basics of creating a deb 2. Standard package naming and file locations 3. The Debian human hierchy (from the sponsored maintainers to ftpmasters, possibly even up to DPL, if I'll think it's relevant). 4. The automatic QA tools (pbuilder, lintian, linda) 5. The tools that help keep it all together - dch, uscan, dupload, dpkg-buildpackage I'll also not lie, I'm doing this to help me learn the turf toward becoming a DD myself. Thing is, as mentioned above, I'm doing this in order to learn this. I'd love to hear from the mentors here about any other tools that may be worth looking into. You might find this post by me a few months back helpful: http://lists.debian.org/debian-mentors/2004/12/msg00310.html -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New upstream packages?
Erinn Clark [EMAIL PROTECTED] writes: * Erinn Clark [EMAIL PROTECTED] [2004:12:18 18:23 -0500]: snip Of course, just after sending this mail, I was directed to: http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream ...which I somehow managed to miss. It's still a bit sparse, so any other tips people have for dealing with new upstream releases is very welcome. First of all, I'll assume you've skimmed over the source as part of your initial packaging. I usually go through the following steps: 1. Read the upstream changelog, NEWS, and whatever other documentation they may have released with the new version. 2. Do a 'diff -urN' between the old and new upstream sources to try to get a feel for the scope of the changes, where work is actively being done (and thus where new bugs may appear), and also keep an eye out for anything suspicious. 3. Port the old Debian packaging to the new version. This basically involves applying the diff.gz from the old package to the new one and incrementing the debian/changelog. Tools like uupdate help automate this for you. Personally I keep all of my packages in a subversion repository and thus do an svn merge. 4. If the patch/merge did not apply cleanly, inspect the situation to determine what failed (clues are left in .rej files). Most often the problem is that a patch you applied to the source was integrated upstream, and thus the patch is no longer relevant. 5. If any changes were made to the build system (hopefully you'd know from steps 1 and 2) and update the debian/rules and debian/control build dependencies if necessary. 6. Build the new package. Personally I always build in a pbuilder chroot since I use some 3rd party packages on my system and I don't want those interfering. 7. Verify that the new package builds correctly. 8. Run lintian to catch any obvious policy violations. 9. Run 'debdiff old-package.change new-package.change'. Verify that no files have been unintentionally misplaced or removed, and no other inadvertent changes were made. 10. Verify the contents with 'debc new-package.changes'. Ensure no files are zero-length that should not be. 11. Install the new package. Verify it installs/upgrades correctly. Verify that it works normally. If the package makes use of non-trivial pre/post/inst/rm scipts, be sure to test the upgrade paths of those. 12. Check to see if any bugs have been fixed that are currently open in the BTS. If they have been, close them in the debian/changelog. 13. Check the sanity of the diff.gz file. Run 'interdiff -z old-package.diff.gz new-package.diff.gz' and verify any modifications changes are intentional and no junk files have crept in. 14. Check the contents of the .changes file to make sure you are uploading to the correct distribution, the proper bugs closures are listed in the Closes: field, the Maintainer: and Changed-By: fields match, the file is GPG-signed, etc. 15. If any changes were made to correct anything in the packaging along the way, repeat steps 6-13 until satisfied. If your upload needs to be sponsored, be sure to note any special options required when building the package (like 'dpkg-buildpackage -sa -v ...') and be sure to inform your sponsor so he or she builds it correctly. Did I miss anything? -- For every sprinkle I find, I shall kill you! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: elizatalk simple chatbot for IM
On Mon, Dec 13, 2004 at 12:15:37AM -0600, David Moreno Garza wrote: On Tue, 2004-12-07 at 20:08 +0100, Nico Golde wrote: You will find the files on: http://nico.f-451.net/debian/elizatalk/ Is the template from debian/rules really yours? It seems pretty much a debhelper template and you are not giving credits for it: There's no need to give credit for the dh-make template. The templates no longer declare a copyright, and say you may use that output file without restriction. They tend to be so trivial, there's no need to worry about credits... -- For every sprinkle I find, I shall kill you! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: warning: menu-command-not-in-package
[EMAIL PROTECTED] (Peter Jay Salzman) writes: On Mon 13 Dec 04, 12:10 PM, Brian Nelson [EMAIL PROTECTED] said: On Mon, Dec 13, 2004 at 02:55:28PM -0500, Peter Jay Salzman wrote: My first package is ALMOST lintian clean. One warning: $ lintian -i yadex_1.7.0-1_i386.deb W: yadex: menu-command-not-in-package /usr/lib/menu/yadex:2 x-terminal-emulator N: N: The menu item specifies a command which is not available in the N: package. In most cases this is a typo or after you moved a binary N: around, but forgot to update the menu file. N: My debian/yadex.menu file: ?package(yadex): needs=x11 section=Games/Arcade title=yadex \ hints=Doom,3D command=x-terminal-emulator -e /usr/games/yadex Why not just do command=/usr/games/yadex? The way Yadex (a Doom WAD editor) starts is kind of wierd. You start it from a terminal, but when you want to edit a WAD file: 1. In the terminal you type e whatever to edit a level 2. Yadex uses xlib to put up its own x11 Window in which you graphically edit a WAD's level. I'm trying to think of another program that does this to give as an example, and I'm drawing a blank. In any event, you have to start the program in any kind of terminal, and then to do anything even slightly useful, it spawns its own specialized x11 window. Very different from a normal x11 program which immediately spawns its own window when you run the executable. OK, so it sounds like you're right and lintian's wrong. IMO, you should install a lintian override to suppress the warning and just carry on with your current packaging. -- For every sprinkle I find, I shall kill you! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: warning: menu-command-not-in-package
Justin Pryzby [EMAIL PROTECTED] writes:
On Mon, Dec 13, 2004 at 01:02:29PM -0800, Brian Nelson wrote:
[EMAIL PROTECTED] (Peter Jay Salzman) writes:
On Mon 13 Dec 04, 12:10 PM, Brian Nelson [EMAIL PROTECTED] said:
On Mon, Dec 13, 2004 at 02:55:28PM -0500, Peter Jay Salzman wrote:
$ lintian -i yadex_1.7.0-1_i386.deb
W: yadex: menu-command-not-in-package /usr/lib/menu/yadex:2
?package(yadex): needs=x11 section=Games/Arcade title=yadex \
hints=Doom,3D command=x-terminal-emulator -e
/usr/games/yadex
OK, so it sounds like you're right and lintian's wrong. IMO, you should
Lintian probably checks for the existence of a /usr/bin/$command where
command is everything between the double quotes.
Lintian has, in ./check/menu-format:319:
my @com=split(' ',$vals{'command'});
So, it assumes that you should provide (in this case)
/usr/bin/x-terminal-emulator. (Not, as I'd guessed, that it doesn't
That's a faulty assumption by lintian. There's no reason to require the
package contains the x-terminal-emulator executable, as long as it'll be
satisfied by the dependencies.
I think a wrapper script is appropriate if the user would otherwise
have to type x-terminal-emulator, but I dislike the idea of
echo |yadex. I don't think it'll do what the user wants. Instead,
install what is presently /usr/games/yadex to /usr/lib/yadex/... and
install a one-line wrapper script to /usr/games/yadex:
#!/bin/sh -e
exec x-terminal-emulator -e /usr/lib/yadex/...
What's wrong with just letting users type yadex in an X terminal? If
they try to run it from a text-mode console, it'll fail, but so what?
All other programs requiring a $DISPLAY fail to run in that situation
too.
--
For every sprinkle I find, I shall kill you!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: warning: menu-command-not-in-package
On Mon, Dec 13, 2004 at 02:55:28PM -0500, Peter Jay Salzman wrote:
My first package is ALMOST lintian clean. One warning:
$ lintian -i yadex_1.7.0-1_i386.deb
W: yadex: menu-command-not-in-package /usr/lib/menu/yadex:2
x-terminal-emulator
N:
N: The menu item specifies a command which is not available in the
N: package. In most cases this is a typo or after you moved a binary
N: around, but forgot to update the menu file.
N:
My debian/yadex.menu file:
?package(yadex): needs=x11 section=Games/Arcade title=yadex \
hints=Doom,3D command=x-terminal-emulator -e /usr/games/yadex
Why not just do command=/usr/games/yadex?
My package provides /usr/games/yadex, depends on xterm |
x-terminal-emulator, so everything should be fine. Those are the only two
commands in the menu file. So what exactly is lintian talking about?
Lintian isn't always right. It's probably a false positive.
On a related note, xterm provides x-terminal-emulator, so is:
Depends: ${shlibs:Depends}, xterm | x-terminal-emulator
redundant? Would it be better to pare this down to:
Depends: ${shlibs:Depends}, x-terminal-emulator
No. You should always provide a default for a virtual package, like you
did the first time.
--
For every sprinkle I find, I shall kill you!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package split/merge advice
Jan Alonzo [EMAIL PROTECTED] writes: Frank Küster [EMAIL PROTECTED] writes: Hi, (on somewhat related topic) I recently filed an RFP on itagalog and aspell-tl and one of the developers said that I should consider merging both sources since they use the same word list. snip way. I'd like to receive advices about the matter. I didn't check how big the individual upstream data files are, but yes, if they are rather small, you can consider creating a merged orig.tar.gz file from all of them. Would this be ok in my case? Get all the aspell files, put in ispell-tl, and build the binary packages for aspell and ispell from there? But that will make my orig.tar.gz lose its pristineness? What aspell files are you putting in, precisely? The dictionary packages available from aspell.net are contain wordlists that are pre-compiled to an extent. You don't want to include those; rather, you should generate those from the common wordlists (the plain, uncompiled, newline-delimited ones). If you have an upstream tarball containing the plain wordlists, you should be able to keep that pristine and add the rest of the stuff to the diff.gz. If you don't, then there's probably no reason to attempt to combine them. For example, see the ispell-da source. It builds ispell-da, wdanish, and aspell-da packages from a common wordlist. -- For every sprinkle I find, I shall kill you!
Re: [Dict-common-dev] RFS: aspell-tl - Tagalog (Filipino) dictionary for GNU Aspell
On Sat, Dec 04, 2004 at 07:41:30PM +1100, Jan Alonzo wrote: Good Day! I would like to request for someone to sponsor my package for aspell-tl. apsell-tl contains the tagalog dictionary to spell check tagalog texts. Currently it contains more than 14,000 words (and increasing. Some details: Package: aspell-tl Version: 0.02-1-1 License: GPL Package URL: http://www.unpluggable.com/debian/unstable The main purpose of this RFS is so that Debian-using Filipinos can spell-check tagalog texts using this dictionary (and of course, the grand plan of Debian for everyone ;). I can sponsor this. -- For every sprinkle I find, I shall kill you! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: RFS: orphaned 'htp' package, an HTML pre-processor
On Wed, Nov 10, 2004 at 05:18:22PM -0500, Jan Medlock wrote: martin f krafft wrote: Do we need htp when there is wml? I've not looked at wml, but even if they have the same functionality, variety has always been a strength of Debian. ...and package bloat is a weakness of Debian... -- For every sprinkle I find, I shall kill you! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: RFS: orphaned 'htp' package, an HTML pre-processor
On Wed, Nov 10, 2004 at 05:18:22PM -0500, Jan Medlock wrote: martin f krafft wrote: Do we need htp when there is wml? I've not looked at wml, but even if they have the same functionality, variety has always been a strength of Debian. ...and package bloat is a weakness of Debian... -- For every sprinkle I find, I shall kill you!
Re: Simple Debian Package Creation?
Zach Garner [EMAIL PROTECTED] writes: First: 1. The sheer number of helper scripts, with layers and layers of scripts built on top of each other is really confusing. Hm? Do you mean the debhelper scripts? Those significantly help simplify the writing of debian/rules. Of course, if you don't like them, you don't have to use them. 2. The number of files that I have to create within the /debian directory is difficult to deal with, and having to create the /debian directory within my application directory and being forced to name my application directory according to debian rules is very irritating. Only a couple files in debian/ are actually required. No one forces you to name your directory anything. 3. Most of the package creation scripts (I'm refering explicitly to dh_make which is supposed to be the proper way of creating a package, as discussed in the New Maintainer's Guide) expect that you are building a traditional unix application, that's written in C, has ./configure and a Makefile. All we are doing in most of our packages is installing some files. Why can't that be simple? It can be. dh_make is pretty crappy a lot of the time. Either undo its damage or just don't use it to begin with. Second, why can't I create packages with standard unix commands? Why can't I say something like: $ tar cvzf data.tgz myapplication/* $ tar czvf control.tgz control $ tar czvf mypackage-0.1.deb data.tgz control.tgz I don't know. Why can't you? Those no reason you shouldn't be able to built a .deb by hand. -- Blast you and your estrogenical treachery! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple Debian Package Creation?
Zach Garner [EMAIL PROTECTED] writes: First: 1. The sheer number of helper scripts, with layers and layers of scripts built on top of each other is really confusing. Hm? Do you mean the debhelper scripts? Those significantly help simplify the writing of debian/rules. Of course, if you don't like them, you don't have to use them. 2. The number of files that I have to create within the /debian directory is difficult to deal with, and having to create the /debian directory within my application directory and being forced to name my application directory according to debian rules is very irritating. Only a couple files in debian/ are actually required. No one forces you to name your directory anything. 3. Most of the package creation scripts (I'm refering explicitly to dh_make which is supposed to be the proper way of creating a package, as discussed in the New Maintainer's Guide) expect that you are building a traditional unix application, that's written in C, has ./configure and a Makefile. All we are doing in most of our packages is installing some files. Why can't that be simple? It can be. dh_make is pretty crappy a lot of the time. Either undo its damage or just don't use it to begin with. Second, why can't I create packages with standard unix commands? Why can't I say something like: $ tar cvzf data.tgz myapplication/* $ tar czvf control.tgz control $ tar czvf mypackage-0.1.deb data.tgz control.tgz I don't know. Why can't you? Those no reason you shouldn't be able to built a .deb by hand. -- Blast you and your estrogenical treachery!
Re: RFS: icculus's orbital sniper game
On Mon, Oct 25, 2004 at 01:59:03AM -0500, Joe Wreschnig wrote: On Sun, 2004-10-24 at 22:09, Brian Nelson wrote: On Sun, Oct 24, 2004 at 10:00:31PM +0100, Steve Kemp wrote: On Sun, Oct 24, 2004 at 11:59:29AM -0700, Kees Cook wrote: Okay, I've renamed this to orbitalsniper and adjusted the sources to match. One thing that stood out was that the binary isn't installed into /usr/games/, instead you chose /usr/bin. For a game that is suprising, so I'd suggest moving it. /usr/games doesn't appear in the FHS (anymore?). I think /usr/bin is the right place for it. http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS9 It's listed as optional though. Does that mean it's deprecated or anything? I'm surprised putting games in /usr/games would still be considered a good idea. It's still there. (Please don't scare me like that in the future.) Heh, sorry. A text search for usr/games on that page didn't show anything... -- Blast you and your estrogenical treachery! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: icculus's orbital sniper game
On Mon, Oct 25, 2004 at 01:59:03AM -0500, Joe Wreschnig wrote: On Sun, 2004-10-24 at 22:09, Brian Nelson wrote: On Sun, Oct 24, 2004 at 10:00:31PM +0100, Steve Kemp wrote: On Sun, Oct 24, 2004 at 11:59:29AM -0700, Kees Cook wrote: Okay, I've renamed this to orbitalsniper and adjusted the sources to match. One thing that stood out was that the binary isn't installed into /usr/games/, instead you chose /usr/bin. For a game that is suprising, so I'd suggest moving it. /usr/games doesn't appear in the FHS (anymore?). I think /usr/bin is the right place for it. http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS9 It's listed as optional though. Does that mean it's deprecated or anything? I'm surprised putting games in /usr/games would still be considered a good idea. It's still there. (Please don't scare me like that in the future.) Heh, sorry. A text search for usr/games on that page didn't show anything... -- Blast you and your estrogenical treachery!
Re: RFS: icculus's orbital sniper game
On Sun, Oct 24, 2004 at 10:00:31PM +0100, Steve Kemp wrote: On Sun, Oct 24, 2004 at 11:59:29AM -0700, Kees Cook wrote: Okay, I've renamed this to orbitalsniper and adjusted the sources to match. One thing that stood out was that the binary isn't installed into /usr/games/, instead you chose /usr/bin. For a game that is suprising, so I'd suggest moving it. /usr/games doesn't appear in the FHS (anymore?). I think /usr/bin is the right place for it. -- Blast you and your estrogenical treachery! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: icculus's orbital sniper game
On Sun, Oct 24, 2004 at 10:00:31PM +0100, Steve Kemp wrote: On Sun, Oct 24, 2004 at 11:59:29AM -0700, Kees Cook wrote: Okay, I've renamed this to orbitalsniper and adjusted the sources to match. One thing that stood out was that the binary isn't installed into /usr/games/, instead you chose /usr/bin. For a game that is suprising, so I'd suggest moving it. /usr/games doesn't appear in the FHS (anymore?). I think /usr/bin is the right place for it. -- Blast you and your estrogenical treachery!
Re: Suggestions On Getting A Sponsor
On Mon, Sep 27, 2004 at 10:49:52PM -0400, Michael MacFadden wrote: Brian, Point taken. But I happen to be the upstream author for this project. So it's not like I just picked this out of a hat, and it's not like I am in the position to say, Well maybe I should just pick something easier to package. The only reason I am looking into packaging this is because several people have emailed me and asked about the availability of Debian packages. Since Debian happens to be my platform of choice I figured I would try to learn the ropes of package maintenance. Granted, I am a complete newbie and don't understand the technical or philosophical issues behind some of these issues. But if I am passionate and committed to getting this packaged and into Debian, then there must be some avenue. I suppose the trick is finding a developer who is both experienced with Web App packaging and also interested in my package. If I were you, I'd just put the packages you create on the upstream site and add a note saying you're looking for a sponsor for the packages. That way, users will be able to download the packages, and if an interested developer finds them, the packages should find an easy path into Debian. I don't think it's worth trying to force the package into Debian if you can't easily find a sponsor. There's a general feeling with developers that Debian is already far too big and there are too many packages that are of very little interest. The testing release managers, of whom Steve is one, probably especially feel this way since the bigger Debian is, the more they have to get it released. -- Blast you and your estrogenical treachery!
Re: Suggestions On Getting A Sponsor
On Mon, Sep 27, 2004 at 10:49:52PM -0400, Michael MacFadden wrote: Brian, Point taken. But I happen to be the upstream author for this project. So it's not like I just picked this out of a hat, and it's not like I am in the position to say, Well maybe I should just pick something easier to package. The only reason I am looking into packaging this is because several people have emailed me and asked about the availability of Debian packages. Since Debian happens to be my platform of choice I figured I would try to learn the ropes of package maintenance. Granted, I am a complete newbie and don't understand the technical or philosophical issues behind some of these issues. But if I am passionate and committed to getting this packaged and into Debian, then there must be some avenue. I suppose the trick is finding a developer who is both experienced with Web App packaging and also interested in my package. If I were you, I'd just put the packages you create on the upstream site and add a note saying you're looking for a sponsor for the packages. That way, users will be able to download the packages, and if an interested developer finds them, the packages should find an easy path into Debian. I don't think it's worth trying to force the package into Debian if you can't easily find a sponsor. There's a general feeling with developers that Debian is already far too big and there are too many packages that are of very little interest. The testing release managers, of whom Steve is one, probably especially feel this way since the bigger Debian is, the more they have to get it released. -- Blast you and your estrogenical treachery! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Suggestions On Getting A Sponsor
I think you're missing the point. It's not that developers think this should not be packaged. It's that packaging a web app is so difficult to get right that only developers with a very strong personal interest in the software would be willing to even look at it. The vast majority will consider it to not be worth the effort. The best way to find a sponsor is to package something that is both interesting and easy to sponsor. I know I only sponsor packages I have both a personal interest in and take little time to review. -- Blast you and your estrogenical treachery! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Suggestions On Getting A Sponsor
I think you're missing the point. It's not that developers think this should not be packaged. It's that packaging a web app is so difficult to get right that only developers with a very strong personal interest in the software would be willing to even look at it. The vast majority will consider it to not be worth the effort. The best way to find a sponsor is to package something that is both interesting and easy to sponsor. I know I only sponsor packages I have both a personal interest in and take little time to review. -- Blast you and your estrogenical treachery!
Re: amarok package review and RFS (II)
On Fri, Sep 24, 2004 at 04:03:09AM +0200, Adeodato Sim? wrote: I'm looking for a sponsor for my amarok package, which as you may know is a new audio player for KDE. the package is relatively simple and contains few if not none KDE specific issues. I'm interested in seeing this packaged. I'll took a look at it soon and sponsor it if you haven't found another sponsor yet. -- Blast you and your estrogenical treachery! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amarok package review and RFS (II)
On Fri, Sep 24, 2004 at 04:03:09AM +0200, Adeodato Sim? wrote: I'm looking for a sponsor for my amarok package, which as you may know is a new audio player for KDE. the package is relatively simple and contains few if not none KDE specific issues. I'm interested in seeing this packaged. I'll took a look at it soon and sponsor it if you haven't found another sponsor yet. -- Blast you and your estrogenical treachery!
Re: How to get rid of an epoch?
On Fri, Aug 27, 2004 at 10:38:15PM +0200, Amaya wrote: I'm doing a little houskeeping before sarge releases. Then I stumble upon this: Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in stable = new version (1.6-2) targeted at unstable. Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in unstable = new version (1.6-2) targeted at unstable. Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in testing = new version (1.6-2) targeted at unstable. For some reason (the changelog doesn't help much), the previous maintainer used an epoch at some point and I would like to get rid of it. What's the best way to do it? You can't unless you rename the package. That's why the use of epoch's is strongly discouraged unless absolutely necessary. -- Blast you and your estrogenical treachery!
Re: Package Name Choice
On Sat, Aug 07, 2004 at 01:59:33AM +0200, Nico Golde wrote: Hello Christoffer, * Christoffer Sawicki [EMAIL PROTECTED] [2004-08-07 01:38]: I'm packaging GTK-Qt Theme Engine [0] and have a question about the naming of the binary package. The name is currently gtk2-engines-gtk-qt which is sort of right since the package contains a GTK2 theme engine. However, it's not a standard theme engine since it depends on Qt for its drawing and is configured through KControl. Do you think the package name should be gtk-qt-engine or gtk2-engines-gtk-qt? Please CC me, I'm not on the list. [0] http://www.freedesktop.org/Software/gtk-qt just take the name the upstream does. I would *never* blindly trust upstream to choose a name that is sane for Debian. The upstream name (gtk-qt) is particularly poor in this case. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package Name Choice
On Sat, Aug 07, 2004 at 01:59:33AM +0200, Nico Golde wrote: Hello Christoffer, * Christoffer Sawicki [EMAIL PROTECTED] [2004-08-07 01:38]: I'm packaging GTK-Qt Theme Engine [0] and have a question about the naming of the binary package. The name is currently gtk2-engines-gtk-qt which is sort of right since the package contains a GTK2 theme engine. However, it's not a standard theme engine since it depends on Qt for its drawing and is configured through KControl. Do you think the package name should be gtk-qt-engine or gtk2-engines-gtk-qt? Please CC me, I'm not on the list. [0] http://www.freedesktop.org/Software/gtk-qt just take the name the upstream does. I would *never* blindly trust upstream to choose a name that is sane for Debian. The upstream name (gtk-qt) is particularly poor in this case. -- You win again, gravity!
Re: How to retire a bug tagged wontfix,woody?
Kevin Glynn [EMAIL PROTECTED] writes: Andreas Metzler writes: On Mon, Aug 02, 2004 at 03:03:31PM +0200, Kevin Glynn wrote: I am the (new) maintainer for mozart. I have one Serious bug outstanding: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mozart). The bug was tagged wontfix, woody. The bug has been fixed in versions later than woody. What should I do? Will this just hang around forever? [...] Basically that is up to you as maintainer. Having open bugs in the BTS tagged woody that you are not going to fix only serves one purpose: documentation. If you do not think this is necessary close it. Personally, for this specific bug I'd keep it open just a little bit longer until sarge is released. Thanks for the responses. I understand now, I was just worried about having open 'Serious' bugs so close to a freeze Then downgrade it. There's a mismatch there anyway. A serious bug should *never* be tagged as wontfix. Either it needs to be fixed or it's not really serious. -- You win again, gravity!
Re: How to retire a bug tagged wontfix,woody?
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Mon, Aug 02, 2004 at 11:42:49PM -0700, Brian Nelson wrote: Then downgrade it. There's a mismatch there anyway. A serious bug should *never* be tagged as wontfix. Either it needs to be fixed or it's not really serious. This is not true. For example, architecture-dependent data in /usr/share is a serious bug, but if a version in woody has this bug, it is still wontfix: such a bug doesn't render the package nearly unusable, doesn't cause dataloss, isn't a security issue, hence, isn't important enough to risk breaking stuff in woody for.. A serious bug usually implies a policy violation and not necessarily a usability issue. If the policy violation is exaggerated (like your above example, or the OP's bug), I'd just downgrade it. Leaving serious bugs open and tagged wontfix just makes no sense to me. -- You win again, gravity!
Re: How to retire a bug tagged wontfix,woody?
Kevin Glynn [EMAIL PROTECTED] writes: Andreas Metzler writes: On Mon, Aug 02, 2004 at 03:03:31PM +0200, Kevin Glynn wrote: I am the (new) maintainer for mozart. I have one Serious bug outstanding: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mozart). The bug was tagged wontfix, woody. The bug has been fixed in versions later than woody. What should I do? Will this just hang around forever? [...] Basically that is up to you as maintainer. Having open bugs in the BTS tagged woody that you are not going to fix only serves one purpose: documentation. If you do not think this is necessary close it. Personally, for this specific bug I'd keep it open just a little bit longer until sarge is released. Thanks for the responses. I understand now, I was just worried about having open 'Serious' bugs so close to a freeze Then downgrade it. There's a mismatch there anyway. A serious bug should *never* be tagged as wontfix. Either it needs to be fixed or it's not really serious. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to retire a bug tagged wontfix,woody?
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Mon, Aug 02, 2004 at 11:42:49PM -0700, Brian Nelson wrote: Then downgrade it. There's a mismatch there anyway. A serious bug should *never* be tagged as wontfix. Either it needs to be fixed or it's not really serious. This is not true. For example, architecture-dependent data in /usr/share is a serious bug, but if a version in woody has this bug, it is still wontfix: such a bug doesn't render the package nearly unusable, doesn't cause dataloss, isn't a security issue, hence, isn't important enough to risk breaking stuff in woody for.. A serious bug usually implies a policy violation and not necessarily a usability issue. If the policy violation is exaggerated (like your above example, or the OP's bug), I'd just downgrade it. Leaving serious bugs open and tagged wontfix just makes no sense to me. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDBS Documentation
debian-devel would probably be a more appropriate place to ask this. Nico Golde [EMAIL PROTECTED] writes: Hi, i subscibed to the cdbs mailinglist with the intention to support the project a little bit. I wrote a little german documentation for cdbs: http://www.ngolde.de/texte/cdbs.html, but i get no resonse on the list. How about the project activity in the last time? Is it dead? Sure seems that way... -- You win again, gravity!
Re: CDBS Documentation
debian-devel would probably be a more appropriate place to ask this. Nico Golde [EMAIL PROTECTED] writes: Hi, i subscibed to the cdbs mailinglist with the intention to support the project a little bit. I wrote a little german documentation for cdbs: http://www.ngolde.de/texte/cdbs.html, but i get no resonse on the list. How about the project activity in the last time? Is it dead? Sure seems that way... -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Silly question about man page
Nathaniel W. Turner [EMAIL PROTECTED] writes: On Friday 23 July 2004 09:11 am, Bartosz Fenski aka fEnIo wrote: On Fri, Jul 23, 2004 at 08:34:12AM -0400, Nathaniel W. Turner wrote: But why on earth would anyone use dh_make when we have cdbs? ;-) I can say only for myself, but cdbs is completely useless for me as far as it is shipped without documentation. Documentation was missing from the package for a while, but it's back now; see /usr/share/doc/cdbs/cdbs.html and /usr/share/doc/cdbs/why.html for starters. You're welcome. It sure would be nice if cdbs development wasn't, err, completely dead... -- You win again, gravity!
Re: Silly question about man page
Nathaniel W. Turner [EMAIL PROTECTED] writes: On Friday 23 July 2004 09:11 am, Bartosz Fenski aka fEnIo wrote: On Fri, Jul 23, 2004 at 08:34:12AM -0400, Nathaniel W. Turner wrote: But why on earth would anyone use dh_make when we have cdbs? ;-) I can say only for myself, but cdbs is completely useless for me as far as it is shipped without documentation. Documentation was missing from the package for a while, but it's back now; see /usr/share/doc/cdbs/cdbs.html and /usr/share/doc/cdbs/why.html for starters. You're welcome. It sure would be nice if cdbs development wasn't, err, completely dead... -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: netdump -- Dump kernel crash information over the network
[EMAIL PROTECTED] (Joe Nahmias) writes: Hello Chirag, On Wed, Jul 14, 2004 at 05:23:14PM +0530, Chirag Kantharia wrote: Hi! I've uploaded netdump package to mentors.debian.net and am seeking for a sponsor for this package. I took a look at your package, a few issues: 0) For some reason you decided to build this as a debian-specific package. You should change this to use the regular method -- with a .dsc, .diff.gz, and a .orig.tar.gz. 1) You don't close the ITP bug in your changelog. 2) Policy is up to version 3.6.1.1 now, please update your package as necessary. There's no need to update the policy version from 3.6.1 to 3.6.1.1. Including the 4th component is completely pointless. See policy 5.6.10. -- You win again, gravity!
Re: RFS: netdump -- Dump kernel crash information over the network
[EMAIL PROTECTED] (Joe Nahmias) writes: Hello Chirag, On Wed, Jul 14, 2004 at 05:23:14PM +0530, Chirag Kantharia wrote: Hi! I've uploaded netdump package to mentors.debian.net and am seeking for a sponsor for this package. I took a look at your package, a few issues: 0) For some reason you decided to build this as a debian-specific package. You should change this to use the regular method -- with a .dsc, .diff.gz, and a .orig.tar.gz. 1) You don't close the ITP bug in your changelog. 2) Policy is up to version 3.6.1.1 now, please update your package as necessary. There's no need to update the policy version from 3.6.1 to 3.6.1.1. Including the 4th component is completely pointless. See policy 5.6.10. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf question
Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] writes: And while I'm at it: the behaviour change is not really dangerous, but can cause people to get more spam. (Background: postgrey changed from --lookup-by-host to --lookup-by-subnet in Version 1.14) So, is a debconf notice even necessary, or would NEWS.Debian suffice? I think NEWS.Debian would be the proper place. Debconf notes should only be used to report total breakage, not minor issues, AIUI. -- You win again, gravity!
Re: debconf question
Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] writes: And while I'm at it: the behaviour change is not really dangerous, but can cause people to get more spam. (Background: postgrey changed from --lookup-by-host to --lookup-by-subnet in Version 1.14) So, is a debconf notice even necessary, or would NEWS.Debian suffice? I think NEWS.Debian would be the proper place. Debconf notes should only be used to report total breakage, not minor issues, AIUI. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: amarok - versatile and easy to use audio player for KDE
Peter Rockai (mornfall) [EMAIL PROTECTED] writes: Anibal Monsalve Salazar wrote: W: amarok source: out-of-date-standards-version 3.5.8.0 W: amarok source: changelog-should-mention-nmu W: amarok source: source-nmu-has-incorrect-version-number 1.0.0-3 W: amarok source: source-contains-CVS-dir debian/CVS E: amarok-xmms: binary-without-manpage amarok_xmmswrapper E: amarok-xmms: usr-doc-symlink-without-dependency amarok E: amarok-gstreamer: usr-doc-symlink-without-dependency amarok E: amarok-arts: no-shlibs-control-file usr/lib/libamarokarts.so E: amarok-arts: usr-doc-symlink-without-dependency amarok First, amarok-* do depend on amarok... no idea what to do about that; override? I will fix maintainer and changelog, i wanted to make another build anyway. Manpage will be included as well (not for amarokapp or amarok_xmmswrapper tho). libamarokarts.so is not a shared library but a loadable module, i know this is a problem but it's upstream. It can't go in /usr/lib then. It would have to go in /usr/lib/amarok/ or something instead. It's not critical. Well, changing it is probably quite some work, error-prone and means diverging from upstream. I will bug them about it tho. No, that doesn't sound like it would be the right thing to do... -- You win again, gravity!
Re: sponsor wanted for 'ketchup' package
Laszlo 'GCS' Boszormenyi [EMAIL PROTECTED] writes: * Anibal Monsalve Salazar [EMAIL PROTECTED] [2004-06-28 22:21:14 +1000]: I don't think you should create a debian package for small script, IMO. Agree. Even if I don't know where it should go, but definiately finding a backage which would include ketchup sounds a better idea. Maybe kernel-package? -- You win again, gravity!
Re: RFS: amarok - versatile and easy to use audio player for KDE
Peter Rockai (mornfall) [EMAIL PROTECTED] writes: Anibal Monsalve Salazar wrote: W: amarok source: out-of-date-standards-version 3.5.8.0 W: amarok source: changelog-should-mention-nmu W: amarok source: source-nmu-has-incorrect-version-number 1.0.0-3 W: amarok source: source-contains-CVS-dir debian/CVS E: amarok-xmms: binary-without-manpage amarok_xmmswrapper E: amarok-xmms: usr-doc-symlink-without-dependency amarok E: amarok-gstreamer: usr-doc-symlink-without-dependency amarok E: amarok-arts: no-shlibs-control-file usr/lib/libamarokarts.so E: amarok-arts: usr-doc-symlink-without-dependency amarok First, amarok-* do depend on amarok... no idea what to do about that; override? I will fix maintainer and changelog, i wanted to make another build anyway. Manpage will be included as well (not for amarokapp or amarok_xmmswrapper tho). libamarokarts.so is not a shared library but a loadable module, i know this is a problem but it's upstream. It can't go in /usr/lib then. It would have to go in /usr/lib/amarok/ or something instead. It's not critical. Well, changing it is probably quite some work, error-prone and means diverging from upstream. I will bug them about it tho. No, that doesn't sound like it would be the right thing to do... -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sponsor wanted for 'ketchup' package
Laszlo 'GCS' Boszormenyi [EMAIL PROTECTED] writes: * Anibal Monsalve Salazar [EMAIL PROTECTED] [2004-06-28 22:21:14 +1000]: I don't think you should create a debian package for small script, IMO. Agree. Even if I don't know where it should go, but definiately finding a backage which would include ketchup sounds a better idea. Maybe kernel-package? -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: PennMUSH - #3
Ervin Hearn III [EMAIL PROTECTED] writes: Hello, It's been a month since I've last poked at this thread, but I would once more like to ask if anyone would take a look at my PennMUSH package and possibly consider sponsoring it. I have kept it up to date with upstream releases, and thanks to Joel Baker's input in previous months, I believe the package is fairly clean. [...] http://debian.korongil.net/ Even if you don't have the interest in sponsoring the package, I'd appreciate any feedback that can be given about the package. The .diff.gz is far too large to be sponsored (by most developers' standards, anyway). It looks like it contains a lot of auto-generated junk that should be deleted in the clean target. -- You win again, gravity!
Re: RFS: PennMUSH - #3
Ervin Hearn III [EMAIL PROTECTED] writes: Hello, It's been a month since I've last poked at this thread, but I would once more like to ask if anyone would take a look at my PennMUSH package and possibly consider sponsoring it. I have kept it up to date with upstream releases, and thanks to Joel Baker's input in previous months, I believe the package is fairly clean. [...] http://debian.korongil.net/ Even if you don't have the interest in sponsoring the package, I'd appreciate any feedback that can be given about the package. The .diff.gz is far too large to be sponsored (by most developers' standards, anyway). It looks like it contains a lot of auto-generated junk that should be deleted in the clean target. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: patmv -- a bulk renaming tool
Jay Berkenbilt [EMAIL PROTECTED] writes: On Mon, Apr 26, 2004 at 08:13:32PM +0200, Thomas Viehmann wrote: So: I suggest you submit it for addition to renameutils. As a side effect, renameutils and your package get a comaintainer. Hmmm. Maybe you should see if the renameutils maintainer is willing/interested in including it first; if not I will look at it. I agree that it makes sense for it to be separate from perl; but perhaps not separate from renameutils. I have to assert, respectfully, that I don't think patmv belongs with renameutils or any other existing package. I guess I'm confused as to why the suggestion of including it in another package has come up at all. patmv is its own package with a life outside of these other packages. That should, in my opinion, be sufficient reason to have it be a separate package. I think most upstream authors would be reluctant to have their software added to Debian by being combined with some other package that they don't have anything to do with. If you disagree, please let me know; I'm definitely open to hearing compelling arguments to the contrary. Tiny packages are generally frowned upon in Debian since they unnecessarily bloat the Packages file. So, small scripts like yours tend to be collected into a single package with other related scripts. If everyone packaged their pet scripts into separate packages, the already very large number of packages in Debian would grow enormously. -- You win again, gravity!
Re: RFS: patmv -- a bulk renaming tool
Jay Berkenbilt [EMAIL PROTECTED] writes: On Mon, Apr 26, 2004 at 08:13:32PM +0200, Thomas Viehmann wrote: So: I suggest you submit it for addition to renameutils. As a side effect, renameutils and your package get a comaintainer. Hmmm. Maybe you should see if the renameutils maintainer is willing/interested in including it first; if not I will look at it. I agree that it makes sense for it to be separate from perl; but perhaps not separate from renameutils. I have to assert, respectfully, that I don't think patmv belongs with renameutils or any other existing package. I guess I'm confused as to why the suggestion of including it in another package has come up at all. patmv is its own package with a life outside of these other packages. That should, in my opinion, be sufficient reason to have it be a separate package. I think most upstream authors would be reluctant to have their software added to Debian by being combined with some other package that they don't have anything to do with. If you disagree, please let me know; I'm definitely open to hearing compelling arguments to the contrary. Tiny packages are generally frowned upon in Debian since they unnecessarily bloat the Packages file. So, small scripts like yours tend to be collected into a single package with other related scripts. If everyone packaged their pet scripts into separate packages, the already very large number of packages in Debian would grow enormously. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Closing bugs.
Bartosz Fenski aka fEnIo [EMAIL PROTECTED] writes: Hello. I've got question related to closing bugs. Let's say I adopted some package, and with the new upstream version I should close some outstanding bugs. And I did it in 1.1-1 version. Then I ask previous maintainer to upload it, and he pointed me out some other needed changes. So I made another release 1.1-2 with those fixes. Then previous maintainer uploaded it, but he built package without `-v1.0` switch so only latest changelog was included. This led to non-closed bugs which are fixed in fact. What now? Should I close those bugs manually, or is it correct way to upload another version (1.1-3) including changelogs from 1.1-1 to 1.1-3? I mean is it good way? Then changelog from version 1.1-2 will be parsed two times. Either method is fine. If you're planning to make another upload soon anyway, I'd just wait and build with the -v switch. Otherwise, just close them by hand, preferably inserting the text of the relevant changelog entry in the closing message. -- You win again, gravity!
Re: Closing bugs.
Kalle Kivimaa [EMAIL PROTECTED] writes: Bartosz Fenski aka fEnIo [EMAIL PROTECTED] writes: This led to non-closed bugs which are fixed in fact. What now? Should I close those bugs manually, or is it correct way to upload another version (1.1-3) including changelogs from 1.1-1 to 1.1-3? Just use the control interface to BTS to close them. Include the relevant parts of the changelog. No, you should never use [EMAIL PROTECTED] to close bugs. -- You win again, gravity!
Re: Closing bugs.
Bartosz Fenski aka fEnIo [EMAIL PROTECTED] writes: Hello. I've got question related to closing bugs. Let's say I adopted some package, and with the new upstream version I should close some outstanding bugs. And I did it in 1.1-1 version. Then I ask previous maintainer to upload it, and he pointed me out some other needed changes. So I made another release 1.1-2 with those fixes. Then previous maintainer uploaded it, but he built package without `-v1.0` switch so only latest changelog was included. This led to non-closed bugs which are fixed in fact. What now? Should I close those bugs manually, or is it correct way to upload another version (1.1-3) including changelogs from 1.1-1 to 1.1-3? I mean is it good way? Then changelog from version 1.1-2 will be parsed two times. Either method is fine. If you're planning to make another upload soon anyway, I'd just wait and build with the -v switch. Otherwise, just close them by hand, preferably inserting the text of the relevant changelog entry in the closing message. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Closing bugs.
Kalle Kivimaa [EMAIL PROTECTED] writes: Bartosz Fenski aka fEnIo [EMAIL PROTECTED] writes: This led to non-closed bugs which are fixed in fact. What now? Should I close those bugs manually, or is it correct way to upload another version (1.1-3) including changelogs from 1.1-1 to 1.1-3? Just use the control interface to BTS to close them. Include the relevant parts of the changelog. No, you should never use [EMAIL PROTECTED] to close bugs. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: stripclub - Online Comic Reader/Archiver
A few more minor problems:
* In interface.fl:163:
callback {system(xterm -e zless /usr/share/doc/stripclub/readme.txt.gz);}
You can't rely on xterm being available unless you depend upon it, and
even still, that's bad practice. Instead, you should use
/usr/bin/x-terminal-emulator.
* Code like stripclub:288:
snprintf(cmd, 1023, rm -rf %s, GetCacheFileName(, false));
system(cmd);
is potentially dangerous, since what if %s is some file /, without
the quotes? Yeah, from the code path, it looks like that wouldn't
happen under normal conditions, but still I'd avoid code like that
altogether.
* The CFLAGS and INSTALL_PROGRAM stuff in debian/rules is unused. You
should pass CFLAGS to the 'make' command, and just remove the
INSTALL_PROGRAM stuff since dh_strip does the right thing anyway.
Bah, I hate dh_make ...
* Finally, your debian/rules lacks the binary-indep target, which is a
policy violation. Quoting section 4.8:
Both the binary-arch and binary-indep targets must exist. If one of
them has nothing to do (which will always be the case if the source
generates only a single binary package, whether
architecture-dependent or not), it must still exist and must always
succeed.
So just add it and have it do nothing.
--
You win again, gravity!
Re: CDBS and menu icons
Matt Brubeck [EMAIL PROTECTED] writes: I am adding a menu icon to my audacity package, built with CDBS. Can anyone suggest the best way to install the icons (which are not part of the original source)? Currently I am using the following lines in debian/rules: ICONS = debian/audacity.xpm debian/audacity16.xpm binary-install/audacity:: $(ICONS) install -d debian/audacity/usr/share/audacity install -m 644 $(ICONS) debian/audacity/usr/share/audacity Does that not work? Personally, I'd use dh_install, but it doesn't really matter as long as it works... -- You win again, gravity!
Re: CDBS and menu icons
Matt Brubeck [EMAIL PROTECTED] writes: I am adding a menu icon to my audacity package, built with CDBS. Can anyone suggest the best way to install the icons (which are not part of the original source)? Currently I am using the following lines in debian/rules: ICONS = debian/audacity.xpm debian/audacity16.xpm binary-install/audacity:: $(ICONS) install -d debian/audacity/usr/share/audacity install -m 644 $(ICONS) debian/audacity/usr/share/audacity Does that not work? Personally, I'd use dh_install, but it doesn't really matter as long as it works... -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: stripclub - Online Comic Reader/Archiver
A few more minor problems:
* In interface.fl:163:
callback {system(xterm -e zless /usr/share/doc/stripclub/readme.txt.gz);}
You can't rely on xterm being available unless you depend upon it, and
even still, that's bad practice. Instead, you should use
/usr/bin/x-terminal-emulator.
* Code like stripclub:288:
snprintf(cmd, 1023, rm -rf %s, GetCacheFileName(, false));
system(cmd);
is potentially dangerous, since what if %s is some file /, without
the quotes? Yeah, from the code path, it looks like that wouldn't
happen under normal conditions, but still I'd avoid code like that
altogether.
* The CFLAGS and INSTALL_PROGRAM stuff in debian/rules is unused. You
should pass CFLAGS to the 'make' command, and just remove the
INSTALL_PROGRAM stuff since dh_strip does the right thing anyway.
Bah, I hate dh_make ...
* Finally, your debian/rules lacks the binary-indep target, which is a
policy violation. Quoting section 4.8:
Both the binary-arch and binary-indep targets must exist. If one of
them has nothing to do (which will always be the case if the source
generates only a single binary package, whether
architecture-dependent or not), it must still exist and must always
succeed.
So just add it and have it do nothing.
--
You win again, gravity!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: stripclub - Online Comic Reader/Archiver
Benjamin Cutler [EMAIL PROTECTED] writes: After dinking around with the build tools for a bit, I'm reasonably sure this is put together correctly, so here goes. I'm looking for a sponsor for my package stripclub, an online comic reader and archiver. It supports the vast majority of webcomics so far tested, though a few kinks still exist, mostly dealing with server oddities. The package was built with pbuilder (sid), and is lintian clean. I see a few problems: * You should change the RFP for stripclub to an ITP (just change the bug title), and then close the bug in the changelog. * Your debian/copyright is lacking a bit. See http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200312/msg7.html for more info. * Standards-Version is out of date * The short description is a little long for my tastes. It seems it could be phrased more concisely. Also, the long description is rather poorly written. It contains incomplete sentences, and the use of acronyms like FLTK should be avoided. See section 6.2 of the developers reference. * The debian/rules file contains a lot of commented out commands left over from the dh_make template. It's best to clean it up and remove commands that will never be used. * The debian/stripclub.doc-base.EX file should be removed. It's just a dh_make example file. * The upstream optimization flags look retarded. -O3 -fomit-frame-pointer -funroll-loops? What is that about? This isn't gentoo... * The md5sums don't match the upstream tarball. It looks like upstream distributes the file as a bz2, so the .orig.tar.gz can't match, but the .tar file inside should still be identical. -- You win again, gravity!
Re: RFS: stripclub - Online Comic Reader/Archiver
Benjamin Cutler [EMAIL PROTECTED] writes: Brian Nelson wrote: Benjamin Cutler [EMAIL PROTECTED] writes: After dinking around with the build tools for a bit, I'm reasonably sure this is put together correctly, so here goes. I'm looking for a sponsor for my package stripclub, an online comic reader and archiver. It supports the vast majority of webcomics so far tested, though a few kinks still exist, mostly dealing with server oddities. The package was built with pbuilder (sid), and is lintian clean. * Your debian/copyright is lacking a bit. See http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200312/msg7.html for more info. So I should change the company name to my name? Or do you mean I should be more clear on the GPL? Oops, I didn't realize you're also the upstream author. That makes the copyright more OK than I realized. Still, you should include more on the GPL (versioning, etc.), like in the example in that email. * Standards-Version is out of date Is this something that just entails changing the number (which I just did, if that's all...), or does my package somehow violate a new standard? Normally you create a package using the current policy version as a guideline, and then keep it up to date by following /usr/share/doc/debian-policy/upgrading-checklist.txt.gz . Often, it's OK to just increase the number, but always check the checklist first. * The upstream optimization flags look retarded. -O3 -fomit-frame-pointer -funroll-loops? What is that about? This isn't gentoo... Is this an actual problem, or a matter of taste? If it's the latter, I don't really see a need to change it... They're overly aggressive. -fomit-frame-pointer makes debugging virtually impossible AIUI, and -funroll-loops makes the code larger (and likely slower due to more CPU cache misses). Also, Debian Policy states you should include -g to include debugging information. Specifically, it says: For the C programming language, this means the following compilation parameters should be used: CC = gcc CFLAGS = -O2 -g -Wall though -O3 is probably OK in most cases. You should keep the optimizations options as conservative as possible, unless you really know what you're doing. If your programs runs too slowly, you'll likely be able to get a far greater performance increase with no downsides from optimizing the code (after narrowing down the problem areas with a profiler) rather than relying on the often buggy advanced GCC optimizations. * The md5sums don't match the upstream tarball. It looks like upstream distributes the file as a bz2, so the .orig.tar.gz can't match, but the .tar file inside should still be identical. Hmm, that seems a little odd. I'll fiddle with my internal packaging script and have it make both bz2 and gz, uupdate was spitting a warning at me about unable to preserve pristine sources from non-gz, guess it wasn't something I can just ignore. Well, if you're also the upstream packager, keeping the upstream tarball pristine is less meaningful, so it's probably not much to worry about. -- You win again, gravity!
Re: RFS: stripclub - Online Comic Reader/Archiver
Jepri [EMAIL PROTECTED] writes: Benjamin Cutler wrote: Nicolas Kratz wrote: Point made. While I, personally, don't feel any regret (I've been a Premium Keenspot member for two years, have every Sluggy book). I'll be sticking a splash screen into the next build saying just that. Perhaps I should move the Per-comic donation links todo item up in my list. A store link sounds like a good idea too. One reason I've not done this already is my lack of knowledge of any standard way to have a Linux system spawn a webbrowser with the URL. Coding for specific browsers is an option, but is there an easier way? In Debian, /etc/alternatives/x-www-browser is a link to an installed browser. That might not be the users first choice of browser, but that's another fight for another time. That's why you should use /usr/bin/sensible-browser instead, since that will use the $BROWSER variable if set. -- You win again, gravity!
Re: RFS: stripclub - Online Comic Reader/Archiver
Benjamin Cutler [EMAIL PROTECTED] writes: Brian Nelson wrote: Benjamin Cutler [EMAIL PROTECTED] writes: After dinking around with the build tools for a bit, I'm reasonably sure this is put together correctly, so here goes. I'm looking for a sponsor for my package stripclub, an online comic reader and archiver. It supports the vast majority of webcomics so far tested, though a few kinks still exist, mostly dealing with server oddities. The package was built with pbuilder (sid), and is lintian clean. * Your debian/copyright is lacking a bit. See http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200312/msg7.html for more info. So I should change the company name to my name? Or do you mean I should be more clear on the GPL? Oops, I didn't realize you're also the upstream author. That makes the copyright more OK than I realized. Still, you should include more on the GPL (versioning, etc.), like in the example in that email. * Standards-Version is out of date Is this something that just entails changing the number (which I just did, if that's all...), or does my package somehow violate a new standard? Normally you create a package using the current policy version as a guideline, and then keep it up to date by following /usr/share/doc/debian-policy/upgrading-checklist.txt.gz . Often, it's OK to just increase the number, but always check the checklist first. * The upstream optimization flags look retarded. -O3 -fomit-frame-pointer -funroll-loops? What is that about? This isn't gentoo... Is this an actual problem, or a matter of taste? If it's the latter, I don't really see a need to change it... They're overly aggressive. -fomit-frame-pointer makes debugging virtually impossible AIUI, and -funroll-loops makes the code larger (and likely slower due to more CPU cache misses). Also, Debian Policy states you should include -g to include debugging information. Specifically, it says: For the C programming language, this means the following compilation parameters should be used: CC = gcc CFLAGS = -O2 -g -Wall though -O3 is probably OK in most cases. You should keep the optimizations options as conservative as possible, unless you really know what you're doing. If your programs runs too slowly, you'll likely be able to get a far greater performance increase with no downsides from optimizing the code (after narrowing down the problem areas with a profiler) rather than relying on the often buggy advanced GCC optimizations. * The md5sums don't match the upstream tarball. It looks like upstream distributes the file as a bz2, so the .orig.tar.gz can't match, but the .tar file inside should still be identical. Hmm, that seems a little odd. I'll fiddle with my internal packaging script and have it make both bz2 and gz, uupdate was spitting a warning at me about unable to preserve pristine sources from non-gz, guess it wasn't something I can just ignore. Well, if you're also the upstream packager, keeping the upstream tarball pristine is less meaningful, so it's probably not much to worry about. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: stripclub - Online Comic Reader/Archiver
Jepri [EMAIL PROTECTED] writes: Benjamin Cutler wrote: Nicolas Kratz wrote: Point made. While I, personally, don't feel any regret (I've been a Premium Keenspot member for two years, have every Sluggy book). I'll be sticking a splash screen into the next build saying just that. Perhaps I should move the Per-comic donation links todo item up in my list. A store link sounds like a good idea too. One reason I've not done this already is my lack of knowledge of any standard way to have a Linux system spawn a webbrowser with the URL. Coding for specific browsers is an option, but is there an easier way? In Debian, /etc/alternatives/x-www-browser is a link to an installed browser. That might not be the users first choice of browser, but that's another fight for another time. That's why you should use /usr/bin/sensible-browser instead, since that will use the $BROWSER variable if set. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: stripclub - Online Comic Reader/Archiver
Benjamin Cutler [EMAIL PROTECTED] writes: After dinking around with the build tools for a bit, I'm reasonably sure this is put together correctly, so here goes. I'm looking for a sponsor for my package stripclub, an online comic reader and archiver. It supports the vast majority of webcomics so far tested, though a few kinks still exist, mostly dealing with server oddities. The package was built with pbuilder (sid), and is lintian clean. I see a few problems: * You should change the RFP for stripclub to an ITP (just change the bug title), and then close the bug in the changelog. * Your debian/copyright is lacking a bit. See http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200312/msg7.html for more info. * Standards-Version is out of date * The short description is a little long for my tastes. It seems it could be phrased more concisely. Also, the long description is rather poorly written. It contains incomplete sentences, and the use of acronyms like FLTK should be avoided. See section 6.2 of the developers reference. * The debian/rules file contains a lot of commented out commands left over from the dh_make template. It's best to clean it up and remove commands that will never be used. * The debian/stripclub.doc-base.EX file should be removed. It's just a dh_make example file. * The upstream optimization flags look retarded. -O3 -fomit-frame-pointer -funroll-loops? What is that about? This isn't gentoo... * The md5sums don't match the upstream tarball. It looks like upstream distributes the file as a bz2, so the .orig.tar.gz can't match, but the .tar file inside should still be identical. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with SONAME which changes very often
Bartosz Fenski aka fEnIo [EMAIL PROTECTED] writes: On Fri, Apr 02, 2004 at 11:18:11PM +0200, Goswin von Brederlow wrote: Please give me some hints/suggestions what should be done in such situation? Are there any packages with that situation in our archive? Since you are the only one using I would say link it in static. Problem solved. I made it this way. Seems to work fine. But on second thought, seeing that its utilitie_s_, static linking would waste ram. I was wrong. I thought it will provide many small binaries, but seems that it is linked in one binary with many features. So there won't be wasting ram. The number of binaries won't matter. Running two or more copies of one binary would still use more memory, since the library code isn't being shared. -- You win again, gravity!
Re: Bug in New Maintainers Guide german translation
Nico Golde [EMAIL PROTECTED] writes: Hi, i found a spelling mistake in the german translation of the new maintainers guide. i wrote a patch for this bug. the patch is in the attachment of this mail. please fix it. [EMAIL PROTECTED]:~/privat/Doku/debian/maint-guid] $ md5sum nico_golde_ch-dreq.de.patch fa4af1574a02ecb852b6eaa8fc736bb9 nico_golde_ch-dreq.de.patch Please file a bug against the 'maint-guide' package and include the patch with the report. -- You win again, gravity!
Re: How to deal with SONAME which changes very often
Bartosz Fenski aka fEnIo [EMAIL PROTECTED] writes: On Fri, Apr 02, 2004 at 11:18:11PM +0200, Goswin von Brederlow wrote: Please give me some hints/suggestions what should be done in such situation? Are there any packages with that situation in our archive? Since you are the only one using I would say link it in static. Problem solved. I made it this way. Seems to work fine. But on second thought, seeing that its utilitie_s_, static linking would waste ram. I was wrong. I thought it will provide many small binaries, but seems that it is linked in one binary with many features. So there won't be wasting ram. The number of binaries won't matter. Running two or more copies of one binary would still use more memory, since the library code isn't being shared. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug in New Maintainers Guide german translation
Nico Golde [EMAIL PROTECTED] writes: Hi, i found a spelling mistake in the german translation of the new maintainers guide. i wrote a patch for this bug. the patch is in the attachment of this mail. please fix it. [EMAIL PROTECTED]:~/privat/Doku/debian/maint-guid] $ md5sum nico_golde_ch-dreq.de.patch fa4af1574a02ecb852b6eaa8fc736bb9 nico_golde_ch-dreq.de.patch Please file a bug against the 'maint-guide' package and include the patch with the report. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bengali wordlist for aspell
Soumyadip Modak [EMAIL PROTECTED] writes:
I'm packaging the bengali wordlist for aspell, for Debian. During
dpkg-buildpackage i get the following errors:
modak:/home/soumyadip/Debian/aspell/aspell-bn-0.50-1# dpkg-buildpackage
dpkg-buildpackage: source package is aspell-bn-0.50
dpkg-buildpackage: source version is 1-1
dpkg-buildpackage: source maintainer is Soumyadip Modak
[EMAIL PROTECTED]
dpkg-buildpackage: host architecture is i386
debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
/usr/bin/make distclean
make[1]: Entering directory
`/home/soumyadip/Debian/aspell/aspell-bn-0.50-1'
make[1]: *** No rule to make target `distclean'. Stop.
make[1]: Leaving directory
`/home/soumyadip/Debian/aspell/aspell-bn-0.50-1'
make: [clean] Error 2 (ignored)
cp -f /usr/share/misc/config.sub config.sub
cp -f /usr/share/misc/config.guess config.guess
dh_clean
dpkg-source -b aspell-bn-0.50-1
dpkg-source: building aspell-bn-0.50 in aspell-bn-0.50_1-1.tar.gz
dpkg-source: building aspell-bn-0.50 in aspell-bn-0.50_1-1.dsc
debian/rules build
dh_testdir
# Add here commands to configure the package.
./configure --host=i386-linux --build=i386-linux --prefix=/usr
--mandir=\${prefix}/share/man --infodir=\${prefix}/share/infoWarning:
future versions will require --vars before variables are set
: error: invalid variable name: --host
make: *** [config.status] Error 1
The configure script that comes with the aspell dicts is homebrew (not
created by autoconf), and thus does not accept most of those options.
Edit those out of the debian/rules file. Also, you might want to check
out some of the aspell-* packages in the archive for reference.
--
You win again, gravity!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bengali wordlist for aspell
Soumyadip Modak [EMAIL PROTECTED] writes:
I'm packaging the bengali wordlist for aspell, for Debian. During
dpkg-buildpackage i get the following errors:
modak:/home/soumyadip/Debian/aspell/aspell-bn-0.50-1# dpkg-buildpackage
dpkg-buildpackage: source package is aspell-bn-0.50
dpkg-buildpackage: source version is 1-1
dpkg-buildpackage: source maintainer is Soumyadip Modak
[EMAIL PROTECTED]
dpkg-buildpackage: host architecture is i386
debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
/usr/bin/make distclean
make[1]: Entering directory
`/home/soumyadip/Debian/aspell/aspell-bn-0.50-1'
make[1]: *** No rule to make target `distclean'. Stop.
make[1]: Leaving directory
`/home/soumyadip/Debian/aspell/aspell-bn-0.50-1'
make: [clean] Error 2 (ignored)
cp -f /usr/share/misc/config.sub config.sub
cp -f /usr/share/misc/config.guess config.guess
dh_clean
dpkg-source -b aspell-bn-0.50-1
dpkg-source: building aspell-bn-0.50 in aspell-bn-0.50_1-1.tar.gz
dpkg-source: building aspell-bn-0.50 in aspell-bn-0.50_1-1.dsc
debian/rules build
dh_testdir
# Add here commands to configure the package.
./configure --host=i386-linux --build=i386-linux --prefix=/usr
--mandir=\${prefix}/share/man --infodir=\${prefix}/share/infoWarning:
future versions will require --vars before variables are set
: error: invalid variable name: --host
make: *** [config.status] Error 1
The configure script that comes with the aspell dicts is homebrew (not
created by autoconf), and thus does not accept most of those options.
Edit those out of the debian/rules file. Also, you might want to check
out some of the aspell-* packages in the archive for reference.
--
You win again, gravity!
Re: RFS: bbppp -- PPP tool for the blackbox window manager
Florian Ernst [EMAIL PROTECTED] writes: On Mon, Mar 08, 2004 at 03:52:08PM -0800, Brian Nelson wrote: * The patch that changes 0's to NULL's is pointless. In C++, NULL is just #define NULL 0. Definitely true. I preferred QA's patch over upstream's patch since for me 'NULL' just makes it somewhat clearer. In technical terms they are the same, unlike in plain C, but speaking in human terms (just mine at that time) they differ. But as I don't want my preferences to confuse anyone I reverted this change now. I'm not trying to argue you should prefer one over the other. I just think that modifications to the upstream sources should be kept to a bare minimum. In this particular case, it obscured the point of the patch, which was to initialize report.resumeCommand to 0/NULL. I've uploaded up-to-date content (lintian / linda clean) to http://ernst.uni-hd.de/debian/bbppp Please tell me if there is anything else you want me to check / fix. Well, some of your debhelper stuff could use updating. See http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200303/msg2.html Also, the debian/copyright is kinda funky. This is how I'd do it: This package was debianized by Timshel Knoll [EMAIL PROTECTED] on Thu, 31 Aug 2000 01:28:25 +1100. It was downloaded from http://bbtools.windsofstorm.net/sources/ Upstream Author: John Kennis [EMAIL PROTECTED] Copyright: Copyright (C) 1998-2000 John Kennis Translations Copyright (C) 1999 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. -- Timshel Knoll [EMAIL PROTECTED] Mon, 18 Mar 2002 02:58:54 +1100 This package version was downloaded from http://bbtools.sourceforge.net/ On Debian systems, the complete text of the GNU General Public License, version 2, can be found in /usr/share/common-licenses/GPL-2. -- Florian Ernst [EMAIL PROTECTED] Mon, 1 Mar 2004 18:13:24 +0100 A small sidenote: as 0.2.3-4 didn't make it into Sarge yet and possibly will be delayed because of problems in the s390 buildd (at least that's what I guess) an upload of 0.2.4-1 should be delayed as well... In that case, the build on the broken arch will normally be retried in a few days. Like today. ;) -- Don't worry, it's *in*-flammable. pgp0.pgp Description: PGP signature
Re: PHP/MySQL package
David Moreno Garza [EMAIL PROTECTED] writes: Hi all, I have plans for packaging a little www-based package. It uses PHP and MySQL, over Apache. In the documentation I been searching, I just can find some resources with packaging which need to be compilated or so. In the package I would need to set up a new MySQL database (I vaguely know I could use wwwconfig, but not sure about its use), and set the scripts to some location on DocumentRoot. I am just writting to ask for some documentation resources on www-based packages, if exists. Otherwise, any help or hint would be great. No, but there are plenty of examples to check out: $ grep-available -FDepends -sPackage php4 --and wwwconfig-common Package: tutos Package: drupal Package: phpgroupware Package: mantis Package: spip Package: kronolith Package: omlcs Package: nag Package: jsboard Package: myphpmoney Package: imp3 Package: dcl Package: phpqladmin Package: dacode Package: ilohamail Package: mediamate Package: spip-eva Package: irm Package: ldap-account-manager Package: acidlab Package: opendb Package: cacti Package: phppgadmin Package: moodle Package: mnemo Package: horde2 Package: gallery Package: zoph Package: gween -- Don't worry, it's *in*-flammable. pgp0.pgp Description: PGP signature
Re: RFS: bbppp -- PPP tool for the blackbox window manager
Florian Ernst [EMAIL PROTECTED] writes: On Mon, Mar 08, 2004 at 03:52:08PM -0800, Brian Nelson wrote: * The patch that changes 0's to NULL's is pointless. In C++, NULL is just #define NULL 0. Definitely true. I preferred QA's patch over upstream's patch since for me 'NULL' just makes it somewhat clearer. In technical terms they are the same, unlike in plain C, but speaking in human terms (just mine at that time) they differ. But as I don't want my preferences to confuse anyone I reverted this change now. I'm not trying to argue you should prefer one over the other. I just think that modifications to the upstream sources should be kept to a bare minimum. In this particular case, it obscured the point of the patch, which was to initialize report.resumeCommand to 0/NULL. I've uploaded up-to-date content (lintian / linda clean) to http://ernst.uni-hd.de/debian/bbppp Please tell me if there is anything else you want me to check / fix. Well, some of your debhelper stuff could use updating. See http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200303/msg2.html Also, the debian/copyright is kinda funky. This is how I'd do it: This package was debianized by Timshel Knoll [EMAIL PROTECTED] on Thu, 31 Aug 2000 01:28:25 +1100. It was downloaded from http://bbtools.windsofstorm.net/sources/ Upstream Author: John Kennis [EMAIL PROTECTED] Copyright: Copyright (C) 1998-2000 John Kennis Translations Copyright (C) 1999 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. -- Timshel Knoll [EMAIL PROTECTED] Mon, 18 Mar 2002 02:58:54 +1100 This package version was downloaded from http://bbtools.sourceforge.net/ On Debian systems, the complete text of the GNU General Public License, version 2, can be found in /usr/share/common-licenses/GPL-2. -- Florian Ernst [EMAIL PROTECTED] Mon, 1 Mar 2004 18:13:24 +0100 A small sidenote: as 0.2.3-4 didn't make it into Sarge yet and possibly will be delayed because of problems in the s390 buildd (at least that's what I guess) an upload of 0.2.4-1 should be delayed as well... In that case, the build on the broken arch will normally be retried in a few days. Like today. ;) -- Don't worry, it's *in*-flammable. pgpsRFHifrj7E.pgp Description: PGP signature
Re: PHP/MySQL package
David Moreno Garza [EMAIL PROTECTED] writes: Hi all, I have plans for packaging a little www-based package. It uses PHP and MySQL, over Apache. In the documentation I been searching, I just can find some resources with packaging which need to be compilated or so. In the package I would need to set up a new MySQL database (I vaguely know I could use wwwconfig, but not sure about its use), and set the scripts to some location on DocumentRoot. I am just writting to ask for some documentation resources on www-based packages, if exists. Otherwise, any help or hint would be great. No, but there are plenty of examples to check out: $ grep-available -FDepends -sPackage php4 --and wwwconfig-common Package: tutos Package: drupal Package: phpgroupware Package: mantis Package: spip Package: kronolith Package: omlcs Package: nag Package: jsboard Package: myphpmoney Package: imp3 Package: dcl Package: phpqladmin Package: dacode Package: ilohamail Package: mediamate Package: spip-eva Package: irm Package: ldap-account-manager Package: acidlab Package: opendb Package: cacti Package: phppgadmin Package: moodle Package: mnemo Package: horde2 Package: gallery Package: zoph Package: gween -- Don't worry, it's *in*-flammable. pgpOJv8BYQ9fs.pgp Description: PGP signature
Re: RFS: bbppp -- PPP tool for the blackbox window manager
Florian Ernst [EMAIL PROTECTED] writes: well, OK, I take it nobody is interested in this package at all, as I haven't even recieved negative response so far... ;) I'll continue to maintain my version of the package until someone steps forward I can hand it over to who has / doesn't need a sponsor. I can sponsor you I guess, but I don't have a PPP link on which to test it. I'd have to take your word on it that it works. All the files can be found at http://ernst.uni-hd.de/debian/bbppp Additionally in one week from now I will file a RFS on http://www.internatif.org/bortzmeyer/debian/sponsor/ so this package doesn't get lost in the list archives. Just drop me a mail if you want further comments... I have a couple comments: * The patch that changes 0's to NULL's is pointless. In C++, NULL is just #define NULL 0. * The xlibs-dev build dependency is obsolete: Package: xlibs-dev [...] Description: X Window System client library development files pseudopackage This package smooths upgrades from Debian 3.0 by depending on libice-dev, libsm-dev, libx11-dev, libxext-dev, libxi-dev, libxmu-dev, libxmuu-dev, libxp-dev, libxpm-dev, libxrandr-dev, libxt-dev, libxtrap-dev, libxtst-dev, libxv-dev, pm-dev, x-dev, and xlibs-static-dev. This pseudopackage is only depended upon by packages that haven't yet corrected their dependencies to reflect the new library arrangement. -- Don't worry, it's *in*-flammable. pgp0.pgp Description: PGP signature
Re: randomplay: command-line shuffle music player
John Buttery [EMAIL PROTECTED] writes: * Adam Kessel [EMAIL PROTECTED] [2003-09-07 16:35:14 -0700]: It's definitely a scratch an itch type program. So's emacs. For that matter, so's the kernel itself. :) I'm wondering if something relatively simple (the script is about 340 lines of code) would be worth including in Debian. Personally, my opinion on this is that anything useful enough to be worth writing is worth including. As long as someone's willing to maintain the package, that's all that matters. That goes for any distribution, or any OS for that matter. That is certainly not all that matters. If every script anyone tried to write was included in Debian, Debian would collapse under its own weight. I find it hard to believe any 340 line script would merit its own package. I think it would be much more worthwhile to try to get it added to an existing package, such as one of the command-line players. -- I'm sick of being the guy who eats insects and gets the funny syphilis. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: randomplay: command-line shuffle music player
John Buttery [EMAIL PROTECTED] writes: * Adam Kessel [EMAIL PROTECTED] [2003-09-07 16:35:14 -0700]: It's definitely a scratch an itch type program. So's emacs. For that matter, so's the kernel itself. :) I'm wondering if something relatively simple (the script is about 340 lines of code) would be worth including in Debian. Personally, my opinion on this is that anything useful enough to be worth writing is worth including. As long as someone's willing to maintain the package, that's all that matters. That goes for any distribution, or any OS for that matter. That is certainly not all that matters. If every script anyone tried to write was included in Debian, Debian would collapse under its own weight. I find it hard to believe any 340 line script would merit its own package. I think it would be much more worthwhile to try to get it added to an existing package, such as one of the command-line players. -- I'm sick of being the guy who eats insects and gets the funny syphilis.
Re: lintian error file-in-unusual-dir usr/etc/settings/ withQt3-Application
Dominik Stadler [EMAIL PROTECTED] writes: Hi, I started working on a debian-package. The application uses the Qt-Library as basis (no KDE). During startup, the application looks in a directory /usr/etc/settings/ for system-wide settings for the application. This is not coded inside the application, but a feature of the Qt-Library. Uh, are you sure? If it's using QSettings, you can modify the search path to be something sane. Or is it getting set through a configure script? Showing us the source would be helpful. If I try to include a configfile in this directory, lintian complains about this with several errors and warnings. Rightly so. I need the configfile there in order to set some system-wide settings that are required to run the application. Without them, every user will need to do manual configuration when starting the application. My question therefore: Is this a case where lintian should allow an exception, because I have no other way of telling the Qt-Library to search in a different directory? Or is it simply not possible? No, this certainly shouldn't be allowable. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgp0.pgp Description: PGP signature
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
Dominik Stadler [EMAIL PROTECTED] writes: Hi, I started working on a debian-package. The application uses the Qt-Library as basis (no KDE). During startup, the application looks in a directory /usr/etc/settings/ for system-wide settings for the application. This is not coded inside the application, but a feature of the Qt-Library. Uh, are you sure? If it's using QSettings, you can modify the search path to be something sane. Or is it getting set through a configure script? Showing us the source would be helpful. If I try to include a configfile in this directory, lintian complains about this with several errors and warnings. Rightly so. I need the configfile there in order to set some system-wide settings that are required to run the application. Without them, every user will need to do manual configuration when starting the application. My question therefore: Is this a case where lintian should allow an exception, because I have no other way of telling the Qt-Library to search in a different directory? Or is it simply not possible? No, this certainly shouldn't be allowable. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgp7n6eAvDNRH.pgp Description: PGP signature
Re: lintian error file-in-unusual-dir usr/etc/settings/ with Qt3-Application
Dominik Stadler [EMAIL PROTECTED] writes: Why Qt should look in /usr/etc? Configure your program with --sysconfdir=/etc flag and everything should be OK. Thanks for the hints, but the problem is that the application does not use autoconf/automake/configure, but the build-tool qmake. Is there any equivalent to --sysconfdir there? I couldn't find one. Nope. You'll need to modify the application source. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgpgvwFVxiMVc.pgp Description: PGP signature
Re: [RFS] slimp3 - MPEG Layer III Streaming Server
[EMAIL PROTECTED] (Bruno Rodrigues) writes: Anyone interested in sponsoring my slimp3[1] package and its companions, libmp3-tag-perl[2] and libaudio-wav-perl[3] ? Packages have already been scrutinized by my sponsor Salvador Abreu [EMAIL PROTECTED] and Brian Nelson [EMAIL PROTECTED], but Salvador doesn't have time (University exams time, he's a teacher) and Brian haven't yet replied back to my last request, although he was very responsive before and helped me alot fixing these packages. Err, oh yeah, I completely forgot about sponsoring these. Sorry about that. I'll take a lot of these again. -- Poems... always a sign of pretentious inner turmoil. pgp0.pgp Description: PGP signature
Re: RFS: pdsh
Brian Pellin [EMAIL PROTECTED] writes: Junichi Uekawa wrote: Commercialization of this product is prohibited without notifying the Department of Energy (DOE) or Lawrence Livermore National Laboratory (LLNL). This seems to me to conflict with the GPL, and I'd like confirmation on that. I guess if it is, then the proper procedure would be to ask upstream about the conflict. That conflicts with Debian Free Software Guidelines, even if it doesn't conflict with GPL. Are you certain that this is a violation? I believe you were probably refering to the No discrimination against fields of endeavor clause, but is notification considered a restriction? It doesn't require permission from LLNL, just that they be notified. Any form of notification that *must* be done is not DFSG-compliant. Regardless I will contact the upstream author to see if this product can be distributed without that clause, but in the past have notification clauses been considered a DFSG violation? See, for example, graphviz, which requires any modifications to be sent upstream. It's not exactly that same case, but it's similar enough, I think. -- Poems... always a sign of pretentious inner turmoil. pgp0.pgp Description: PGP signature
Re: RFS: pdsh
Brian Pellin [EMAIL PROTECTED] writes: Junichi Uekawa wrote: Commercialization of this product is prohibited without notifying the Department of Energy (DOE) or Lawrence Livermore National Laboratory (LLNL). This seems to me to conflict with the GPL, and I'd like confirmation on that. I guess if it is, then the proper procedure would be to ask upstream about the conflict. That conflicts with Debian Free Software Guidelines, even if it doesn't conflict with GPL. Are you certain that this is a violation? I believe you were probably refering to the No discrimination against fields of endeavor clause, but is notification considered a restriction? It doesn't require permission from LLNL, just that they be notified. Any form of notification that *must* be done is not DFSG-compliant. Regardless I will contact the upstream author to see if this product can be distributed without that clause, but in the past have notification clauses been considered a DFSG violation? See, for example, graphviz, which requires any modifications to be sent upstream. It's not exactly that same case, but it's similar enough, I think. -- Poems... always a sign of pretentious inner turmoil. pgphyNd10wAOs.pgp Description: PGP signature
Re: How do I get libtool to use g++?
Neil Roeth [EMAIL PROTECTED] writes: I recently had a bug (193950) filed against one of my packages because the shared libraries had undefined non-weak symbols - libstdc++ was not being linked in. I resolved it with what I consider a gruesome hack. I discovered that forcing libtool to use g++ while linking would automatically link in libstdc++. The hack came about because I could not figure out how to get libtool to use g++ instead of gcc. So, I did sed -e 's/CC=gcc/CC=g++/g' libtool lt.tmp mv -f lt.tmp libtool to force it. What's the right way to get libstdc++ linked in to shared libraries of C++ code? The package uses autoconf, automake, libtool, etc. Use -lstdc++ and don't use libtool? Libtool doesn't really support c++ libraries[1]. Well, libtool CVS sort of does, but it's still fucked (this *is* libtool we're talking about here). Libtool itself is a gruesome hack and needs to be put to rest. [1] http://www.gnu.org/manual/libtool-1.4.2/html_node/libtool_53.html -- Looks like excitement by repetition! pgp0.pgp Description: PGP signature
Re: How do I get libtool to use g++?
Neil Roeth [EMAIL PROTECTED] writes: I recently had a bug (193950) filed against one of my packages because the shared libraries had undefined non-weak symbols - libstdc++ was not being linked in. I resolved it with what I consider a gruesome hack. I discovered that forcing libtool to use g++ while linking would automatically link in libstdc++. The hack came about because I could not figure out how to get libtool to use g++ instead of gcc. So, I did sed -e 's/CC=gcc/CC=g++/g' libtool lt.tmp mv -f lt.tmp libtool to force it. What's the right way to get libstdc++ linked in to shared libraries of C++ code? The package uses autoconf, automake, libtool, etc. Use -lstdc++ and don't use libtool? Libtool doesn't really support c++ libraries[1]. Well, libtool CVS sort of does, but it's still fucked (this *is* libtool we're talking about here). Libtool itself is a gruesome hack and needs to be put to rest. [1] http://www.gnu.org/manual/libtool-1.4.2/html_node/libtool_53.html -- Looks like excitement by repetition! pgpeDcKwlfiaW.pgp Description: PGP signature
Re: advice on closing bugs
Neil Roeth [EMAIL PROTECTED] writes: I recently adopted several packages (jade, openjade, opensp) and several of the open bugs were fixed by NMUs, so they have fixed tags. I think all I need to do is send an email to [EMAIL PROTECTED] that says, This bug was fixed in the NMU of version 1.2.1-29.3. The fix has been propagated to the latest version, 1.2.1-32. So, as the new maintainer of the package, I am closing the bug. Do I need to say any more? (I probably wouldn't have asked if there hadn't been so much recent flamage on -devel about closing bugs.) There doesn't seem to be a clear consensus on the best way to close fixed-by-NMU bugs. Your method is of course fine (it's always acceptable to close a bug through -done, I think). Another common way (though inferior, IMO) is to close them with a changelog entry such as * Acknowledge NMU (Closes: ...) Colin's method is my favorite (dpkg-buildpackage -v ...) -- Poems... always a sign of pretentious inner turmoil. pgp0.pgp Description: PGP signature
Re: advice on closing bugs
Neil Roeth [EMAIL PROTECTED] writes: I recently adopted several packages (jade, openjade, opensp) and several of the open bugs were fixed by NMUs, so they have fixed tags. I think all I need to do is send an email to [EMAIL PROTECTED] that says, This bug was fixed in the NMU of version 1.2.1-29.3. The fix has been propagated to the latest version, 1.2.1-32. So, as the new maintainer of the package, I am closing the bug. Do I need to say any more? (I probably wouldn't have asked if there hadn't been so much recent flamage on -devel about closing bugs.) There doesn't seem to be a clear consensus on the best way to close fixed-by-NMU bugs. Your method is of course fine (it's always acceptable to close a bug through -done, I think). Another common way (though inferior, IMO) is to close them with a changelog entry such as * Acknowledge NMU (Closes: ...) Colin's method is my favorite (dpkg-buildpackage -v ...) -- Poems... always a sign of pretentious inner turmoil. pgpClDkMgw6So.pgp Description: PGP signature
Re: How do you upload/build sponsored packages?
[EMAIL PROTECTED] (Bob Proulx) writes: Colin Watson wrote: I actually don't see how dpkg-buildpackage's sign-immediately-after-build defaults ever make sense (except when dpkg-buildpackage was originally written, when debsign didn't yet exist). Why would you want to waste time signing a package you haven't tested yet? Surely the order should be build, test, sign. Accordingly, I have DEBUILD_DPKG_BUILDPACKAGE_OPTS=-uc -us, together with a bunch of other options that don't matter here, in ~/.devscripts. I've never yet found that I want the other behaviour. Would it be somehow possible to change the default behavior? Uh, have you filed a wishlist bug? I don't think it would be difficult to convince the maintainer, especially since debsign is in the same package. -- Poems... always a sign of pretentious inner turmoil. pgpUpjr1wsSaZ.pgp Description: PGP signature
Re: Antwort: Re: new package - don't know how to compile
Matthias Hofer [EMAIL PROTECTED] writes: 1. (*) text/plain ( ) text/html Please send only plain text email to the mailing list. what can I do? I think this means that you need (a more recent version of) GNU automake. What version do you have, if any? I have 1.4-p4-1.1 (from woody). Note that if you're packaging this with the intention of including it in Debian proper, you need to build it with an up-to-date unstable system. -- Looks like excitement by repetition! pgp4V5YmlX9us.pgp Description: PGP signature
