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
Brian Nelson [EMAIL PROTECTED] wrote: * 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. See also http://www.de.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz 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. If it is a bug, it's still a bug; whether it should be fixed in a Debian-specific patch or by pestering upstream about it is at the descretion of the maintainer. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Can I simulate a weak conflict?
Nicolas Boullis [EMAIL PROTECTED] wrote: Oh, and I just thought there could be a workaround. I could make a new no-udev empty package that conflicts with udev, and then write Recommends: no-udev | udev (= 0.060-1). An elegant solution ;-) I guess this would behave as expected, but I think that having one more package only for this would be quite insane! Especially because others would pick up the idea... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Can I simulate a weak conflict?
Hi. Nicolas Boullis wrote: If there's currently no way to set up such things, it might be worth suggesting to add such a feature to next-generation .deb format. Don't you think so? To be honest, no. If you do a Recommends: udev (= ...), most people will just install the recommended udev and be fine. People who have reason to not like to use udev will just not. Most people won't want to make a decision, so it's of no use giving them the choice. Those who want to choose will read the README.Debian to see what's going on. For the others: Do venture a single recommondation. Oh, and I just thought there could be a workaround. I could make a new no-udev empty package that conflicts with udev, and then write Recommends: no-udev | udev (= 0.060-1). I guess this would behave as expected, but I think that having one more package only for this would be quite insane! Let's not. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Error in the account verification!
Title: Message Dear FlexWindow user, The FlexWindow update you send encountered an error in the account verification. As a result your window has not been updated. The cause of the problem is most probably a misspelled account name, password or window name in the subject line of your message. Please check the settings in the subject line and resend your update.If the problem persists, contact [EMAIL PROTECTED].
Re: Looking for python-xlib sponsor
On Tue, Jul 26, 2005 at 10:57:47PM +0200, Martin v. Löwis wrote: Geert Stappers wrote: snip/ That is what is done with python. Please post also the description of the non default or dummy packages. I haven't really changed the description since I adopted the packages, but here you go: Package: python2.1-xlib Version: 0.12-5 Section: python Priority: extra Architecture: all Depends: python2.1 Installed-Size: 317 Maintainer: Martin v. Löwis [EMAIL PROTECTED] Source: python-xlib Description: Interface for Python to the X11 Protocol (for Python2.1) python-xlib is a 100% pure python implementation of the X11 protocol. snip/ Package: python2.4-xlib Version: 0.12-5 Section: python Priority: extra Architecture: all Depends: python2.4 Installed-Size: 317 Maintainer: Martin v. Löwis [EMAIL PROTECTED] Source: python-xlib Description: Interface for Python to the X11 Protocol (for Python2.4) python-xlib is a 100% pure python implementation of the X11 protocol. python2.4-xlib is new; this closes #292560. Okay, thanks. After having checked the debian/rules file I understood why you originally came with only the default package. My apology for being grumpy. Some advice about requesting a sponsor: reread http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#rfs And for the interest level I guess that [EMAIL PROTECTED] is good place for also RFS. Regards, Martin Cheers Geert Stappers signature.asc Description: Digital signature
how to prevent binary incompatibilities with libraries (in reference to Bug#320029)
I need some help with finding a good resolution for Bug#320029.
In summary, the current version of my 'librmagick-ruby' package was
compiled against libmagick6-dev_6.0.6.x. It works nicely when run with
libmagick6_6.0.6.x, but fails when libmagick6 is upgraded to the version
currently in unstable (6.2.3.x).
I have to admit that I don't understand the implications of the failure;
does this mean that ABI compatibility has been broken, ie. that there's
a bug in the libmagick6 package?
My package currently Depends on libmagick6, sans version number. The
bug reporter suggested that I depend on a specific version - a thought
that had also occurred to me - but I'm not sure that it's the best thing
to do. What do you think?
I'm not sure how I'd inject a version-number into the libmagick6,
wayway, since it's generated by ${shlibs:Depends}. That's another thing
that confuses me: why does the generated dependency not include version
info?
Thanks in advice for your advice, tolerance, personal abuse, or
irrelevant anecdotes.
--
cheers, MikeWhttp://www.dogbiscuit.org/mdub/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to prevent binary incompatibilities with libraries (in reference to Bug#320029)
Mike Williams [EMAIL PROTECTED] writes:
I need some help with finding a good resolution for Bug#320029.
In summary, the current version of my 'librmagick-ruby' package was
compiled against libmagick6-dev_6.0.6.x. It works nicely when run
with libmagick6_6.0.6.x, but fails when libmagick6 is upgraded to the
version currently in unstable (6.2.3.x).
I have to admit that I don't understand the implications of the
failure; does this mean that ABI compatibility has been broken,
ie. that there's a bug in the libmagick6 package?
Unless you used some internal symbols not ment to be used that would
be a libmagick6 bug.
My package currently Depends on libmagick6, sans version number. The
bug reporter suggested that I depend on a specific version - a thought
that had also occurred to me - but I'm not sure that it's the best
thing to do. What do you think?
Recompile against the new libmagick6 and see if that breaks with the
old one. If so then the libmagick6 shlibs info needs to require a
higher version.
Also the only way to fix this, prevent users system from breaking, is
for libmagick6 to conflict with older librmagick-ruby
versions. Otherwise partial updates would break the system.
I'm not sure how I'd inject a version-number into the libmagick6,
wayway, since it's generated by ${shlibs:Depends}. That's another
thing that confuses me: why does the generated dependency not include
version info?
If all libmagick6 versions are backward and forward compatible then no
version is required. From what you say there isn't even backward
compatibility, which usualy means upstream forgot to increase the
soversion.
Thanks in advice for your advice, tolerance, personal abuse, or
irrelevant anecdotes.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
On Wed, 27 Jul 2005, Frank Küster wrote: Nicolas Boullis [EMAIL PROTECTED] wrote: Oh, and I just thought there could be a workaround. I could make a new no-udev empty package that conflicts with udev, and then write Recommends: no-udev | udev (= 0.060-1). An elegant solution ;-) I guess this would behave as expected, but I think that having one more package only for this would be quite insane! Especially because others would pick up the idea... Can dpkg/apt/etc. be tweaked to automatically Provides: no-* ? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for python-xlib sponsor
Geert Stappers wrote: Some advice about requesting a sponsor: reread http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#rfs And for the interest level I guess that [EMAIL PROTECTED] is good place for also RFS. Thanks for the advise. Posting to debian-python is certainly a good idea; beyond that, I guess I just keep reposting the request every 6 months or so, until some sponsor finds some time, or until I get accepted as a debian-developer. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for python-xlib sponsor
Hi Martin, Martin v. Löwis wrote: I just adopted python-xlib, fixed the outstanding bugs, and put the revised package at While you're at it: - If you read Matthew's FAQ, you'll find that the copyright file isn't correct. - You're #249071 has 127.0.0.1 in the comment but localhost in the code. Why? - What's the current best practice of linking doc and library packages? - IIRC there was some discussion about dropping python 2.1/2.2 for etch. Can you check what the deal is? If you don't find a sponsor until I return from vacation+moving in two and a half or three weeks, you fix the first and I understand the others, I'll sign the papers. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
Hi, On Wed, Jul 27, 2005 at 09:57:35AM +0200, Thomas Viehmann wrote: Hi. Nicolas Boullis wrote: If there's currently no way to set up such things, it might be worth suggesting to add such a feature to next-generation .deb format. Don't you think so? To be honest, no. If you do a Recommends: udev (= ...), most people will just install the recommended udev and be fine. People who have reason to not like to use udev will just not. Most people won't want to make a decision, so it's of no use giving them the choice. Those who want to choose will read the README.Debian to see what's going on. For the others: Do venture a single recommondation. I have to disagree. For people who don't want to make a choice, tools like aptitude in its default configuration will install recommended packages. So it would install udev, even for someone who uses a 2.4 kernel... I'd rather set no recommendation at all, or conflict with old udev... Oh, and I just thought there could be a workaround. I could make a new no-udev empty package that conflicts with udev, and then write Recommends: no-udev | udev (= 0.060-1). I guess this would behave as expected, but I think that having one more package only for this would be quite insane! Let's not. Don't worry, I won't. Let's not bloat the packages file once again! ;-) Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
Hi, On Wed, Jul 27, 2005 at 11:22:44AM -0600, Bruce Sass wrote: On Wed, 27 Jul 2005, Frank Küster wrote: Nicolas Boullis [EMAIL PROTECTED] wrote: Oh, and I just thought there could be a workaround. I could make a new no-udev empty package that conflicts with udev, and then write Recommends: no-udev | udev (= 0.060-1). An elegant solution ;-) I guess this would behave as expected, but I think that having one more package only for this would be quite insane! Especially because others would pick up the idea... Can dpkg/apt/etc. be tweaked to automatically Provides: no-* ? If they were to be tweaked, I'd rather like them to understand something like Recommends: !udev || udeb (= 0.060-1) rather than give a special meaning to a prefix that would be perfectly legal in a package name. Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
On Wed, 2005-07-27 at 11:22 -0600, Bruce Sass wrote: On Wed, 27 Jul 2005, Frank Küster wrote: Nicolas Boullis [EMAIL PROTECTED] wrote: Oh, and I just thought there could be a workaround. I could make a new no-udev empty package that conflicts with udev, and then write Recommends: no-udev | udev (= 0.060-1). An elegant solution ;-) I guess this would behave as expected, but I think that having one more package only for this would be quite insane! Especially because others would pick up the idea... Can dpkg/apt/etc. be tweaked to automatically Provides: no-* ? Two methods, one is not tenable: (a) X conflicts with no-X implicitly (b) When Y depends on no-X, if Y is installed, no-X is synthesised and installed too if it doesn't exist, (and conflicting with X to prevent X being installed). The dummy installation is mandatory because here is the alternative, which is not tenable: When installing X, scan all installed packages to see if there is a dependency on no-X, if so there is a conflict. This is untenable because it requires scanning all packages in your local database, whereas installation of a package should only require looking up the listed dependencies. The reason a logical 'X isn't installed' does not work is that you could install Y, which depends on no X, and then just install X. Now Y is silently broken by a package that knows nothing about Y. The first technique works 'as if for each package X, either X or no-X was installed' and is the same as for the manual installation of a no-X package except it is handled by apt automatically and doesn't require any no-X package in the repository (but one must still be physically entered into your local database). The proof is by Shroedingers Cat: either X or no-X is always physically installed whenever you require a dependency, it is irrelevant whether or not X or no-X is installed otherwise, so the absence of one or the other is also irrelevant. -- John Skaller skaller at users dot sourceforge dot net signature.asc Description: This is a digitally signed message part
Re: Sponsor request for aspell-uz
On Wednesday 27 July 2005 08:27, Brian Nelson wrote: Almost there, just a few more things: * The urgency should be set to low, not high. Fixed. * Why have you deviated from the upstream version? I don't have a good reason for this. I just blindly followed aspell-en. This time deb and source versions are the same. * 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? * The 1_make.dpatch is obsolete now that you aren't using make at all. Fixed. * 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. Fixed. 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 The updated files are at http://www.uni-bremen.de/~kmashrab/aspell/deb/aspell-uz_0.04-0-1-deb.tar.bz2 Mashrab. -- Mashrab Kuvatov Ph.D student University of Bremen, IUP Home-page: www.sat.uni-bremen.de/members/mashrab PGP key: www.uni-bremen.de/~kmashrab/kmashrab.asc pgp1ikMtLtz8I.pgp Description: PGP signature
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: Can I simulate a weak conflict?
Hi, On Thu, Jul 28, 2005 at 07:12:16AM +1000, skaller wrote: Two methods, one is not tenable: (a) X conflicts with no-X implicitly (b) When Y depends on no-X, if Y is installed, no-X is synthesised and installed too if it doesn't exist, (and conflicting with X to prevent X being installed). The dummy installation is mandatory because here is the alternative, which is not tenable: When installing X, scan all installed packages to see if there is a dependency on no-X, if so there is a conflict. This is untenable because it requires scanning all packages in your local database, whereas installation of a package should only require looking up the listed dependencies. The reason a logical 'X isn't installed' does not work is that you could install Y, which depends on no X, and then just install X. Now Y is silently broken by a package that knows nothing about Y. As far as I know, such things already happen with conflicts: let foo conflict with bar. If you install foo first, everything is fine. Later, if you install bar, foo is broken by bar, while bar knows nothing about foo... Where's the difference? Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor request for aspell-uz
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) 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? If you want to update the info-aspell file before I upload, let me know. Otherwise it looks ready to go. I'll update it (if necessary) once I sort out the above questions. Mashrab. -- Mashrab Kuvatov Ph.D student University of Bremen, IUP Home-page: www.sat.uni-bremen.de/members/mashrab PGP key: www.uni-bremen.de/~kmashrab/kmashrab.asc pgp8mxPEg7LYd.pgp Description: PGP signature
Re: Can I simulate a weak conflict?
On Thu, 2005-07-28 at 01:01 +0200, Nicolas Boullis wrote: The reason a logical 'X isn't installed' does not work is that you could install Y, which depends on no X, and then just install X. Now Y is silently broken by a package that knows nothing about Y. As far as I know, such things already happen with conflicts: let foo conflict with bar. If you install foo first, everything is fine. Later, if you install bar, foo is broken by bar, while bar knows nothing about foo... Where's the difference? Ouch! I see. Being a math type person I tried to see if there were a proper extension. However I didn't go back to consider whether Debian itself was broken. The assumption here is that Conflicts is a symmetric relation: if A conflicts with B, then B conflicts with A. On that assumption, apt is broken and should be fixed the way I suggested: if there is a conflict which not currently true, a no-X package should be created by the package manager to prevent subsequent installation. So it looks like 'no-X' is not simply needed to satisfy an unusal request -- it is needed to repair a fundamental bug in Debian. -- John Skaller skaller at users dot sourceforge dot net signature.asc Description: This is a digitally signed message part
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]
