Re: RFS: hex-a-hop (updated package)
Hi, I'm taking a look at it, and see that Sam is in the Uploaders. Should I upload the package (if it's good), or does he normally do that? Thanks, Bas On Mon, Sep 10, 2007 at 01:15:04AM +0200, Jens Seidel wrote: Dear mentors, I am looking for a sponsor for the new version 0.0.20070315-5 of my package hex-a-hop. It builds these binary packages: hex-a-hop - puzzle game based on hexagonal tiles The package appears to be lintian clean. The upload would fix these bugs: 438857, 440377, 441040 It mainly adds supports for big endian systems. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/h/hex-a-hop - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/h/hex-a-hop/hex-a-hop_0.0.20070315-5.dsc I would be glad if someone uploaded this package for me. Kind regards Jens Seidel ___ Pkg-games-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: RFS: hex-a-hop (updated package)
2007/9/10, Bas Wijnen [EMAIL PROTECTED]: Hi, I'm taking a look at it, and see that Sam is in the Uploaders. Should I upload the package (if it's good), or does he normally do that? Thanks, Bas Please upload it, Bas :) PS: BTW, It's better to use [EMAIL PROTECTED] instead of [EMAIL PROTECTED] for this kind of stuff, not everyone is subscribed to the latter. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hex-a-hop (updated package)
Hello again, I have some questions before uploading the package: - You have specified Priority: extra. According to policy, This contains all packages that conflict with others with required, important, standard or optional priorities, or are only likely to be useful if you already know what they are or have specialized requirements. I would expect this to be optional. Is there a reason that it isn't? - debian/copyright is almost complete. It says: On Debian systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'., which isn't very clear about the version. I suggest you use something like what was suggested on the games list by Eddy. It also says The Debian packaging is (C) 2007, Miriam Ruiz [EMAIL PROTECTED] and is licensed under the GPL, see above.. You may want to add your name to that (AFAIK you did significant parts as well). And this is a GPL without version claim, which according to the GPL means any version is acceptable. I think this is not what is intended. Also, it is said that (C) has no legal meaning, you should use the word copyright instead. I don't think any judge would consider this unclear, but better safe than sorry. :-) - The manual page mentions the license. This is not required, but if you do it, it would be good to point to /usr/share/common-licenses for the complete text. - Lintian gives a list of warnings for the translated manpages. They're not compressed with gzip -9, and some of them have errors. These should be fixed. For the compression, you should add -9 to the gzip command in debian/i18n/Makefile. I didn't look at the other problems, but lintian -i gives some hints. On Mon, Sep 10, 2007 at 01:15:04AM +0200, Jens Seidel wrote: The package appears to be lintian clean. You may be using lintian from stable? The one from sid gives the errors, anyway. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: RFS: hex-a-hop (updated package)
Hi Bas, On Mon, Sep 10, 2007 at 09:55:31AM +0200, Bas Wijnen wrote: I have some questions before uploading the package: first of all thanks for your review. - You have specified Priority: extra. According to policy, This contains all packages that conflict with others with required, important, standard or optional priorities, or are only likely to be useful if you already know what they are or have specialized requirements. I would expect this to be optional. Is there a reason that it isn't? Oops, I didn't changed this. Sam, you are probably the one who is responsible. Can you explain this? (Would it be OK for me to change this (after a carefully analysis this night) or do you feel responsible for this alone?) To be honest I mainly worked on i18n and some code cleanup/bug fixes. - debian/copyright is almost complete. It says: On Debian systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'., which isn't very clear about the version. I suggest you use something like what was suggested on the games list by Eddy. OK. It also says The Debian packaging is (C) 2007, Miriam Ruiz [EMAIL PROTECTED] and is licensed under the GPL, see above.. You may want to add your name to that (AFAIK you did Right, will do so. Did so already for individual patches. significant parts as well). And this is a GPL without version Which is not forbidden as was told to me once I asked ... claim, which according to the GPL means any version is acceptable. I think this is not what is intended. Also, it is said that (C) has I don't know what was intended. Miriam, can you please change this? (I will agree to any license change as long as only a version number is added such as v2 or later, ...) I changed the existing package and had to use the given license for modifications/additions. no legal meaning, you should use the word copyright instead. I don't think any judge would consider this unclear, but better safe than sorry. :-) Right. Will do so in the program as well to clarify it. - The manual page mentions the license. This is not required, but if you do it, it would be good to point to /usr/share/common-licenses for the complete text. OK. - Lintian gives a list of warnings for the translated manpages. They're not compressed with gzip -9, and some of them have errors. These Hm, yes, that's my error. dh_installman will not do the job for currently unsupported languages so I do no longer use it. All man pages lintian complain about are OK, just currently not supported by man-db and I adapted the installation so that they will supported later by default once man-db is upgraded. Will try to create a override file. should be fixed. For the compression, you should add -9 to the gzip command in debian/i18n/Makefile. I didn't look at the other problems, but lintian -i gives some hints. On Mon, Sep 10, 2007 at 01:15:04AM +0200, Jens Seidel wrote: The package appears to be lintian clean. You may be using lintian from stable? The one from sid gives the errors, anyway. Right, I really have to use the one from Sid! To be honest I fixed all issues I was aware of and thought also that mentors.debian.net (which created this mail template) does another lintian check. This is nevertheless no excuse ... Thanks Bas, I will adress all these issues, Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hex-a-hop (updated package)
2007/9/10, Jens Seidel [EMAIL PROTECTED]: Hi Bas, On Mon, Sep 10, 2007 at 09:55:31AM +0200, Bas Wijnen wrote: I have some questions before uploading the package: first of all thanks for your review. - You have specified Priority: extra. According to policy, This contains all packages that conflict with others with required, important, standard or optional priorities, or are only likely to be useful if you already know what they are or have specialized requirements. I would expect this to be optional. Is there a reason that it isn't? Oops, I didn't changed this. Sam, you are probably the one who is responsible. Can you explain this? (Would it be OK for me to change this (after a carefully analysis this night) or do you feel responsible for this alone?) In fact the main responsible for the package until now was me. I convinced Sam to be added to Uploaders because, having contributed with a patch, he knew enough of the package to understand it. Go ahead and change it, no problem :) Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: xulrunner-l10n
Dear mentors, I am looking for a sponsor for my package xulrunner-l10n. * Package name: xulrunner-l10n Version : 1.8.1-1 Upstream Author : Mozilla Project and Mozilla Localization Projects. * URL : http://www.mozilla.org/projects/l10n/ * License : GPL LGPL MPL (tri-licence) Section : devel It builds these binary packages: xulrunner-l10n-af - Afrikaans language package for xulrunner xulrunner-l10n-all - All language packages for xulrunner (meta) xulrunner-l10n-ar - Arabic language package for xulrunner xulrunner-l10n-be - Belarusian language package for xulrunner xulrunner-l10n-bg - Bulgarian language package for xulrunner xulrunner-l10n-ca - Catalan language package for xulrunner xulrunner-l10n-cs - Czech language package for xulrunner xulrunner-l10n-da - Danish language package for xulrunner xulrunner-l10n-de - German language package for xulrunner xulrunner-l10n-el - Greek language package for xulrunner xulrunner-l10n-en-gb - English (Great Britain) language package for xulrunner xulrunner-l10n-es-ar - Spanish (Argentina) language package for xulrunner xulrunner-l10n-es-es - Spanish (Spain) language package for xulrunner xulrunner-l10n-eu - Basque language package for xulrunner xulrunner-l10n-fi - Finnish language package for xulrunner xulrunner-l10n-fr - French language package for xulrunner xulrunner-l10n-fy-nl - Frisian language package for xulrunner xulrunner-l10n-ga-ie - Irish (Ireland) language package for xulrunner xulrunner-l10n-gu-in - Gujarati (India) language package for xulrunner xulrunner-l10n-he - Hebrew language package for xulrunner xulrunner-l10n-hu - Hungarian language package for xulrunner xulrunner-l10n-it - Italian language package for xulrunner xulrunner-l10n-ja - Japanese language package for xulrunner xulrunner-l10n-ka - Georgian language package for xulrunner xulrunner-l10n-ko - Korean language package for xulrunner xulrunner-l10n-ku - Kurdish language package for xulrunner xulrunner-l10n-lt - Lithuanian language package for xulrunner xulrunner-l10n-mk - Macedonian language package for xulrunner xulrunner-l10n-mn - Mongolian language package for xulrunner xulrunner-l10n-nb-no - Bokmaal (Norway) language package for xulrunner xulrunner-l10n-nl - Dutch language package for xulrunner xulrunner-l10n-nn-no - Nynorsk (Norway) language package for xulrunner xulrunner-l10n-pa-in - Punjabi (India) language package for xulrunner xulrunner-l10n-pl - Polish language package for xulrunner xulrunner-l10n-pt-br - Portuguese (Brazil) language package for xulrunner xulrunner-l10n-pt-pt - Portuguese (Portugal) language package for xulrunner xulrunner-l10n-ro - Romanian language package for xulrunner xulrunner-l10n-ru - Russian language package for xulrunner xulrunner-l10n-sk - Slovak language package for xulrunner xulrunner-l10n-sl - Slovenian language package for xulrunner xulrunner-l10n-sv-se - Swedish (Sweden) language package for xulrunner xulrunner-l10n-tr - Turkish language package for xulrunner xulrunner-l10n-zh-cn - Chinese (China) language package for xulrunner xulrunner-l10n-zh-tw - Chinese (Taiwan) language package for xulrunner The package appears to be lintian clean. The upload would fix these bugs: 440938 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xulrunner-l10n - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/x/xulrunner-l10n/xulrunner-l10n_1.8.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards arno renevier signature.asc Description: Digital signature
Are soname bumps required when library upgrades break compatability?
Might seem like a silly question to most people. But is it required to bump the soname of a library when it breaks ABI compatability with an older version? I always thought that is was, but I can't find anything in debian-policy that says that it is required. In fact, it isn't even suggested. -Brandon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Are soname bumps required when library upgrades break compatability?
Brandon [EMAIL PROTECTED] (10/09/2007): Might seem like a silly question to most people. But is it required to bump the soname of a library when it breaks ABI compatability with an older version? I always thought that is was, but I can't find anything in debian-policy that says that it is required. In fact, it isn't even suggested. You may want to read libpkg-guide. Cheers, -- Cyril Brulebois pgpptCn5I8Cip.pgp Description: PGP signature
Re: Are soname bumps required when library upgrades break compatability?
Brandon [EMAIL PROTECTED] writes: Might seem like a silly question to most people. But is it required to bump the soname of a library when it breaks ABI compatability with an older version? I always thought that is was, but I can't find anything in debian-policy that says that it is required. In fact, it isn't even suggested. -Brandon You break every package that depends on the libary. Should be enough reason not to do it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Sat, Sep 08, 2007 at 08:24:19PM +0200, Jan Beyer wrote: Justin Pryzby schrieb am 07.09.2007 17:46 Uhr: On Fri, Sep 07, 2007 at 05:20:56PM +0200, Jan Beyer wrote: On 09/07/2007 01:55 PM, Justin Pryzby wrote : On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: And finally there is a duplicate depends of gwyddion on libgwyddion2, one added by the debhelper scripts and one by me - should I override this, or take away my hand-written dependency? I think you should drop the manually-added one since the automatic one will always be working with ELF dependency output. Should I force a versioned automatic dependency via dh_makeshlibs -V or dh_makeshlibs -V 'libgwyddion2 (=2.8)'? I think you have to bump the shlibs version whenever upstream adds a symbol. Unless you can show (by reading the diff) that a new upstream *doesn't* do this (or make incompatible changes), it's prolly safe to increment this at every new upstream. Otherwise an object compiled against a recent libgwyddion2 with new symbol would end up in a package with Depends: libgwyddion2 (=X) where version X doesn't actually provide the symbol, and an app will crash whenever the symbol lookup is attempted. Then I'll use libxxxy-z (=a.b), which should be inserted by the -V option. -V should be using =. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
On Wed, Aug 15, 2007 at 12:50:53AM +0200, Adam Borowski wrote: (Colin, CC-ing you as I'm not sure if you're of aware of this long thread, and both man-db and groff are your territory...) I wasn't aware of it, thanks. Sorry for my delay in responding. I read through the thread and there are a number of things that I might have responded to individually had I been following it at the time, but now it's probably less confusing if I just reply to this. On Tue, Aug 14, 2007 at 05:25:27PM +0200, Nicolas François wrote: I proposed Colin to work on it during Debconf, but still had no time to do it. Could you tell us if anything was born? I think the best summary of the current status and planning is this policy proposal, on which I'd very much appreciate further comments, since people involved in this thread seem to have a good grip on the issues: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440420 David Given is pretty much spot-on in: http://lists.debian.org/debian-mentors/2007/08/msg00308.html I had hoped to talk about this at Debconf, but unfortunately the software just wasn't ready yet. I tested a CVS snapshot of groff On the other hand, I investigated what the headgear guys produced. I just compiled the package on Debian instead of using a real Red Hat system, so due to misconfiguration things may be better than I'm reporting here. I do need to find the stomach to look at upgrading groff again, but it's not *necessary* (or indeed sufficient) for this. The most important bit to start with is really the changes to man-db. The downside to not upgrading groff, as you note, is that you'll only be able to actually use those codepoints which appear in the legacy character set corresponding to the language you're using (e.g. German manual pages will only be able to use Unicode codepoints that are convertible to ISO-8859-1). This is annoying and I fully agree that it's a bug, but it's not urgent, and I want to get over the first phase of the transition before worrying about that. (Except for this issue, I could display nicely French, English, Japanese and Vietnamese UTF-8 manpages) Cool, and what for Cyrillic, Arabic, Indic, etc? Cyrillic works fine right now, and has done for years, via the ascii8 device in Debian groff. Arabic and Indic will probably still be a bit screwed. The CVS version introduced a -K option to specify the encoding of the input file to groff. This should help to plan a transition for UTF-8 manpages by using this option in man-db. Wouldn't it be easier and less prone to breakages if we simply hard-coded the encoding as UTF-8 and do all the processing in man-db? A versioned dependency or conflict would be enough, and the code would be much simpler. Slowly moving files from man/ to man.UTF-8/ while still supporting the legacy encoding in man/ would be a simple transition plan. I'm afraid that's not an option. So far I found 807 UTF-8 man pages, and only 21 of them were marked as such. But fear not, it appears I've got a solution working, just let me download the rest of archive to check it. Compatibility's the thing here. You're right that there are a lot of pages in UTF-8 and not marked as such (there are 1308 or so in manpages-es alone), but that's a relatively recent phenomenon. Historically, and even up until a year or two ago, pages installed in /usr/share/man/$LL/ had a fixed encoding which man-db could rely on (basically ISO-8859-1 with a few exceptions which were handled specially by man-db, the ones under the MULTIBYTE_GROFF define). Those that have moved to UTF-8 without changing directory have clearly not been tested on Debian since they don't work, and so I have no compunction about codifying that breakage; but I won't break the pages that were installed using the proper encoding and always worked to date. I'm also not really keen on requiring everyone who installs a UTF-8 manual page to declare a versioned conflict on man-db; that's a lot of arcs in the dependency graph. By contrast, moving to /usr/share/man/fr.UTF-8/ etc. for UTF-8 manual pages is easy to describe and understand, and it doesn't break compatibility. The worst case is that the manual page goes missing until you upgrade man-db, but you don't get misencoded garbage, and upgrading man-db first means that everything keeps working at least as well as before. Once we have a better version of groff, we can just tweak man-db's iconv pipeline handling and once again it will keep on working at least as well as before. Due to Red Hat and probably other dists using UTF-8 already, plenty of man pages are in UTF-8 when our groff still can't parse them. Having gone through 2/3 of the archive, I got 807 such pages so far. And every single one displays lovely ä or similar instead. That's 9% of all mans with non-ASCII characters in the corpus. These are bugs in the packages in question, and it would be straightforward for the maintainers to correct
Re: Are soname bumps required when library upgrades break compatability?
On Mon, 10 Sep 2007 07:59:50 -0700 Brandon [EMAIL PROTECTED] wrote: Might seem like a silly question to most people. But is it required to bump the soname of a library when it breaks ABI compatability with an older version? Yes. You (in association with upstream) also need to decide whether to support multiple SONAME's at the same time - i.e. whether to have libfoo3-dev and libfoo2-dev (double maintenance) or just libfoo-dev which will force a transition due to FTBFS RC bugs in Debian and similar problems in other distributions. (Such transitions can be painful and require lots of effort from all parties.) i.e. do you want small amounts of ongoing pain (libfoo2-dev) or large amounts of intermittent pain (libfoo-dev). Once libfoo2-dev is replaced by libfoo3-dev, libfoo2 will hang around for a very long time - take a look at libgtk1 - and this also needs to be taken into account. I always thought that is was, but I can't find anything in debian-policy that says that it is required. In fact, it isn't even suggested. That would be because SONAME's are primarily an upstream issue. If upstream do not understand library versioning, it is pointless trying to enforce a SONAME in Debian (and therefore pointless packaging the library) as you'll end up with libfoo36 - incrementing the SONAME at every minor release - by the time you just get to v1.0.4 or similar. There should never be a direct relationship between the version string and the SONAME. SONAME's should last a lot longer than any version element. http://www.gnu.org/software/libtool/manual.html#Updating-version-info http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html Equally, trying to change a SONAME within Debian when upstream DO understand libtool versioning becomes a long and frustrating pattern of broken updates and multiple re-patching of the sources. Debian Policy concentrates on ensuring that the SONAME created by upstream is correctly handled in Debian. Debian Policy does not have to mandate every aspect of every upstream decision - there are some things (like SONAME's) that simply need to be done properly before the code even gets into Debian (or any other distribution). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpHirIMhXa5q.pgp Description: PGP signature
Re: Man pages and UTF-8
On Mon, Sep 10, 2007 at 07:03:57PM +0100, Colin Watson wrote:
On Wed, Aug 15, 2007 at 12:50:53AM +0200, Adam Borowski wrote:
(Colin, CC-ing you as I'm not sure if you're of aware of this long thread,
and both man-db and groff are your territory...)
I wasn't aware of it, thanks. Sorry for my delay in responding.
Woh, it's great to hear from you. I'm afraid I've been lazy too, you should
be shown ready patches instead of hearing that's mostly working...
On Tue, Aug 14, 2007 at 05:25:27PM +0200, Nicolas François wrote:
I proposed Colin to work on it during Debconf, but still had no time to do
it.
Could you tell us if anything was born?
I think the best summary of the current status and planning is this
policy proposal, on which I'd very much appreciate further comments,
since people involved in this thread seem to have a good grip on the
issues:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440420
I would object quite strongly to that solution, for two reasons:
1. it leaves us with ugly manpage names until the heat death of the universe
2. it's not compatible with the .rpm world, so every single manpage that
sneaks through without being changed will be misencoded
David Given is pretty much spot-on in:
http://lists.debian.org/debian-mentors/2007/08/msg00308.html
It's a working implementation of the above. Too bad, it's an
update-the-world transition :(
I tested a CVS snapshot of groff
On the other hand, I investigated what the headgear guys produced. I just
compiled the package on Debian instead of using a real Red Hat system, so
due to misconfiguration things may be better than I'm reporting here.
I do need to find the stomach to look at upgrading groff again, but it's
not *necessary* (or indeed sufficient) for this. The most important bit
to start with is really the changes to man-db.
We do need to change them both at once. Red Hat did it in a lockstep, after
a thought it may be a better idea to do minimal changes to groff to have its
forward-compatible with future groffs.
The downside to not upgrading groff, as you note, is that you'll only be
able to actually use those codepoints which appear in the legacy
character set corresponding to the language you're using (e.g. German
manual pages will only be able to use Unicode codepoints that are
convertible to ISO-8859-1). This is annoying and I fully agree that it's
a bug, but it's not urgent, and I want to get over the first phase of
the transition before worrying about that.
The meat of Red Hat changes to groff is:
ISO-8859-1/nippon - LC_CTYPE
and then man-db converts everything into the current locale charset. My own
tree instead hardcodes it to UTF-8 under the hood; now it seems to me that
it would probably be best to allow groff1.9-ish -K charset, so man-db
would be able to say -K utf-8 while other users of groff would be
unaffected (unlike Red Hat).
Slowly moving files from man/ to man.UTF-8/ while still supporting the
legacy encoding in man/ would be a simple transition plan.
I'm afraid that's not an option. So far I found 807 UTF-8 man pages, and
only 21 of them were marked as such. But fear not, it appears I've got a
solution working, just let me download the rest of archive to check it.
Compatibility's the thing here. You're right that there are a lot of
pages in UTF-8 and not marked as such (there are 1308 or so in
manpages-es alone), but that's a relatively recent phenomenon.
Historically, and even up until a year or two ago, pages installed in
/usr/share/man/$LL/ had a fixed encoding which man-db could rely on
(basically ISO-8859-1 with a few exceptions which were handled specially
by man-db, the ones under the MULTIBYTE_GROFF define). Those that have
moved to UTF-8 without changing directory have clearly not been tested
on Debian since they don't work, and so I have no compunction about
codifying that breakage;
Except, it's the cleanest long-term way, and it appears it _could_ be
codified without:
but I won't break the pages that were installed using the proper encoding
and always worked to date.
I went through the whole archive, and it appears there is not a single
source man page which appears to be well-formed UTF-8 while using a legacy
charset, albeit we got several which are encoded twice, and thus broken in
any charset.
The broken ones are:
es/man2/mmap.2.gz
es/man7/iso_8859-2.7.gz
man8/ipsec__updown.8.gz
man8/ipsec_auto.8.gz
man8/ipsec_barf.8.gz
... and most of ipsec_*
it/man1/snownews.1.gz
man1/gnome-keyboard-layout.1.gz
man3/Time::Seconds.3pm.gz
My pipeline is a hack, but it transparently supports every manpage except
the several broken ones. If we could have UTF-8 man in the policy, we would
also get a guarantee that no false positive appears in the future.
Please take a look at http://angband.pl/deb/man/mans.enc; it lists the
encodings of all man pages in arch={i386,all} packages. The first field is:
how to patch a patch
Hi, There is a list of softwares already debian packaged. The packager has applied a patch on them. I need to modify again the patched part. So, I need to patch the patch. I guess in real world I wont patch the patch, but what is the easy way to do so? I know a bit using dpatch (or is there a replacement for it? I dont remember) but then,... Thank you for your indications. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hex-a-hop (updated package)
Hi Bas, I fixed (nearly) all problems and uploaded a new package. On Mon, Sep 10, 2007 at 09:55:31AM +0200, Bas Wijnen wrote: I have some questions before uploading the package: - You have specified Priority: extra. According to policy, This contains all packages that conflict with others with required, important, standard or optional priorities, or are only likely to be useful if you already know what they are or have specialized requirements. I would expect this to be optional. Is there a reason that it isn't? - debian/copyright is almost complete. It says: On Debian systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'., which isn't very clear about the version. I suggest you use something like what was suggested on the games list by Eddy. It also says The Debian packaging is (C) 2007, Miriam Ruiz [EMAIL PROTECTED] and is licensed under the GPL, see above.. You may want to add your name to that (AFAIK you did significant parts as well). And this is a GPL without version claim, which according to the GPL means any version is acceptable. I It's still GPL without version. I need the permission of Miriam and maybe others before I can change it. Nevertheless I consider it not as critical. think this is not what is intended. Also, it is said that (C) has no legal meaning, you should use the word copyright instead. I don't think any judge would consider this unclear, but better safe than sorry. :-) - The manual page mentions the license. This is not required, but if you do it, it would be good to point to /usr/share/common-licenses for the complete text. Not done. This would unfuzzy all translations. This is not necessary and would be Debian specific. - Lintian gives a list of warnings for the translated manpages. They're not compressed with gzip -9, and some of them have errors. These should be fixed. For the compression, you should add -9 to the gzip command in debian/i18n/Makefile. I didn't look at the other problems, but lintian -i gives some hints. That's now properly fixed. On Mon, Sep 10, 2007 at 01:15:04AM +0200, Jens Seidel wrote: The package appears to be lintian clean. You may be using lintian from stable? The one from sid gives the errors, anyway. I called lintian on the .dsc file instead the .changes file :-) PS: Sorry Bas, I did not yet fixed your hex-a-hop bug report ... Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to patch a patch
On Tue, Sep 11, 2007 at 12:25:52AM +0200, Mihamina (R12y) Rakotomandimby wrote: There is a list of softwares already debian packaged. The packager has applied a patch on them. I need to modify again the patched part. So, I need to patch the patch. I guess in real world I wont patch the patch, but what is the easy way to do so? I know a bit using dpatch (or is there a replacement for it? I dont remember) but then,... Thank you for your indications. Can you tell us which package it is, and exactly what you want to do? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC: docbook-xsl-saxon (Java extensions for use with DocBook XML stylesheets (Saxon))
x-post to debian-java, debian-mentors and pkg-java-maintainers Hi, I'm building docbook-xsl-saxon, a Java package, that provides docbook-xsl related extensions. For those interested in the packaging files, see http://svn.debian.org/wsvn/debian-xml-sgml/packages/docbook-xsl-saxon/trunk/debian/?rev=0sc=0 I receive these informational objects from lintian: I: docbook-xsl-saxon source: build-depends-without-arch-dep ant I: docbook-xsl-saxon source: build-depends-without-arch-dep java-gcj-compat-dev Now I'm unsure, if lintian is right here. The clean target is defined in an ant makefile (build.xml). So ant and java are both used in the clean target. To my understanding of Build-Depends and Build-Depends-Indep, I have to list at least ant in Build-Depends, not in Build-Depends-Indep. I'm not sure about java-gcj-compat-dev, because java-gcj-compat provides the java binary. The package builds fine with kaffe and gcj-java-compat-dev. BTW: Do both use ecj to compile the source? If yes, where is the difference, if I use gcj-java-compat-dev or kaffe as build-dependency? I'm sorry for the questions, but this is my first Java package and I'm trying to learn more about Java packaging for Debian. Please split answers and send them to the right list if you want. I'm subscribed to all 3 lists, this posting is sent to. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: kopete-otr 0.6-1
Dear DD, I am looking for a sponsor for my package kopete-otr. * Package name : kopete-otr Version : 0.6-1 * URL : http://kopete-otr.follefuder.org/ * License : GPL Section : net It builds these binary packages: kopete-otr - Off-the-Record Messaging plugin for kopete The package is lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/kopete-otr - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/kopete-otr/kopete-otr_0.6-1.dsc I would be glad if someone uploaded this package for me. Kind regards Francesco Cecconi -- Francesco Cecconi ' |BrAnD| ' [EMAIL PROTECTED] GPG Key ID: 11F6E468 | Debian pkg Maintainer Key fingerprint = A45A 59F0 15F8 BF5E 41AC 8478 D931 DAA2 11F6 E468 signature.asc Description: This is a digitally signed message part.
Re: how to patch a patch
Hi, * Mihamina (R12y) Rakotomandimby [EMAIL PROTECTED] [2007-09-11 02:28]: There is a list of softwares already debian packaged. The packager has applied a patch on them. I need to modify again the patched part. So, I need to patch the patch. I guess in real world I wont patch the patch, but what is the easy way to do so? I know a bit using dpatch (or is there a replacement for it? I dont remember) but then,... Thank you for your indications. Is the original patch also using dpatch? If yes you can simply use dpatch-edit-patch file to get into a dpatch environment, edit the files and dpatch will update the patch file for you. Cheers Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgpTfm8cMug0d.pgp Description: PGP signature
Re: Are soname bumps required when library upgrades break compatability?
Soname bumps are upstream business... Yeah. That makes sense. But sometimes upstream doesn't do it. I'm asking mostly for bug reporting. I don't maintain any libraries. When I file a bug report against a library for breaking ABI compatability without bumping the soname, do I report it as serious? Or just important? What would the justification be for reporting as serious if there is no policy regarding it? Debian Policy does not have to mandate every aspect of every upstream decision - there are some things (like SONAME's) that simply need to be done properly before the code even gets into Debian (or any other distribution). I agree with that, at least somewhat. The problem is that some excellent packages would not be able to make it into debian at all, because they depend on a volatile library. -Brandon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Are soname bumps required when library upgrades break compatability?
Brandon [EMAIL PROTECTED] (10/09/2007): I'm asking mostly for bug reporting. I don't maintain any libraries. When I file a bug report against a library for breaking ABI compatability without bumping the soname, do I report it as serious? Or just important? What would the justification be for reporting as serious if there is no policy regarding it? Yes, serious at least, but I'd even say “grave”: “renders package unusable” (by its dependencies) in reportbug. I agree with that, at least somewhat. The problem is that some excellent packages would not be able to make it into debian at all, because they depend on a volatile library. You aren't speaking about the ffmpeg case, are you? Cheers, -- Cyril Brulebois pgpuDj9nemsmT.pgp Description: PGP signature
Re: RFS: kopete-otr 0.6-1
On 10/09/2007, Francesco Cecconi [EMAIL PROTECTED] wrote: Dear DD, I am looking for a sponsor for my package kopete-otr. Maybe you should send an ITP first and add a (Closes: #nn) to the debian/changelog I would be glad if someone uploaded this package for me. Kind regards Francesco Cecconi -- Francesco Cecconi ' |BrAnD| ' [EMAIL PROTECTED] GPG Key ID: 11F6E468 | Debian pkg Maintainer Key fingerprint = A45A 59F0 15F8 BF5E 41AC 8478 D931 DAA2 11F6 E468 -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packaging sqliteman
Neil Williams wrote: On Sat, 08 Sep 2007 23:23:13 +0100 David Claughton [EMAIL PROTECTED] wrote: Hi, I've created the beginnings of a package for sqliteman (upstream site is http://sqliteman.com). It's a GUI frontend for a well established and generally not that buggy backend - it doesn't make a lot of sense (to me at least) to package it in the current state. Yes, I certainly wouldn't want a user to get a false bad impression of sqlite through the use of this program - an aspect I hadn't considered. The problem I have is this program, currently seems to have a few fairly major bugs (for example it is impossible to run insert ... values statements - upstream bug #17). That is such a major omission and such a small amount of work. SQLite is easy (comparatively) and there are numerous packages out there inserting new data all the time. A frontend that cannot support INSERT is pre-alpha IMHO. (I've written one and I maintain almost a dozen others.) After all, commands to SQLite are passed as SQL statements - plain text. The website does come across as more hype than substance. I picked sqliteman purely because I needed/wanted a GUI frontend (there isn't a similar program already in Debian AFAICT) and this was one of only a handful I was able to find on Google... Perhaps I would be better to just go back and look a little harder! ;-) What's my best course of action - ITP it now and work on completing the package despite its current buggy state, or hold fire until the more serious bugs have been resolved upstream? There's no problem keeping an ITP open for ages (I've got one v.old ITP due to upstream bugs and lack of development time but that's my own upstream project so sometimes that changes the way that people view such an old ITP.) I think, on reflection, I'll hold off for now, and keep an eye on progress upstream, while also looking for an alternative GUI that may be in better shape. I would still like to see such an application in Debian, as well as finding a usable program for my own use, of course :-) Thanks for your advice, David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to patch a patch
Mihamina (R12y) Rakotomandimby wrote:
Hi,
There is a list of softwares already debian packaged.
The packager has applied a patch on them.
I need to modify again the patched part.
So, I need to patch the patch.
I guess in real world I wont patch the patch, but what is the easy way
to do so?
I know a bit using dpatch (or is there a replacement for it? I dont
remember) but then,...
Thank you for your indications.
It seems the package is using dpatch. If so, do the following:
- get the source
- copy it (pkg-vers and pkg-vers.orig)
- cd into pkg-vers
- dpatch-edit-patch patchname
- do your thing
- exit dpatch
- cd .. ; diff -u pkg-vers{.orig,}/debian/patches/patchname.dpatch
Another option is to apply the patch in both directories, do your change in
one of them, and then diff.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian .packlist warning and debian/rules modification
Justin Pryzby wrote: Hi, The debhelper tools (dh_install) used to use debian/tmp but now (depending on DH_COMPAT) use debian/$package. So this is a small-ish lintian bug. But debian/tmp also happens to be where dh_make defaults to install (make DESTDIR=$(CURDIR)/debian/tmp), and then copy/move files over debian/$package with dh_install. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to patch a patch
Mihamina (R12y) Rakotomandimby [EMAIL PROTECTED] writes: I need to modify again the patched part. So, I need to patch the patch. I guess in real world I wont patch the patch, but what is the easy way to do so? Allow the patch to proceed, and then simply apply another subsequent patch that achieves the result you want. -- \ I bought a self learning record to learn Spanish. I turned it | `\on and went to sleep; the record got stuck. The next day I | _o__)could only stutter in Spanish. -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Man pages and UTF-8
Colin Watson [EMAIL PROTECTED] writes: David Given is pretty much spot-on in: http://lists.debian.org/debian-mentors/2007/08/msg00308.html Ironically, that message (at least, the one presented at that archive page) doesn't display its non-ASCII characters properly in a UTF-8 locale. -- \ Pinky, are you pondering what I'm pondering? I think so, | `\ Brain, but if they called them 'Sad Meals', kids wouldn't buy | _o__) them! -- _Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
