Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop
Hi mentors! Here I am sending this RFC/RFS again. Having corrected all the bugs/wishlist items which came up here on the list, I feel Rhinote is finally ready to be uploaded. Obviously, if someone finds any other problem, I'll be happy to fix it and learn a little more :) Below is the info about the package. * Package: rhinote Version: 0.7.0 * License: GPL URL: http://greyspace.letzebuerg.org/projects.php Upstream author: Marv Boyes [EMAIL PROTECTED] * Description: virtual sticky-notes for your desktop Rhinotes is a small program that provides virtual sticky-notes. It's handy for jotting down quick notes or holding copied text that you plan to paste elsewhere later. . Notes can be saved as plain text for later viewing/editing with Rhinote or any other text editor. . Rhinote is designed to be keyboard friendly, that is, every single action is bound to a specific keystroke. The package is both lintian and linda clean, builds (?) cleanly in an up-to-date pbuilder environment and is available from the following URLs: * http://www.kiyuko.org/debian/rhinote_0.7.0.orig.tar.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.diff.gz * http://www.kiyuko.org/debian/rhinote_0.7.0-1.dsc My little repository is also apt-gettable: just add the following lines to your sources.list deb http://www.kiyuko.org/debian ./ deb-src http://www.kiyuko.org/debian ./ Thank you for your patience. Cheers. -- KiyuKo eof AT kiyuko DOT org Like Russian Rulette with six bullets loaded pgpgxWZimODOE.pgp Description: PGP signature
Re: Linda warnings about manpages in my packages
On Sun, Apr 23, 2006 at 06:33:04PM -0500, Joe Wreschnig wrote: On Thu, 2006-04-20 at 15:51 -0700, Steve Langasek wrote: If it's not supposed to be a public module, it shouldn't be in a public directory, and then there's no reason to provide more packages than just the application package. FWIW, this is not the common attitude in the Python community; people think it's a good idea to store application-specific modules and extensions in the site directory, even if there's no API/ABI stability. For example, I've had several requests for Quod Libet to install its entire private module hierarchy there. You'll find that several programs in Debian, such as gnome-menus, do this already. Personally I think that's very stupid, and leads to 1) a false sense of security about the stability of such APIs, and 2) a lax attitude towards API compatibility in general in Python (since so many public modules break all the time). Yes; putting libraries in public directories that aren't going to support a stable API/API for the lifetime of a release (be it Debian or python) is simply namespace pollution. It's unfortunate that every language community has to grow into an understanding of this the hard way. If Debian is going to buck the trend here (and I think it should, and thankfully does for many programs) a lot of packages are buggy. Well, I think a lot of packages are buggy is a pretty accurate assessment whether Debian adopts a blanket policy on this or not... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: thailatex (orphaned package for babel-based Thai latex support)
On 4/25/06, Frank Küster [EMAIL PROTECTED] wrote: Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: Dear mentors, I have adopted the orphaned thailatex package in the bug: http://bugs.debian.org/357871 And now the brand new package has been dressed up, waiting for sponsoring. I'm willing to look into it and finally sponsor it (especially since my recent NMU might have caused this or that bug). There are still some minor things to do: Thank you for your comments. I've tried to cover all of them. Please check the updated package at the old place: http://linux.thai.net/~thep/debian/source/thailatex/ Below is what I did: - debian/changelog: * You shouldn't close bugs with new upstream release as an explanation, unless it's a request to package the new version. Instead, write something like * New upstream release - now has a orig.tar.gz again (closes: #344554) - ... babel.sty ... (closes: #351501) - updated fonts - new Loma font I've logged the closing of #344554 separately, but decided not to close #351501, because the closing in previous change was simply from the fact that it's gone when I tried installing. So, being unable to reproduce the bug, even by stepwise upgrades, I can't find a good explanation, and should leave it open, until it can be reproduced somehow. I'll follow up the bug soon. * the bumped standards version to... section usually also gets an explanation (like no changes needed or lots of packaging changes, details below, or whatever). Done. However, as a new comer who haven't read old standards, I can't gather what changes are needed between old and new version. I hope saying after the repackaging is sufficient. - debian/copyright: Should mention where babel.sty comes from. I assume it's a newer upstream version than teTeX's. Anyway, be sure to follow the instructions in 3.4 of the Debian TeX Policy Draft, especially the second paragraph under number 2. (hint: the maintainer address for the Basic TeX packages is [EMAIL PROTECTED], you can also reach texlive's maintainer there). I've added babel.sty copyright info, by taking from tetex-base's copyright file, and from within the file itself. - debian/README.Debian: Please check that the information is still correct and needed (and if yes, fix the bad wording, it misses a problems or similar). I've totally rewritten it. - debian/rules: You could switch to using dh_installtex for the fonts, this would also make the maintainer scripts simpler, and you'd even no longer need 10thailatex.cfg in your debian directory. But this is optional (and I'm not the dh_installtex guy among the Debian TeX Task Force, so don't ask me for details). I used dh_installtex to install the package's maps file, which was simply renamed from 10thailatex.cfg. - installation: * thai.map should not be in TEXMFSYSCONFIG, see file:///usr/share/doc/tex-common/Debian-TeX-Policy.html/ch4.html#s-configurationfiles Ah, done. It seems upstream has already put it in the right place. So, I just removed the mv line. * it would be nice if the documentation, at least the upstream README. would be available to texdoc. A symlink /usr/share/doc/texmf/thailatex/thailatex.txt - ../../thailatex/README would do. Done, with dh_link and the package's links file. Let me know if there is still something missing. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/
Re: how to create a Release file
Damyan Ivanov wrote: apt-ftparchive(1) gives: release The release command generates a Release file from a directory tree. It recursively searches the given directory for Packages, Packages.gz, Packages.bz2, Sources, Sources.gz, Sources.bz2, Re‐ lease and md5sum.txt files. It then writes to stdout a Release file containing an MD5 digest and SHA1 digest for each file. Values for the additional metadata fields in the Release file are taken from the corresponding variables under APT::FT‐ PArchive::Release, e.g. APT::FTPArchive::Release::Origin. The supported fields are: Origin, Label, Suite, Version, Codename, Date, Architectures, Components, Description. See second paragraph. Perhaps a couple of -o APT::FTPArchive::Xyz=Foo options could help? Thanks for the answer, unfortunately it does not work (at least not in stable release). Any option I specified is not taken into account (no error messages on the output either!), the Release file still begins only with: -- Date: Tue, 25 Apr 2006 08:30:22 UTC MD5Sum: ... -- Maybe upgrading to testing solves the problem ?? Another question - where the Release file should be located ? According to docs I placed it into dists/release, but when looking at the debian mirrors I see also some Release files in dist/release/main/binary-i386 etc Can anyone comment on it, please ? Thanks a lot, best regards Tomas E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Keeping previous changelogs
Dear Mentors, I have one question about changelog handling in debian packages. I'm building a new source package with multiple sub-packages. The sub-packages, however, were formerly built separately as single sources, despite the fact that they were from the same upstream source, due to some licensing problem. And now the licensing problem is solved upstream. So, I wish to build them from a single source. All seem to be doing well, except for one little point: how to handle the changelog.Debian. Certainly, the previous changelogs of the sub-packages should be kept. But now there is only one changelog for the new package. I'm thinking about having the new package's changelog been started as a fresh new one, and keeping each sub-package's previous changelog as changelog-preX.Y.Z.Debian.gz. Is this OK according to Debian policy? Or is there other recommended way? Thank you, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/
Re: RFS: thailatex (orphaned package for babel-based Thai latex support)
Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: Thank you for your comments. I've tried to cover all of them. Please check the updated package at the old place: http://linux.thai.net/~thep/debian/source/thailatex/ I'll not be able to do this today (I think), please remind me if I don't speak up by tomorrow evening. I've logged the closing of #344554 separately, but decided not to close #351501, because the closing in previous change was simply from the fact that it's gone when I tried installing. So, being unable to reproduce the bug, even by stepwise upgrades, I can't find a good explanation, and should leave it open, until it can be reproduced somehow. I'll follow up the bug soon. I suggest to contact the submitter and ask him whether he ever could, and now still can reproduce it. * the bumped standards version to... section usually also gets an explanation (like no changes needed or lots of packaging changes, details below, or whatever). Done. However, as a new comer who haven't read old standards, I can't gather what changes are needed between old and new version. I hope saying after the repackaging is sufficient. Have a look at /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Keeping previous changelogs
Dear Mentors, I'm thinking about having the new package's changelog been started as a fresh new one, and keeping each sub-package's previous changelog as changelog-preX.Y.Z.Debian.gz. Is this OK according to Debian policy? Or is there other recommended way? That seems ok, AFAIK there is nothing in then policy against this. There is not really another way of doing this anyway. Greetings Arjan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problems with leftovers from unregistering alternatives
Hi ! I have just recieved a bug: #364742 - and piuparts is as always right. Something fails in removing alternatives again. /usr/share/icons/default/index.theme pointing into alternatives # update-alternatives --display x-cursor-theme x-cursor-theme - status is auto. link currently points to /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme I have unregistered also that link with the alternatives, but trying manually anyway: [EMAIL PROTECTED]:/# update-alternatives --remove x-cursor-theme /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme [EMAIL PROTECTED]:/# update-alternatives --display x-cursor-theme x-cursor-theme - status is manual. link currently points to /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme No versions available. so that changed nothing. But this did. # update-alternatives --remove-all x-cursor-theme [EMAIL PROTECTED]:/# update-alternatives --display x-cursor-theme No alternatives for x-cursor-theme. I of course cannot use --remove-all in my post-inst script, what have I done wrong - and how do I correct it ? /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to create a Release file
Tomas Davidek [EMAIL PROTECTED] writes: Damyan Ivanov wrote: apt-ftparchive(1) gives: release The release command generates a Release file from a directory tree. It recursively searches the given directory for Packages, Packages.gz, Packages.bz2, Sources, Sources.gz, Sources.bz2, Reâ lease and md5sum.txt files. It then writes to stdout a Release file containing an MD5 digest and SHA1 digest for each file. Values for the additional metadata fields in the Release file are taken from the corresponding variables under APT::FTâ PArchive::Release, e.g. APT::FTPArchive::Release::Origin. The supported fields are: Origin, Label, Suite, Version, Codename, Date, Architectures, Components, Description. See second paragraph. Perhaps a couple of -o APT::FTPArchive::Xyz=Foo options could help? Thanks for the answer, unfortunately it does not work (at least not in stable release). Any option I specified is not taken into account (no error messages on the output either!), the Release file still begins only with: -- Date: Tue, 25 Apr 2006 08:30:22 UTC MD5Sum: ... -- Maybe upgrading to testing solves the problem ?? Another question - where the Release file should be located ? According to docs I placed it into dists/release, but when looking at the debian mirrors I see also some Release files in dist/release/main/binary-i386 etc Can anyone comment on it, please ? There are Release files and Release files. :) The dists/sid/Release and dists/sid/Release.gpg are crucial for security and apts authentication. They have to be created on every update. The dists/sid/main/binary-i386/Release file is only used for pining and is completly static. Just download the file from debian and modify it to fit. Thanks a lot, best regards Tomas MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to create a Release file
Am Dienstag, den 25.04.2006, 10:34 +0200 schrieb Tomas Davidek: Damyan Ivanov wrote: apt-ftparchive(1) gives: release The release command generates a Release file from a directory tree. It recursively searches the given directory for Packages, Packages.gz, Packages.bz2, Sources, Sources.gz, Sources.bz2, Re‐ lease and md5sum.txt files. It then writes to stdout a Release file containing an MD5 digest and SHA1 digest for each file. Values for the additional metadata fields in the Release file are taken from the corresponding variables under APT::FT‐ PArchive::Release, e.g. APT::FTPArchive::Release::Origin. The supported fields are: Origin, Label, Suite, Version, Codename, Date, Architectures, Components, Description. See second paragraph. Perhaps a couple of -o APT::FTPArchive::Xyz=Foo options could help? Thanks for the answer, unfortunately it does not work (at least not in stable release). Any option I specified is not taken into account (no error messages on the output either!), the Release file still begins only with: -- Date: Tue, 25 Apr 2006 08:30:22 UTC MD5Sum: ... -- Would you please be so kind to post your exact command and where you run it? Maybe upgrading to testing solves the problem ?? No. As I already said in my other mail: the version in Sarge can create those files. Another question - where the Release file should be located ? According to docs I placed it into dists/release, but when looking at the debian mirrors I see also some Release files in dist/release/main/binary-i386 etc Can anyone comment on it, please ? Goswin von Brederlow already did. Just a minor addition: Only Sarge uses the Release files e.g. dists/sid/main/binary-i386/Release for pinning. Testing and unstable use the file e.g. dists/sid/Release. AFAIK the other files are not longer downloaded. Regards, Daniel
Re: RFS: thailatex (orphaned package for babel-based Thai latex support)
On 4/25/06, Frank Küster [EMAIL PROTECTED] wrote: Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: I've logged the closing of #344554 separately, but decided not to close #351501, because the closing in previous change was simply from the fact that it's gone when I tried installing. So, being unable to reproduce the bug, even by stepwise upgrades, I can't find a good explanation, and should leave it open, until it can be reproduced somehow. I'll follow up the bug soon. I suggest to contact the submitter and ask him whether he ever could, and now still can reproduce it. Yes, I've followed up the bug. * the bumped standards version to... section usually also gets an explanation (like no changes needed or lots of packaging changes, details below, or whatever). Done. However, as a new comer who haven't read old standards, I can't gather what changes are needed between old and new version. I hope saying after the repackaging is sufficient. Have a look at /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Thanks for the guide. I've checked all the changes. Based on the check list, the only relevant change appears to be changelog conversion to UTF-8. Changes updated at the old place. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/
Re: proper way to package mozilla extensions
On Mon, 24 Apr 2006, Don Armstrong wrote: On Mon, 24 Apr 2006, Yaroslav Halchenko wrote: ... 1. There are two possible packaging schemes a. Keep only original .xpi in the .orig.tar.gz, and extract/dpatch it at build time. b. Keep unzipped .xpi in .orig.tar.gz. c. Distribute the actual source code in the orig.tar.gz. ... doh... how could I forget about this one? ;-) Otherwise it's a PITA to actually patch the .xpi, as you have to unpack it, unpack the jar, patch the jar, pack the jar, pack the xpi. totally true... See Michael Spang's work on greasemonkey for an example on how to do this. thank you - I will check it out! 1: Note that I personally won't sponsor mozilla modules that don't distribute the actual source in the orig.tar.gz... xpi and jar is the source -- it is just packaged with the other than tar/gzip archiver and nested in each other to make our life fun ;-) That is why there is no alternative tarball with the true source is often provided (even if the license is GPL) -- at least I didn't mention any on https://addons.mozilla.org. I will check with the upstream if they will not mind provide .tar.gz as well... -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpuwqV2s5Iz8.pgp Description: PGP signature
Re: Keeping previous changelogs
On 4/25/06, Arjan Oosting [EMAIL PROTECTED] wrote: Dear Mentors, I'm thinking about having the new package's changelog been started as a fresh new one, and keeping each sub-package's previous changelog as changelog-preX.Y.Z.Debian.gz. Is this OK according to Debian policy? Or is there other recommended way? That seems ok, AFAIK there is nothing in then policy against this. There is not really another way of doing this anyway. Thanks for the confirmation. That makes me more confident to do it. :-) Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/
Re: proper way to package mozilla extensions
Yaroslav Halchenko [EMAIL PROTECTED] writes: xpi and jar is the source -- it is just packaged with the other than tar/gzip archiver and nested in each other to make our life fun ;-) That is why there is no alternative tarball with the true source is often provided (even if the license is GPL) -- at least I didn't mention any on https://addons.mozilla.org. I will check with the upstream if they will not mind provide .tar.gz as well... Sometimes Mozilla extensions contain other binaries. One example that I know is the Html Validator extension. And I know that because my AMD64 Firefox loads the i386 version of this extension. And when I try to use it Firefox says it is not compatible. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to create a Release file
Pinning and other fanciness aside, I just use this quick and dirty
bit of script to build my in-place repositories for me:
rm -f Contents.bz2 Contents.gz Packages.bz2 Packages.gz \
Release Release.gpg Sources.bz2 Sources.gz
apt-ftparchive contents . Contents
bzip2 -k Contents
gzip -9 Contents
apt-ftparchive packages . Packages
bzip2 -k Packages
gzip -9c Packages Packages.gz
apt-ftparchive sources . Sources
bzip2 -k Sources
gzip -9c Sources Sources.gz
apt-ftparchive release . Release
rm Packages Sources
gpg --armor --default-key =Jeremy Stanley [EMAIL PROTECTED] \
--detach-sign --output Release.gpg Release
This works to get signed releases in etch and later, and then users
of the repository can:
finger [EMAIL PROTECTED] | sudo apt-key add -
...or:
wget -O- \
http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0x29ABF7441FB84657; \
| sudo apt-key add -
...at which point apt-get will stop complaining about unsigned
packages/releases for them.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: spcaview : package review needed
Le mardi 25 avril 2006 à 11:20 +0800, Paul Wise a écrit : On Mon, 2006-04-24 at 23:48 +0200, Le_Vert wrote: spcaview : package review needed The convention is RFC: package -- package description http://www.le-vert.net/divers/debian-package/spcaview/spcaview_20051212-1.dsc Best to just specify the dsc/diff so we can go dget -x url.dsc for a more thorough review, or open it in a browser for a quick one. Could you check this package before my sponsor upload it ? : Some comments: * hopefully your sponsor will check it too ;) He is, but as he has no video device he can't check if everything is working... * debian/changelog: the version should be 0.0.20051212 or 0.0.0.20051212 or something so that if upstream changes their version scheme, you won't have to use and epoch. Fixed. * debian/control: might want to add the Homepage. see the devref 6.2.4 for how Fixed. . * debian/compat: might want to consider dropping to 4 if you don't use any debhelper 5 features (makes things slightly easier for sarge backporters) Downgraded. * debian/control: package description could use some work, esp grammar. consult either this list or the debian-l10n-english list if english is not your first language. Also, check policy, the devref and [1] for some helpful tips for descriptions. I did my best... I hope it's better now, I'm not a nativ english speaker. * debian/copyright: you miss the authors and some of the copyrights, please read [2] and check them with mc and grep -rih copyright . | sort -u I added everything I can find in any sources files. * debian/rules: better to use quilt/dpatch than a homebrew patch system I'm using dpatch right now, pretty nice, thanks :-) * debian/rules: you can use debian/manpages instead of passing arguments to dh_installman Fixed. * debian/watch: please add one (read uscan(1) for more info) Added. Looks great but is it usefull ? Can I receive an e-mail when my package is no more up to date ? * debian/patches and debian/manpages: don't forget to send these to upstream (except changing the BIN variable, upstream should use /usr/local) It'll be done. * http-java-applet/install should probably get installed as a doc. http-java-applet/index-sample.html and http-java-applet/control.jpg should probably be installed using dh_installexamples * orig.tar.gz: http-java-applet/JWebcamPlayer.jar contains compiled bytecode, it *must not* be shipped (and probably should be removed from the orig.tar.gz). You should recompile it using free java if possible. If not, ask on the debian-java list, or possibly the classpath developers for help porting it. * orig.tar.gz: what is the copyright/licence for SwingWorker.java? looks like a copy of [3]. If so, that would be copyright by sun and not distributable. Removed all of it from sources. Doesn't work, no copyright information and this is really not related to spcaview tools anyway. * orig.tar.gz: please remove the build/install instructions from the README (since debian users don't need them), and ask upstream to split those out into INSTALL. Fixed. * lintian/linda: give these errors: E: spcaview source: debian-rules-missing-required-target binary-indep N: N: The debian/rules file for this package does not provide one of the N: required targets. All of build, binary, binary-arch, binary-indep, and N: clean must be provided, even if they don't do anything for this N: package. N: N: Refer to Policy Manual, section 4.8 for details. N: W: spcaview; A binary links against a library it does not use symbols from This package contains a binary that links against a library that is not in the Depends line. This may also be a bug in the library which does not have a shlibs file. Binary-indep rule added. What's about the second one ? My lintian doesn't give this warning (Etch). 1. http://people.debian.org/~walters/descriptions.html 2. http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html 3. http://java.sun.com/products/jfc/tsc/articles/threads/src/SwingWorker.java Thanks ! I guess the package is really far better now... Any other suggestions ? http://www.le-vert.net/divers/debian-package/spcaview/ signature.asc Description: Ceci est une partie de message numériquement signée
Re: building rpms on debian system?
The Fungi wrote: I'm not sure I've seen what seems to me to be the obvious solution come through in a reply yet, but why not just create a custom chroot for your target distribution (be it RHEL 4 or SUSE 9 or whatever) and build in there? Apparently this works pretty well for most people. If so, great. I'm aware that any autobuilt package in Debian is handled with a chroot of some kind, so obviously I've either been doing something wrong, or I'm tripping over edge cases that don't get along with virtual Linux installs of any kind. Do it a la pbuilder and just keep a tarfile of the clean system archived so you can have several without taking up much space, and upgrade them periodically as needed. Your only limitation is that you're stuck in the chroot using whatever kernel you've booted for Debian, but if that becomes an issue, UML to the rescue (in some ways easier to manage than chroots, in my opinion). For reasonably current OSes, this is probably a useful option. But my own experience has been that while it may work OK for semi-recent OS releases, it's of limited value for older OS releases. I've never used this for building packages, but I tried for some time to build an updated version of a Quake2 mod. Unfortunately, a critical library used by this mod is only available as a statically-linkable binary - the library's author(s) did not release their source for whatever reason. In order to get the mod to build in such a way that it actually runs without segfaulting, it must be compiled with a GCC version that matches the version used to build the library (~2.7something). At the very *least*. (g)libc version, kernel version, possibly the CPU, and who knows what else may also be factors; the code will compile and link apparently without error pretty much anywhere I've tried. But it will either fail to load in Quake2 at all, or it will segfault on attempting to exercise any of its capabilities. (Once compiled correctly, it seems to *run* just fine pretty much anywhere. Nrgh.) However, **EVERY** attempt I've made to do this in a logically separate OS running under the current real OS (chroot, UML, and most recently a VMWare virtual machine) has failed to produce a working binary. The ONLY place I've been able to successfully build this mod was in a distribution that shipped with a suitable GCC, installed on a real P133. (RedHat 5.2 or Debian slink [2.1] contain a suitable gcc.) Other things I've tried in chroots, UML images, and VMWare virtual machines have shown a minor assortment of other oddities as well. (Quite aside from the minor headaches of actually getting RedHat and its descendants and variants installed in a chroot or UML image; this is one place Debian has a big advantage.) -kgd -- Get your mouse off of there! You don't know where that email has been! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: spcaview : package review needed
On Tue, Apr 25, 2006 at 10:09:34PM +0200, Le_Vert wrote: Le mardi 25 avril 2006 ?? 11:20 +0800, Paul Wise a ??crit : On Mon, 2006-04-24 at 23:48 +0200, Le_Vert wrote: spcaview : package review needed The convention is RFC: package -- package description http://www.le-vert.net/divers/debian-package/spcaview/spcaview_20051212-1.dsc I'm using dpatch right now, pretty nice, thanks :-) FYI many people are now starting to use quilt. * debian/watch: please add one (read uscan(1) for more info) Added. Looks great but is it usefull ? Can I receive an e-mail when my package is no more up to date ? I don't think there is any .d.o service for this (yet). I have a wishlist bug against devscripts for a local cronjob example that will query DEHS to do this, though. I also have a 30 line webdiff script I'm running nightly against a couple pages, which I supposed could be used to do the same thing. E: spcaview source: debian-rules-missing-required-target binary-indep N: N: The debian/rules file for this package does not provide one of the N: required targets. All of build, binary, binary-arch, binary-indep, and N: clean must be provided, even if they don't do anything for this N: package. N: N: Refer to Policy Manual, section 4.8 for details. N: W: spcaview; A binary links against a library it does not use symbols from This package contains a binary that links against a library that is not in the Depends line. This may also be a bug in the library which does not have a shlibs file. Binary-indep rule added. What's about the second one ? My lintian doesn't give this warning (Etch). unstable does have a newer lintian; I don't know if thats the cause. You still know lintian -I, right? I guess ldd -u might help find the cause. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping previous changelogs
I had the same problem with a package nyself. What I did was put the old ones in the format changelog-oldpackagename.Debian.old. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFS] ophaned package glosstex
Hi, glosstex was orphaned two month ago. However I use it everyday and I furthermore I correct a few bugs and I improve it (hyperref). Therefore I am searching a sponsor. Regards Bastien ROUCARIES PS: GlossTeX is a tool for the automatic preparation of glossaries, lists of acronyms and sorted lists in general for use with LaTeX and MakeIndex. GlossTeX combines the functionality of acronym, nomencl and GloTeX. Like GloTeX, it uses the same format glossary definition files. GlossTeX can be used together with nomencl, nevertheless.
Re: [RFS] ophaned package glosstex
On Tue, Apr 25, 2006 at 10:32:24PM +, roucaries bastien wrote: Hi, glosstex was orphaned two month ago. However I use it everyday and I furthermore I correct a few bugs and I improve it (hyperref). Could you provide a hypertext link (url) to the source package you wish to have uploaded? Thanks Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting *really* close to releasing my first .deb's... What's next?
Russ Allbery [EMAIL PROTECTED] wrote:
The separate debian/ directory is sort of a psychological
separation of hats that keeps it clearer that I may not always and forever
wear both hats.
The idea of a --with-debian-policy configure script argument
occured to me today; having that argument expand to all of the arguments my
package uses to fit in with debian:
./configure --prefix=/usr --mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info --host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) --libexecdir=\$${prefix}/lib \
--with-makefilepl-args=INSTALLDIRS=vendor PREFIX=/usr \
--with-docdir=/usr/share/doc/libbtt0/html
Anyways, I've successfully moved to a non-native package and removed
all lintian warnings, except one that shows up on my work machine, but not
on my home machine:
W: libapache2-mod-bt: binary-or-shlib-defines-rpath
./usr/lib/apache2/modules/mod_bt.so /usr/local/lib
I've asked the debian-apache list how much I should care about that.
New .deb's are here:
http://www.crackerjack.net/mod_bt/experimental_debs/
In that folder is also the output from debuild and pbuilder. It
seems sane enough to me. :-)
So now I need a sponsor. Is there anybody out there that is willing
to shepherd these .deb's into the flock of debian/unstable?
Thanks,
Tyler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting *really* close to releasing my first .deb's... What's next?
Tyler MacDonald [EMAIL PROTECTED] writes: Anyways, I've successfully moved to a non-native package and removed all lintian warnings, except one that shows up on my work machine, but not on my home machine: W: libapache2-mod-bt: binary-or-shlib-defines-rpath ./usr/lib/apache2/modules/mod_bt.so /usr/local/lib I've asked the debian-apache list how much I should care about that. You should care, since it means that if someone installs, say, Apache 2.2 in /usr/local, your package will break in bizarre and unexpected ways. It's not clear where this is coming from, as the Debian apxs2 should not be doing this. But I haven't looked at your package rules to see how you're building the shared library. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with leftovers from unregistering alternatives
On Tue, Apr 25, 2006 at 12:15:57PM +, Sune Vuorela wrote: I have just recieved a bug: #364742 - and piuparts is as always right. Something fails in removing alternatives again. /usr/share/icons/default/index.theme pointing into alternatives # update-alternatives --display x-cursor-theme x-cursor-theme - status is auto. link currently points to /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme I have unregistered also that link with the alternatives, but trying manually anyway: [EMAIL PROTECTED]:/# update-alternatives --remove x-cursor-theme /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme [EMAIL PROTECTED]:/# update-alternatives --display x-cursor-theme x-cursor-theme - status is manual. link currently points to /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme No versions available. so that changed nothing. what does update-alternatives --list x-cursor-theme list in this case? It really looks to me like a u-a bug, not a bug in the calling maintainer script. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Getting *really* close to releasing my first .deb's... What's next?
Russ Allbery [EMAIL PROTECTED] wrote: Tyler MacDonald [EMAIL PROTECTED] writes: Anyways, I've successfully moved to a non-native package and removed all lintian warnings, except one that shows up on my work machine, but not on my home machine: W: libapache2-mod-bt: binary-or-shlib-defines-rpath ./usr/lib/apache2/modules/mod_bt.so /usr/local/lib I've asked the debian-apache list how much I should care about that. You should care, since it means that if someone installs, say, Apache 2.2 in /usr/local, your package will break in bizarre and unexpected ways. It's not clear where this is coming from, as the Debian apxs2 should not be doing this. But I haven't looked at your package rules to see how you're building the shared library. Debian's apxs2 clearly states: /usr/bin/apxs2 +447: $opt .= -rpath $CFG_LIBEXECDIR -module -avoid-version $apr_ldflags; And in it's makefile generator: /usr/bin/apxs2 +700:$(SH_LINK) -rpath $(libexecdir) -module -avoid-version mod_%NAME%.lo That's why I've asked debian-apache. :-) A response to that (http://lists.debian.org/debian-apache/2006/04/msg00038.html) isn't the only thing holding me back tho. I still have a few things to do before I can release 0.0.15, and I'm waiting on my webmistress to give me a new logo (see htdocs/no_apache_logo.txt in the distribution). Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting *really* close to releasing my first .deb's... What's next?
Tyler MacDonald [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] wrote: W: libapache2-mod-bt: binary-or-shlib-defines-rpath ./usr/lib/apache2/modules/mod_bt.so /usr/local/lib It's not clear where this is coming from, as the Debian apxs2 should not be doing this. But I haven't looked at your package rules to see how you're building the shared library. Debian's apxs2 clearly states: /usr/bin/apxs2 +447: $opt .= -rpath $CFG_LIBEXECDIR -module -avoid-version $apr_ldflags; -rpath as an option to libtool is separate and not equivalent to rpath in a shared library build. -rpath sometimes results in an rpath in the resulting object, but generally does not. However, if $CFG_LIBEXECDIR in your build is /usr/local/lib, that's probably a problem. In general, the string /usr/local should not appear anywhere in your build for Debian packages. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting *really* close to releasing my first .deb's... What's next?
Russ Allbery [EMAIL PROTECTED] wrote: However, if $CFG_LIBEXECDIR in your build is /usr/local/lib, that's probably a problem. In general, the string /usr/local should not appear anywhere in your build for Debian packages. It doesn't, and apxs2's reply is the same on both systems: $ /usr/bin/apxs2 -q LIBEXECDIR /usr/lib/apache2/modules Yet on my work system, lintian complains with that. On my home system, both with pbuilder and just plain debuild, the warning does not appear. This is confusing me. On my home system, I've added /usr/local/lib to my ld.so.conf because I'm compiling libraries there all the time. I'm wondering if the presence of it there is preventing it from being added to RPATH at home. Still, even though I ran pbuilder at home, wouldn't pbuilder's ld.so.conf be a debian default without my customization? I'm going to bash away at it some more... Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting *really* close to releasing my first .deb's... What's next?
Tyler MacDonald [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] wrote: However, if $CFG_LIBEXECDIR in your build is /usr/local/lib, that's probably a problem. In general, the string /usr/local should not appear anywhere in your build for Debian packages. It doesn't, and apxs2's reply is the same on both systems: $ /usr/bin/apxs2 -q LIBEXECDIR /usr/lib/apache2/modules Yet on my work system, lintian complains with that. On my home system, both with pbuilder and just plain debuild, the warning does not appear. This is confusing me. On my home system, I've added /usr/local/lib to my ld.so.conf because I'm compiling libraries there all the time. I'm wondering if the presence of it there is preventing it from being added to RPATH at home. Yes, libtool will refrain from adding to rpath any path that's already listed in the system ld.so.conf, so that's quite possibly the explanation of why the behavior is different. That doesn't explain where the /usr/local/lib is coming from in the first place, though. I've built Apache modules for Debian before and have never seen this problem. Although... I do just build the module and don't let apxs2 install the module, since it didn't support DESTDIR. If you're doing installation with apxs2, maybe it's relinking in some bizarre way? Still, even though I ran pbuilder at home, wouldn't pbuilder's ld.so.conf be a debian default without my customization? In fact, at least in my pbuilder chroot, I have no ld.so.conf at all. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: spcaview : package review needed
On Tue, 2006-04-25 at 16:14 -0400, Justin Pryzby wrote: I'm using dpatch right now, pretty nice, thanks :-) FYI many people are now starting to use quilt. For good reason, it rocks! * debian/watch: please add one (read uscan(1) for more info) Added. Looks great but is it usefull ? Can I receive an e-mail when my package is no more up to date ? I don't think there is any .d.o service for this (yet). There have been rumblings on #debian-qa and -qa semi-related to this. I have a wishlist bug against devscripts for a local cronjob example that will query DEHS to do this, though. Be awesome if this were included. My lintian doesn't give this warning (Etch). unstable does have a newer lintian; I don't know if thats the cause. You still know lintian -I, right? I guess ldd -u might help find the cause. That was actually from linda, not lintian. ldd and objdump -x would indeed be helpful to find the problem. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: spcaview : package review needed
Paul Wise [EMAIL PROTECTED] writes: That was actually from linda, not lintian. ldd and objdump -x would indeed be helpful to find the problem. The linda warning about linking against a binary that you don't use symbols from is very prone to false positives and often has to just be ignored. It's very difficult to implement that check even at the 80% level and to implement it fully correctly requires knowledge about the global state of the repository that's hard to come by. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
build paths found in binary packages/was: Re: Getting *really* close to releasing my first .deb's... What's next?
On Tue, Apr 25, 2006 at 08:06:05PM -0700, Russ Allbery wrote: Tyler MacDonald [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] wrote: W: libapache2-mod-bt: binary-or-shlib-defines-rpath ./usr/lib/apache2/modules/mod_bt.so /usr/local/lib It's not clear where this is coming from, as the Debian apxs2 should not be doing this. But I haven't looked at your package rules to see how you're building the shared library. Debian's apxs2 clearly states: /usr/bin/apxs2 +447: $opt .= -rpath $CFG_LIBEXECDIR -module -avoid-version $apr_ldflags; -rpath as an option to libtool is separate and not equivalent to rpath in a shared library build. -rpath sometimes results in an rpath in the resulting object, but generally does not. However, if $CFG_LIBEXECDIR in your build is /usr/local/lib, that's probably a problem. In general, the string /usr/local should not appear anywhere in your build for Debian packages. I have often wondered if it would be useful to have a check (say, in lintian ...) grepping the binary package contents for the build directory ... assuming that the build directory is a sufficiently long string, perhaps larger binary packages will need longer build paths, but this doesn't seem like a real problem; /buildd/ itself is long enough to make a random occurance in an enourmous package beyond unlikely. I suspect the only think preventing this from being implemented is that too many things would be affected .. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: build paths found in binary packages/was: Re: Getting *really* close to releasing my first .deb's... What's next?
Justin Pryzby [EMAIL PROTECTED] writes: I have often wondered if it would be useful to have a check (say, in lintian ...) grepping the binary package contents for the build directory ... assuming that the build directory is a sufficiently long string, perhaps larger binary packages will need longer build paths, but this doesn't seem like a real problem; /buildd/ itself is long enough to make a random occurance in an enourmous package beyond unlikely. I suspect the only think preventing this from being implemented is that too many things would be affected .. All debugging information, for instance, I believe embeds the name of the build directory. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proper way to package mozilla extensions
indeed -- proper full building from source is simply necessary in such cases for my case -- upstream provided me with SVN information, I wrote a nasty but nice ( :) ) wrapper script which is called by uscan if there is a fresh .xpi available. That wrapper exports upstream SVN, wrapps exported release into .tar.gz and feeds it to svn-upgrade which takes care about the rest. The only difference now in the rules - I am zipping (greesemonkey leaves everything open which I would consider somewhat an overkill) chrome into .jar during install. This way I have fully automatic upgrade procedure, proper watch file so I could monitor my package easily, all sources are extracted in the .orig.tar.gz -- so it is close to be the best solution If anyone interested: http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/imagezoom_0.2.5.orig.tar.gz http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/imagezoom_0.2.5-1.diff.gz http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/imagezoom_0.2.5-1.dsc http://itanix.rutgers.edu/rumba/dists/sid/perspect/binary-all/web/mozilla-imagezoom_0.2.5-1_all.deb On Tue, 25 Apr 2006, Matthias Julius wrote: Sometimes Mozilla extensions contain other binaries. One example that I know is the Html Validator extension. And I know that because my AMD64 Firefox loads the i386 version of this extension. And when I try to use it Firefox says it is not compatible. Matthias -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpAqoxQREAqu.pgp Description: PGP signature
Re: build paths found in binary packages/was: Re: Getting *really* close to releasing my first .deb's... What's next?
On Tue, Apr 25, 2006 at 09:15:15PM -0700, Russ Allbery wrote: Justin Pryzby [EMAIL PROTECTED] writes: I have often wondered if it would be useful to have a check (say, in lintian ...) grepping the binary package contents for the build directory ... assuming that the build directory is a sufficiently long string, perhaps larger binary packages will need longer build paths, but this doesn't seem like a real problem; /buildd/ itself is long enough to make a random occurance in an enourmous package beyond unlikely. I suspect the only think preventing this from being implemented is that too many things would be affected .. All debugging information, for instance, I believe embeds the name of the build directory. It certainly seems to .. good point. But this shouldn't be the reason not to implement the check, since normal packages shouldn't have debug info; only those matching m/-dbg$/ (or whatever) should. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with leftovers from unregistering alternatives
On 2006-04-26, Steve Langasek [EMAIL PROTECTED] wrote: what does update-alternatives --list x-cursor-theme list in this case? It shows nothing. [EMAIL PROTECTED]:/# update-alternatives --list x-cursor-theme [EMAIL PROTECTED]:/# It really looks to me like a u-a bug, not a bug in the calling maintainer script. I have been considering the same thing, but I am asking advice here before doing anything else, as I am quite new into u-a. Except if I need to remove the alternatives links in the exact opposite order of registering them. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
