RFS: hashalot (updated)
Hi!
I seem to have issues catching the previous sponsor, for some time already.
There's an updated package at:
dget http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-5.dsc
Issues fixed:
* Buffer overflow on RMD160:
It will cause only a crash instead of executing arbitrary code, and
considering the typical usage this is nearly always harmless. Yet, in
non-typical uses even wrong output can be pretty bad for a hash.
A nearly-identical fix is already in Ubuntu (they move some functions
around without an apparent reason).
* Lots of packaging cruft:
Due to "debian/rules clean" not working correctly, prior Debian diffs
included files like config.h, .deps/*, stamp-*, Makefile.
Also, config.{sub,guess} has been yanked away as per the current packaging
practices.
* Debhelper 5, standards 3.7.3, etc.
* Vcs-Svn and Vcs-Browser.
As the diff is small (except for file deletions), this shouldn't take much
of your time. If someone could upload this, that would be cool.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: tcng (updated) (1 RC, 3 non-RC bugs)
Hi! I seem to have issues getting hold on the previous sponsor (busy/bus/SA ?), and there's a number of bugs that could use uploading. The updated package can be found at: dget http://mentors.debian.net/debian/pool/main/t/tcng/tcng_10b-2.dsc The issues fixed are: * FTBFS on amd64: It appears that new glibc is more picky about the order of #includes (on amd64 only). One of header files defines __KERNEL_STRICT_NAMES which changes the behaviour of other parts -- but only if it's seen soon enough. * TeX transition: Build-depending only on texlive-latex-base cuts down half a GB of junk. * Incorrectly cleared ingress rules: A functionality bug. * A manpage: Instead of a stub which says "see this 180KB text file", I took an excerpt from said file which describes command-line arguments. * Wrapper madness: The upstream package looks for data in whatever directory the package was _built_ unless it's overridden with an env var. The /usr/bin/ binary is: #!/bin/sh TCNG_TOPDIR=/usr/lib/tcng exec /usr/lib/tcng/bin/tcc "$@" which seems not robust enough. I changed the build system to set up the paths at configure time. * Vcs-Svn and Vcs-Browser Speaking of the last item, step-by-step diffs are linked from http://angband.pl/viewvc/deb/tcng/trunk/?view=log It would be cool if someone could upload the package. You don't want Debian mail servers to collapse under the bulk of angry mails about outstanding RC bugs, do you? -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Thu, Jan 24, 2008 at 09:25:05AM +0100, Luca Bruno wrote: > Adam Borowski scrisse: > > > As the diff is small (except for file deletions), this shouldn't take > > much of your time. If someone could upload this, that would be cool. > > I've seen that you've already found Kapil available, fine :). > Anyway your gzipped diff is 70K (almost as big as the original > tarball), which seems to clash with your previous statement. > It also seems to contain a heavy autotool-ization. A diff from the previous packages, I mean. I wasn't clear enough, sorry. As in "debdiff hashalot_0.3-4.dsc hashalot_0.3-5.dsc". Matthias Urlich enabled AM_MAINTAINER_MODE some time ago -- this stops _new_ unrequested autotoolization changes, but is a reautotooling by itself. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Thu, Jan 24, 2008 at 09:10:11AM +0530, Kapil Hari Paranjape wrote: > Hello, > > Some quick comments. > > On Thu, 24 Jan 2008, Adam Borowski wrote: > > * Buffer overflow on RMD160: > > It will cause only a crash instead of executing arbitrary code, and > > considering the typical usage this is nearly always harmless. Yet, in > > non-typical uses even wrong output can be pretty bad for a hash. > > > > A nearly-identical fix is already in Ubuntu (they move some functions > > around without an apparent reason). > > Has this patch been submitted upstream? Yes, albeit only a week ago. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Thu, Jan 24, 2008 at 04:44:48PM +0530, Kapil Hari Paranjape wrote: > On Thu, 24 Jan 2008, Adam Borowski wrote: > > On Thu, Jan 24, 2008 at 09:25:05AM +0100, Luca Bruno wrote: > > > Anyway your gzipped diff is 70K (almost as big as the original > > > tarball), which seems to clash with your previous statement. > > > Matthias Urlich enabled AM_MAINTAINER_MODE some time ago -- this stops _new_ > > unrequested autotoolization changes, but is a reautotooling by itself. > > It is indeed true that > diff -ur hashalot-0.3-[45] | wc -c > returns just about 5K. And these are the changes documented in the > changelog. Actually, it seems that reverting to upstream autotooling doesn't break anything (except obviously being unfriendly to those who want to update autotoolage themselves). I would need to rename a file by hand in debian/rules, that's all. Should I remove those parts from the diff? > At a cursory glance it looks like this package may continue to need > such large patches it it continues to be un-maintained upstream (if > only for re-autotool-ing!). Debian patches are small: -q for suppressing output, manpage and now the buffer overflow fix. Autotoolage changes appear to be huge, but they're all auto-generated files. > Is Adam willing to take up the task of being de-facto long-term > maintainer of the package in this case? In long-term, the package will most likely be absorbed into cryptsetup, where already most of functionality has gone to. Unless somehow it is needed for something else (there appears to be no other hasher for RMD160 around), it will probably go away completely. It's mostly there to avoid breaking people's setups. Regards. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Fri, Jan 25, 2008 at 06:19:57AM +0530, Kapil Hari Paranjape wrote: > Hello, > > Sorry about the delay in responding. Different time zones! Hah, it's 4am, it's me who's hitting the bed now... > > On Thu, 24 Jan 2008, Adam Borowski wrote: > > Actually, it seems that reverting to upstream autotooling doesn't break > > anything (except obviously being unfriendly to those who want to update > > autotoolage themselves). I would need to rename a file by hand in > > debian/rules, that's all. > > > > Should I remove those parts from the diff? > > I think so. The package does not depend on anything substantial other > than the C library and compiler. Updating the autotool-age should not > be necessary. Actually, it does check for all the headers, then... doesn't use that information at all. configure.ac should be empty except for invoking automake. Even that old automake 1.7 upstream used knows where to install things good enough. I thus reverted this part of the diff, reducing it by a factor of 20... > I notice that you have shifted the man page from section 1 (used by > upstream) to section 8. Since "hashalot" is not just a "command to be > used by system administrators", I don't know why this has been done. Matthias Urlichs did this because: 1. hashalot is good nearly solely for cryptsetup. A nicer interface for using the hashes could be nice but SHA256, SHA384 and SHA512 are already provided by "coreutils", so anything an user would use is RMD160. Which was totally broken for anything but one-line strings until this upload and no one complained. 2. binary output can be dangerous for an unwary user > Rather than include the manpage you should patch the upstream > manpage. (Upstream seems to have included the manpage written by > Matthias Ulrich at some stage but the Debian packaging hasn't taken > this into account). Good point, fixed this. > > In long-term, the package will most likely be absorbed into cryptsetup, > > Now that there is "luks", there is some doubt about this! luks doesn't need an external helper for this task. > Overall, it would be good if you simplified the Debian .diff.gz so > that it is clear that it consists of (a) packaging (b) bug fixes to > the upstream code. (Usually (b) is done by using "dpatch" or "quilt" > but I won't insist on this). Ok, I did this, then overwrote 0.3-5 on mentors. There's a watch file for uscan now as well. Bye for tonight! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
(done) Re: RFS: hashalot (updated)
Debian Queue daemon wrote: > hashalot_0.3-5_arm.changes uploaded successfully to localhost > [...] Thanks! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS/RFC: bibutils; convert bibliographic data between formats
On Sun, Jan 27, 2008 at 07:55:30PM +0100, David Bremner wrote: > By the way, if you don't mind one more question, can you say how you > decided that the package was actually GPL 2+? The file headers are > not explicit, stating only "the GPL". The headers say just "the GPL" yet GPL included in the sources is GPL v2. >From "the" GPL: # If the Program does not specify a version number of this License, you may # choose any version ever published by the Free Software Foundation. So while one could argue whether bibutils is under GPL 1+ or GPL 2+, either has a claim for validity, with the latter being a safer choice. In case of doubt, you can include a single byte under GPL 2+ and thus force the issue :p -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tcng (updated) (1 RC, 3 non-RC bugs)
On Thu, Jan 24, 2008 at 12:44:41AM +0100, Adam Borowski wrote: > Hi! > > I seem to have issues getting hold on the previous sponsor (busy/bus/SA ?), > and there's a number of bugs that could use uploading. Try 2. Sponsoring fixes for RC bugs earns you karma, right? > The updated package can be found at: > dget http://mentors.debian.net/debian/pool/main/t/tcng/tcng_10b-2.dsc > > The issues fixed are: > > * FTBFS on amd64: > It appears that new glibc is more picky about the order of #includes (on > amd64 only). One of header files defines __KERNEL_STRICT_NAMES which > changes the behaviour of other parts -- but only if it's seen soon enough. By the way, there's a BTS shove/ignore fest between libc-dev and linux-libc-dev. Related bugs include #434040, #435700, #429064. Yet, since it is trivial to work around the issue here, there's no need to wait. > * TeX transition: > Build-depending only on texlive-latex-base cuts down half a GB of junk. > * Incorrectly cleared ingress rules: > A functionality bug. > * A manpage: > Instead of a stub which says "see this 180KB text file", I took an excerpt > from said file which describes command-line arguments. > * Wrapper madness: > The upstream package looks for data in whatever directory the package was > _built_ unless it's overridden with an env var. The /usr/bin/ binary is: > #!/bin/sh > TCNG_TOPDIR=/usr/lib/tcng exec /usr/lib/tcng/bin/tcc "$@" > which seems not robust enough. I changed the build system to set up the > paths at configure time. > * Vcs-Svn and Vcs-Browser > > Speaking of the last item, step-by-step diffs are linked from > http://angband.pl/viewvc/deb/tcng/trunk/?view=log -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: avant-window-navigator 0.2.1
On Tue, Jan 29, 2008 at 09:50:42PM +0100, Julien Lavergne wrote: > * Package name: avant-window-navigator It spews several pages of dpkg-shlibdeps warnings during build -- what about trimming the libs somehow? -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian: outdated-autotools-helper-file
On Sun, Feb 10, 2008 at 01:40:07PM -0600, Luis Rodrigo Gallardo Cruz wrote: > On Sun, Feb 10, 2008 at 08:27:52PM +0100, David Paleino wrote: > > E: gnome-translate source: outdated-autotools-helper-file config.guess > > 2003-07-02 > > > > What am I supposed to do? I believe that Build-Depending on autotools-dev | > > automake is not sufficient, as it seems that those files won't be updated > > anyways. Should I update them manually? This will introduce those changes in > > the .diff.gz outside the debian/ dir > > Build-Depend on autotools-dev, move the ofending files aside and put > the new copy in thier place before running ./configure, copy the > originals back at the end of clean. Or, instead of saving the originals, just delete them. dpkg-source ignores all deletions. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: talkfilters
On Sun, Feb 10, 2008 at 10:08:29PM +0100, David Paleino wrote: > talkfilters - convert English text into humorous dialects > > The GNU Talk Filters are filter programs that convert ordinary English text > into text that mimics a stereotyped or otherwise humorous dialect. These > filters have been in the public domain for many years, but now for the first > time they are provided as a single integrated package. The filters include: > austro, b1ff, brooklyn, chef, cockney, drawl, dubya, fudd, funetak, jethro, > jive, kraut, pansy, pirate, postmodern, redneck, valspeak and warez. Each > program reads from standard input and writes to standard output. Too bad, there's a lot of file conflicts with Joey Hess' "filters" which serve the same purpose. In fact, filters which conflict are either very same files or reimplementations of those due to license problems. Another issue is, the sources have been mostly gathered from random Usenet posts instead of being confirmed to be really in public domain. We had "filters-nonfree" in Debian for years, then they were either liberated, reimplemented or dropped. Mark Lindner's package lists many of authors as "(unknown)", what, together with these source files having no author attributions but just a GPL boilerplate, puts some doubts whether they are not simply copied together. I would really discuss this with Joey Hess first, he can shed a lot of light on the issue. I don't know the details, he does. And third thing, the claim that "now for the first time they are provided as a single integrated package" is obviously invalidated by Debian's "filters" being here since 1996 while Mark Lindner's "talkfilters" seem to be dated 1998, judging by the first ChangeLog entry. Just my two zorkmids... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#465086: RFS: talkfilters
On Sun, Feb 10, 2008 at 06:17:55PM -0500, Joey Hess wrote: > David Paleino wrote: > > Is there any chance for filter to provide a "libfilters" library to > > interface > > with? I've packaged talkfilters because it was a possible use of > > libtranslate > > [2] [3], but that's not really necessary. I could try to patch it so that it > > uses your "filters" package, but that would need a library to use. There's always pipe() and exec()... > > filters has programs written some in perl and some in lex, so that's not > really possible to do a shared library. ... and yacc, and pure C. Yet, all are either in a form of C (9) or Perl (15), so in theory one could link a Perl interpreter to it. Yet, IMHO the complexity isn't worth it. Creating a process costs less than loading the translation data for a real language anyway, and keeps it possible to write filters in Python (bleh) or Ada... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: tcng (updated) -- 4 bugs including RC
Hi! I am still looking for a sponsor for tcng; either long-term or one-shot. If someone would bother to review and/or upload the package, it would be great. One of outstanding bugs is RC, and it has been waiting for an upload for quite some time. One question: newest lintian complains about doc-base section being "net". Too bad, there's nothing appropiate in "Network/", and the closest match I could find was "System/Administration". Where would you put a language for managing traffic shapers? Version: 10b-2 (unstable has 10b-1) Description: Linux traffic control language interpreter Using /sbin/tc (to configure Linux network traffic flow control) is painful. This package attempts to reduce the pain with two new input languages (one for humans, and XML ;-). The output is XML, or /sbin/tc commands to configure the kernel. dget: http://mentors.debian.net/debian/pool/main/t/tcng/tcng_10b-2.dsc Cheers and schtuff! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
(done) Re: RFS: tcng (updated) -- 4 bugs including RC
After 8 RFS mails for tcng sent to various places, including 3 here, I guess that's a record. Especially for a RC bug fix. Yet, finally Sven Mueller became the hero who uploaded it. Yay for him! And boo for the rest of you lazy bastards :p (Ok, ok, that's probably a fault of me and my lack of people skills; it takes some to attract a sponsor. But, that would suggest I'm not perfect, which is obviously not the case, right?) Cheers and schtuff! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: kbtin -- A text-based MUD client
Do ITPs get their birthday presents? It would be cruel to have #213361
spend its bday in the cramped, smelly BTS. The last RFS ended in a small
flamewar with heretics who dared to claim that tinyfugue (tf) is
usable...
Right, try to get tf to:
* play a "game" like "dpkg-buildpackage" or "mysql-client"
* understand a similar language as zMud (used by ~70% of Windows players)
* survive a player saying 255 251 86 255 250 86 255 240 on a server
without full-blown TELNET additions (double 255 on LP): requests for
criminally insecure protocol extensions like MCCP or MXP are denied
* trigger a message containing color codes
* handle correctly triggers/substitions on messages split on network
packet boundaries --and-- allow prompts at the same time
(In other words, it's not redundant with other clients in Debian)
The packages are available from mentors.debian.net and from
http://angband.pl/debian/kbtin/, and are lin{tian,da} clean.
It would be really nice if I could find a sponsor...
best regards
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: KildClient - Powerful MUD client with a built-in Perl interpreter
On Sat, 31 Dec 2005, Eduardo M KALINOWSKI wrote: Package name: kildclient Kildclient supports the MCCP (Mud Client Compression Protocol) protocol, versions 1 and 2, to reduce the necessary bandwidth. I hope that you're aware that MCCP is a security hole. It assumes that the server either supports MCCP itself or at least has fully featured support for the TELNET protocol. It enables any player to knock you off the server[1], by saying/etc anything that includes the following bytes: 255 253 86 255 250 86 255 240 (for MCCP v2) 255 253 85 255 250 85 251 240 (for MCCP v1) If the server in question has only partial support for TELNET (most LP-based servers, including the "ldmud" package in Debian), the attacker has to double the 255 bytes. You can't blame servers for not talking TELNET, as this just an extra feature. Most codebases (by count, not by usage ratio) don't have it. Partial support is a bug (protocol violation), but unfortunately it's prevalent as most servers use a LP derivative. Thus, you need to either remove support for MCCP or make it an option that is disabled by default. MCCP is a custom extension used by few servers, so axing it won't really hurt. [1] Kildclient will either segfault or lock up -- I'm not sure if this can be exploited to run arbitrary code. Another issue: There is a consistent crash every time you enter "Preferences" for the second time. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kqemu package
On Mon, 10 Apr 2006, Rakotomandimby Mihamina wrote: Would you know any project to make a kqemu Debian package? I know there is already a qemu, I just subscribed to the ML, but how about kqemu? The problem is, you are not allowed to distribute kqemu. So, the only thing you will be legally permitted to do with your package will be installing it on any number of machines under your control. If you don't insist on having proper packages: # apt-get build-dep qemu $ apt-get source qemu Untar the kqemu tarball inside the qemu dir. The last time I checked, kqemu had version 0.7.2 while qemu 0.8.0 -- but it's ok. Then, you need to make sure you have proper kernel headers in /usr/src/linux (or somewhere else, in this case you'll have to append --kernel-path= to configure). Then, you build qemu normally, it's configure script will notice the kqemu subdir and build it as well. The deb will have support for kqemu enabled, but won't include the package itself. 'make install' as root inside the kqemu dir will fix that. In order to make proper packages, you would have to edit kqemu/Makefile and kqemu/install.sh, changing all hard-coded paths appropiately. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kqemu package
On Sun, 9 Apr 2006, Martin Kelly wrote: Rakotomandimby Mihamina wrote: Would you know any project to make a kqemu Debian package? I know there is already a qemu, I just subscribed to the ML, but how about kqemu? It is not open source... you would have to put it in the non-free section. Not even there, at least not without "explicit authorisation" from Fabrice Bellard. You can still make a downloader+installer package (for contrib), but it will break every time the upstream webpage changes. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS music123 package
On Mon, 17 Apr 2006, Maxime Robache wrote:
I'm looking for comments and for a sponsor concerning the music123
package I just adopted.
1. As it's a maintainer upload, the version number should be 15, not 14.3
-- the latter is used for source NMUs.
2. You may want to add support for other filetypes. For example:
* mpc => mpc123 (since recently in Debian), mppdec (not packaged)
* wav => play (package: sox)
* mid => timidity
* s3m, mod => s3mod
* nsf => nosefart (not packaged)
* sid => sidplay
* mp2 => mpg123
(flamebait warning)
3.
#!/usr/bin/perl -w
%player=("mp3"=>"mpg123","ogg"=>"ogg123","wav"=>"play","mid"=>"timidity","s3m"=>"s3mod","mod"=>"s3mod","mpc"=>"mpc123");
@playlist=grep(/\.(wav|mp3|ogg|mid|s3m|mod|mpc)$/i, @ARGV? @ARGV :
split('\n',`find`));
$type="";
for(@playlist)
{
/.(wav|mp3|ogg|mid|s3m|mod|mpc)$/i;
if ("$type" ne "\L$1")
{
do_play();
undef @chunk;
$type="\L$1";
}
push @chunk, $_;
}
do_play();
sub do_play
{
return unless @chunk;
die "Invalid file type: [$type]\n" unless $player{$type};
system $player{$type}, @chunk;
}
(my /usr/local/bin/123) after adding the command-line args could replace
57KB of Ada code. This is a matter of preference, though, and smells of
language bashing :-p
Regards, 1KB
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building rpms on debian system?
On Wed, 19 Apr 2006, Ek Zindagoi wrote: I would like to build rpms on a debian system for use on a redhat system. Can I do that on a debian system ? As a short-term solution, you can cheat by making a Debian package and using alien --to-rpm. However, if anyone tries to put your RPMs into one of their repositories, they can run into problems: http://sourceforge.net/forum/forum.php?thread_id=1313775&forum_id=209131 Oooh... and, seizing an opportunity to push that particular package... An old ITP, fresh release. mentors.debian.net, "kbtin", clean packaging, no dependencies other than libc. I guess that the lack of source RPMs is not a problem here, too :p Happy hacking, Adam -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: d.n.s.c.r.u.f.t. (name mangled because of s.a. :p)
Yeah, I've made it.
kilobyte: hah
X-Spam-Status: Yes, score=5.1 required=4.0 tests=AWL,DRUGSPAM,DRUGSPAM2,
DRUGSPAM3,DRUGS_ERECTILE,IMPRONONCABLE_1,MANY_EXCLAMATIONS,
MURPHY_DRUGS1,SUBJECT_DRUG_GAP_C,SUBJECT_DRUG_GAP_VIA
autolearn=spam
I'm surprised you only got that
Let's say that the previous post contained some references about the sites
this package blocks. If I made murphy autolearn the package's name to mark
it as spam, will I get a medal? :p
Getting a little afraid of quoting the stats again, let's say that ads,
popups and other junk were about 18.5% of entries in my Squid logs. Getting
rid of that is worth a package to me.
Thus, a sponsor would be nice.
Package: dnsNOSAcruft (without NOSA ;-) )
Repository: mentors or http://angband.pl/debian unstable main
{lintian,linda,pbuilder,piuparts}-clean
Cheers.
--
1KB // Rule #6: If violence wasn't your last resort,
// you failed to resort to enough of it.
// - The Seven Habits of Highly Effective Pirates
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dnscruft
On Fri, May 12, 2006 at 12:45:15PM -0400, Joe Smith wrote: > >On Fri, May 12, 2006 at 01:09:40AM +0200, Adam Borowski wrote: > >>Let's say that the previous post contained some references about the > >>sites this package blocks. If I made murphy autolearn the package's > >>name to mark it as spam, will I get a medal? :p > > No, indeed. Kilobyte now must clean up the mess he made. If a package name > is a spam trigger than Debian will have major difficulties in dealing with > that package. One word does not spam make. Otherwise, we wouldn't be able to say a word about Viagra at all, and it would be against the 1st Amendment and thus illegal on servers in the US. (Ok, this analysis may perhaps have some flaws :p). Also, the word "dnscruft" has a spam ratio of no more than 50% (due to the recent ITP), thus it doesn't contribute towards a given post's SA score. On the other hand, though: X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 [...] X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on barad-dur X-Spam-Level: ** X-Spam-Status: No, score=2.9 required=5.0 tests=AWL,FORGED_HOTMAIL_RCVD2, GAPPY_SUBJECT,PRIORITY_NO_NAME autolearn=no version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on barad-dur.angband.pl) You managed to score quite a bit just for using Lookout, more than half of what I got for plenty of quotes from the crap sites dnscruft blocks. But oh well, the original RFS was sent by pine, and it's non-free junk too. But oh well, I need a way to somehow trick you to dget http://mentors.debian.net/debian/pool/main/d/dnscruft/dnscruft_0.20060512-1.dsc and review/upload it :p Bye. -- 1KB // Rule #6: If violence wasn't your last resort, // you failed to resort to enough of it. // - The Seven Habits of Highly Effective Pirates -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-english license and documents
On Mon, May 22, 2006 at 10:32:18PM +0800, Ying-Chun Liu wrote: > Second, the javadoc documents coming with the source files are Japanese. > Should I prune the documents or include them? How do I include them? Please, keep them. Removing documentation is a disservice to the users, even if only a part of them can read it. Only if an adequate English version was available [1], pruning the Japanese docs would be an option IMO (and only because ~99.9% of Japanese people have good command of English). > Should I seperate to another binary package like libjlha-java-doc(-jp)? Do they take half a megabyte or more? Is the package a dependence of something very popular? If no, increasing the size of "Packages" by over 1KB per binary package would more than kill all potential benefits of the split. > But in every *.java (source code) the license is written in > Japanese (same as the license shown on the Japanese page). Because > I'm not good at Japanese, so I can't make sure the license in > Japanese is free or not. Is there any way to deal with the problem > without asking the upstream author to change the source files? FTPmasters and our debian-legal mavens tend to REALLY look down upon removing license notices from source files. If we have a license in English that came from the author (and thus is legally binding), the Japanese copy is harmless, and it will get compressed away by tar|gz so disk space is not a concern as well. Of course, let's have a Japanese-speaking person take a look at the text, but IMHO you don't need to bother about any accuracy higher than "this looks to be the same as the English version". Cheers and schtuff, 1KB. [1] I hope that only few of you seen Polish perl manpages once shipped with PLD. Unless somehow Mommy lied to me about my native language, there must be something really wrong with those docs, as I couldn't comprehend them at all. Gods be praised for ssh and the English version of the mans. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-english license and documents
On Tue, May 23, 2006 at 02:30:50PM +1000, Jamie Jones wrote: > In the event of any license related issues perhaps caused by > mis-translation, the Japanese version is the canonical version that must > be followed. Isn't this the case only if someone else than the author translated the license? -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond-no8
On Sat, Jun 03, 2006 at 01:10:25PM +0200, Florent Rougon wrote: > Charles Plessy <[EMAIL PROTECTED]> wrote: > > Le Fri, Jun 02, 2006 at 04:10:29PM +0200, Florent Rougon a écrit : > >> The files pertaining to the Debian packaging are > >> (c) 2006 Kevin Bube. > >> > > Maybe one could suggest a replacement for the word "pertaining", which > > may be a bit complex for average non-native speakers? > > I'm all open for suggestions since... I am a non-native speaker. Suggestion: apt-get install wordnet wn pertaining -synsv (actually, mindlessly using wn -over works as well most of the time and is simpler to memorize) However, in this case, I wouldn't bother: 1. In this sentence, the meaning can be trivially blarghed from the context. 2. Using simple English is good in help files, but it can look awkward next to legalese. (And yeah, me be a nyet-native speaker, too). Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Homepage-field in description
On Thu, Jun 15, 2006 at 12:11:32AM +0800, Paul Wise wrote: > I don't think any part of packages (description or separate field) are > the correct place for the Homepage field. Yes, that's because it's an unneeded duplication of what's already present in /usr/share/doc/*/copyright. The description is meant to convey information about where you can find useful things about the package, not about where you can download a new version. Of course, there may be cases where including the homepage may be beneficial, but most of the time, it's nothing but adding visual spam. If the homepage contains nothing but a blurb and download links, why would anyone need it in a description that is supposed to be _short_? Thus: shouting on people for "forgetting" the Homepage: field is counterproductive IMHO. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: llk-linux (bug #373754)
On Thu, Jun 15, 2006 at 09:11:54PM +0800, Wei Mingzhi wrote: > * Package name: llk-linux > Description : LianLianKan game for GNU/Linux Well, and (released) Debian, what OS it is? The name and desc of your package doesn't make any sense to me -- the "-linux" part is totally redundant. And, as a piece of visual spam, it is something that IMO should be axed. And, I bet it's wrong, too. A glance at the package shows no reason why it wouldn't work on debian-hurd, debian-kfoobsd, Nexenta, or even, Cthulhu forbid, CygWin. I see that you didn't include the actual link to your package. Just for the actual potential sponsor: it's on mentors.debian.net > (PS: please CC me, I'm not subscribed to this mailing list) Ok, just one note: the "Reply-To:" field doesn't look any similar to your name -- one can feel a bit uneasy using it. Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: llk-linux (bug #373754)
On Thu, Jun 15, 2006 at 09:11:54PM +0800, Wei Mingzhi wrote:
> I'm looking for a sponsor for the following package:
Good luck! As it's in my interest to save the time of actual DDs,
let me help you with the more obvious issues.
> * Package name: llk-linux
* Of course, the issue I mentioned earlier still stands. Having
llk_linux as the package and binary name sucks, is redundant and
ugly. Generally, I would suggest renaming it to "llk", however, for
a GUI-only program, "lianliankan" or "lian-lian-kan" probably would
be better.
* It appears you have a bunch of symlinks to files in
/usr/share/automake-1.9/, yet you don't build-depend on automake-1.9.
You'll need to either add the dependency or replace the symlinks with
actual files.
Once the package is built, let's run lintian on it:
W: llk-linux: binary-without-manpage llk_linux
* The program is GUI-only without any command line, and this is about
the only case where having no manpage is excusable. And "excusable"
doesn't mean "good".
E: llk-linux: FSSTND-dir-in-usr usr/doc/
* The culprit lies in Makefile.am:
.
| llk_linuxdocdir = ${prefix}/doc/llk_linux
`
A naive solution would be making that ${prefix}/share/doc/llk_linux,
however, it's better to install the documentation using
Debian-specific ways. You'll need to adjust every single file
anyway.
W: llk-linux: extra-license-file usr/doc/llk_linux/COPYING
* With GPL, the policy says the license should be pointed to from
/usr/share/doc/$package/copyright instead of being installed as-is.
W: llk-linux: zero-byte-file-in-doc-directory
usr/share/doc/llk-linux/changelog.gz
* If there's no upstream changelog, we don't install it.
W: llk-linux: readme-debian-is-debmake-template
* Just delete it. I can't think of anything reasonable to put there
at this moment.
W: llk-linux: menu-command-not-in-package /usr/share/menu/llk-linux:2
/usr/games/llk-linux
* The binary you install is named llk_linux, not llk-linux (but
again, issue 1 :p).
W: llk-linux: menu-item-uses-apps-games-section /usr/share/menu/llk-linux:2
W: llk-linux: menu-item-creates-new-section Apps/Games
/usr/share/menu/llk-linux:2
* It's just "Games" now.
W: llk-linux: wrong-bug-number-in-closes l3:#
* Should be #373754
* debian/copyright needs to be filled out.
The only non-obvious part is the license. If you're too lazy to read
the relevant part of the policy, just cut&paste this:
.
| This program is free software; you can redistribute it and/or modify
| it under the terms of the GNU General Public License as published by
| the Free Software Foundation; either version 2.1 of the License, or
| (at your option) any later version.
|
| See /usr/share/common-licenses/GPL.
`
* debian/dirs includes /usr/sbin. Why?
* debian/docs includes three files, all empty. Empty files are not
documentation, you see...
* debian/rules have a lot of commented-out files. While harmless,
they cause angry shouts from sponsors, and thus, well, are not
entirely harmless :p
* long description: I'm afraid it could really use being filtered
through a native speaker of English...
A bit of testing:
* About|Rules should probably be Help|Rules.
* The "rules" are written in Chinese, and thus unreadable by a vast
majority of Debian users. It's just a short page -- so translating
it is only a small effort.
HTH.
> (PS: please CC me, I'm not subscribed to this mailing list)
Cheers and schtuff,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: hashalot (adopting)
Whee!? I'm adopting "hashalot", one of the packages Matthias Urlichs recently gave away. He doesn't have the time nowadays, so it would be nice if someone could sponsor this package. It's a simple package with straightforward packaging. My changes: * a cleanup of debian/rules * AM_MAINTAINER_MODE instead of touch-fu * a cleanup of debian/copyright - FSF's address - removed info related to cryptsetup, it has its own package these days * enabled the testsuite on non-cross builds The package is foo-clean, of course. URL: http://mentors.debian.net/debian/pool/main/h/hashalot (or, of course, apt from mentors) Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: tcng (adopting)
Whee!? I'm looking for a sponsor for tcng, another package of Matthias Urlichs that I'm adopting. This upload fixes two unreported RC issues, introduces a new major upstream release and fixes 5 of 6 bugs in the BTS. RC bugs: * FTBFS outside pbuilder * conflict for the binary name "tcc", also found in the package "tcc"; it's RC per Policy 10.1. The upstream renamed the binary to "tcng", so no arbitration against "tcc" is needed. The package is foo-clean. URL: http://mentors.debian.net/debian/pool/main/t/tcng (or apt from m.d.n) Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: kbtin (new)
Whee!? I'm looking for a sponsor for my pet package "kbtin", an extended beyond recognition fork of tintin++. And, unlike any other MUD client in Debian, kbtin can be used to play a popular game named "dpkg-buildpackage" when piping the output through less and friends doesn't cut it. At least, less won't let you interactively sign the packages and so on. The ITP is #213361. The package is foo-clean; the packaging is trivial (clean autotoolage). URL: http://mentors.debian.net/debian/pool/main/k/kbtin (aptable from m.d.n) Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: dnscruft (new)
Whee!? In an attempt to infringe on commercial free speech, I'm looking for a sponsor for a new package, "dnscruft". It feeds bind9 a list of domains like: * doubleclick.net * googlesyndication.com and a plethora of other advertisers, spammers, win32 spyware spewers, phishers and other miscreants that waste a significant part of your bandwidth. It's not just an annoyance, it's freaking 20-33% of all http requests. This package uses a conservative database by default, but provides convenient means of adding custom, more aggressive lists. ITP: #366482. The package is foo-clean. URL: http://mentors.debian.net/debian/pool/main/d/dnscruft (of course, aptable from m.d.n.) Cheers. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tcng (adopting)
On Tue, Jun 20, 2006 at 01:18:05AM +0200, Adam Borowski wrote: > I'm looking for a sponsor for tcng, another package of Matthias Urlichs > that I'm adopting. > RC bugs: [...] > * conflict for the binary name "tcc", also found in the package > "tcc"; it's RC per Policy 10.1. The upstream renamed the binary > to "tcng", so no arbitration against "tcc" is needed. Update: I added NEWS.Debian with a mention of this renaming. (Thanks, pabs!) -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kbtin (new)
On Tue, Jun 20, 2006 at 08:55:40PM -0400, Joe Smith wrote:
> "Adam Borowski" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> >The ITP is #213361. The package is foo-clean; the packaging is
> >trivial (clean autotoolage).
> What is this foo package you keep talking about?
> I know of lintian, linda, puiparts, but not foo.
And pbuilder.
What I mean, the set of automated tools to run is common to every
package tested at a given time. Rare or specialized tools do exist,
but I haven't heard of them being used around d-m these days.
At this time, the fashion^Wcommon practice is to run:
* lintian
* linda
* pbuilder
* piuparts
and there is hardly ever any reason to skip any of them, so it can be
generally assumed that if a metasyntactic variable is used, it's used
as an abbreviation for all four.
This said, piuparts is pretty much a waste of CPU time for any
package that doesn't involve daemons, system-wide config or
system-wide cache -- ie, a majority of user-level software; however,
CPU time is so cheap these days that there is no excuse to skip
piuparts for us pre-DDs.
Going back to kbtin, I'm not sure whether I can claim linda-cleaness
if there's a change made solely to silence her. Linda considers
_empty_ config.{sub,guess} to be outdated; I thus put some short
placeholder contents just to make her happy. The empty
config.{sub,guess} files themselves were a hack to work around a bug
in an old version of automake, a bug that is long gone now. The
files of course should be removed from the upstream tarball, but 1.
it appears to be impossible to remove files from the source; and 2.
it makes no sense to repack the upstream tarball just to get rid of
an empty harmless file.
Of course, if you're a sponsor, forget you've ever seen the previous
paragraph :p The package is linda-clean, neither the hacks nor the
reasons for them are present in upstream svn any longer, and this is
everything you need to know :p
Cheers, regards and what not,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request-For-Sponsorship (xfardic)
On Wed, Jun 21, 2006 at 09:36:59AM +, Alan Baghumian wrote: > * Package name: xfardic First, it would be nice if the subject could contain the package's name. Perhaps the m.d.n boilerplate could include it. The big four tests: * lintian: I'm afraid there are four issues, all in the binary .deb. Just run "lintian -i xfardic_0.7.5+cvs20060604-2_i386.deb", the output is quite descriptive. * linda: A subset of lintian's warnings. * piuparts: Fails, but it's due to your dependency chain. It's not your fault, so you can ignore it for now. * pbuilder: Ok. The source: * The package is debian-native, even though it obviously has an upstream, plenty of non-Debian specific code and so on. You'll need to pass the appropiate args to dpkg-source. * You need to close your ITP bug in debian/changelog: Closes: #282457. * On the first upload, debian/changelog should have just one entry. This is somewhat clumsy if you have a history of this package in your private/local repository (like me with debs of kbtin on SourceForge), but I remember someone being shouted upon for this. I can't recall the reason, but I guess someone can say what it was. * debian/README.Debian contains nothing relevant. Everything has already been mentioned in debian/copyright, the description or simply doesn't matter to the end user (installation details). * debian/dirs: usr/sbin is obviously unneeded. * debian/xfardic.doc-base.EX -- an unedited example file. * debian/rules: Having unneeded commented out stock dh rules is frowned upon. The binary: * README -- exactly the same as README.Debian. * The source has po files for fa_IR and az_AZ, yet only fa_IR gets installed. * As this is a GUI program, a menu or .desktop file would be useful. * No databases are installed by default. Why won't you package them, especially if you provide one on the SF pages yourself? The program is kind of useless otherwise. Usage comments: * Slogging through a tiny scrolled window is a pain, and it happens every time you specify a word that's a part of more than 1-2 phrases. Why won't you enable the maximize button? (No "real" usage tests, sorry. My knowledge of Persian is about as good as my knowledge of Chinese, Klingon or Swahili.) HTH. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] cmarrows
On Wed, Jun 21, 2006 at 11:10:53PM +0200, Matej Kosik wrote: > Uff. I wrongly assumed that software available on the internet without > any restrictions (no licensing information, no "public domain" statement > ) could be considered to be "public domain". As you say, it is not true. > > Thus, the original software is "all rights reserved". That means that > noone (other than the original author---the coopyright holder) can: > - distribute it > - modify it > - ditribute modified versions. > Am I right? You can always modify a piece of software you legally obtained, just like you can modify a car you bought, not losing anything but an eventual guarantee. Only signing a contract can take away this right from you; copyright applies only to _copying_, not to use or modifying. But otherwise, you're right. However, the correct thing to do now is "mail upstream", not "drop the package". Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ipbt
On Wed, Jul 05, 2006 at 02:28:59PM -0400, Bryan Donlan wrote: > * Package name: ipbt > ipbt - Fast, advanced ttyrec player Oops, on just loading a typical NetHack recording: real1m36.499s user1m35.050s sys 0m0.648s Something is terribly wrong here, as my very inefficient implementation of the same loads the same file in a split second. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ipbt
On Wed, Jul 05, 2006 at 10:19:15PM -0400, Bryan Donlan wrote: > On 7/5/06, Adam Borowski <[EMAIL PROTECTED]> wrote: > >On Wed, Jul 05, 2006 at 02:28:59PM -0400, Bryan Donlan wrote: > >> * Package name: ipbt > >> ipbt - Fast, advanced ttyrec player > > > >Oops, on just loading a typical NetHack recording: > > > >real1m36.499s > >user1m35.050s > >sys 0m0.648s > > > >Something is terribly wrong here, as my very inefficient > >implementation of the same loads the same file in a split second. > > The current implementation loads all frames of the movie ahead of > time, generates a list of (character position, frame index, new value) > structures, then sorts by position and time. This allows it to rapidly > reconstruct the value of any character at any frame. My idea was to store the unprocessed vt100 stream and just generate checkpoints every X bytes. Every checkpoint contains a snapshot of the tty state, so seeking is a matter of silently sending the vt100 stream since the last checkpoint to your tty emulator -- silently as in "no immediate screen updates". On any recording of reasonable size this is actually going so fast that in my last alpha release (termrec) I create the checkpoints but not actually use them yet; every seek does a complete reload since the very start. PuTTY tty engine is more sophisticated than mine, but I don't see any reason why it would be significantly slower; this appears to be a fault of the storage data structure. Anyway, I doubt if I'll find the time to finish up termrec anytime soon, but if you would find any pieces of code useful, feel free to take them, without bothering yourself with license issues (ipbt is MITed; termrec is GPLed but it's mine -- so here's the license grant). Meep? -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder on sarge
On Mon, Jul 10, 2006 at 11:54:43AM +0200, Thibaut Paumard wrote: > > E: Couldn't download slang1a-utf8 > > pbuilder: debootstrap failed > > Use pbuilder and cdebootstrap from http://www.backports.org/ . > > To do that, put: > deb http://www.backports.org/debian/ sarge-backports main > in your /etc/apt/sources.list . > > Then add the following to /etc/apt/preferences : > > Package: * > 8< > Pin: release a=sarge-backports > Pin-Priority: 200 good > Package: cdebootstrap > Pin: release a=sarge-backports > Pin-Priority: 999 > > Package: pbuilder > Pin: release a=sarge-backports > Pin-Priority: 999 uhm, why? The whole point of setting the priority at 200 when the default source is at 500 is to say: "don't select these packages automatically, but once I install any of them, keep tracking them until a source of higher priority catches up". > Then run > apt-get update > apt-get install pbuilder cdeboostrap You would have to specify -t sarge-backports once; but then you won't have your /etc/apt/preferences cluttered and this exception will be automatically removed once the version in stable reaches the one you have installed. Both solutions have different semantics, but the former will stick to sarge-backports forever, and I doubt if that's what you want. Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: vtgamma -- gamma correction for Linux console
Meep? I am looking for a sponsor for my package "vtgamma". It contains a tool to set gamma correction on the Linux console, and a simple interactive utility to find out what an appropiate gamma value would be. lintian : clean linda: clean pbuilder : clean piuparts : clean ITP : #377939 URL: http://mentors.debian.net/debian/pool/main/v/vtgamma apt: deb-src http://mentors.debian.net/debian unstable main debian/rules is below 30 lines, and contains nothing but straightforward dh_ lines, so sponsoring shouldn't take more than a tiny bit of your valuable time. An upload would be cool. Regards, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: two different packages with the same source tarball/name
On Fri, Jul 14, 2006 at 02:34:41PM +0200, Thomas Weber wrote: > is it possible to have two different binary packages with the same > source package name (but different upstream versions of the source)? No. The package with the later version will overwrite the earlier one, and this will cause the binaries no longer built to be removed. It is possible to have a single source package have the sources for two versions and build two different binary packages, but in this case you would (rightfully) get beaten with sticks. > Reason: I'm about to package octave-forge for both Octave 2.1 and 2.9 > (you can consider octave-forge as plugin, that needs to be compiled for > the respective version). > Now, upstream provides only one tarball for *one* version; that is, the > latest upstream tarball is meant for Octave 2.9, while previous versions > were meant for Octave 2.1. > I would therefore like to keep the old version for Octave 2.1 (with a > source name of octave-forge), while packaging the latest version for > Octave 2.9 (as well with a source name of octave-forge, but a different > upstream version). Just have two different source packages. Preferably, with the same names as the binaries they produce. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bashish -- Theme environment for text terminals
On Fri, Jul 14, 2006 at 11:58:26PM +0200, Thomas Eriksson wrote: > * Package name: bashish > The package is lintian clean. Er...? lintian -i bashish_2.0.5-1_i386.changes |wc -l 30 To be a bit more exact: lintian bashish_2.0.5-1_i386.changes -i|head E: bashish: shell-script-fails-syntax-check ./usr/share/bashish/bt/defaults/theme N: N: Running this shell script with the shell's -n option set fails, which N: means that the script has syntax errors. N: N: Run e.g. sh -n yourscript to see the errors yourself. N: E: bashish: shell-script-fails-syntax-check ./usr/share/bashish/bt/overrides/theme E: bashish: shell-script-fails-syntax-check ./usr/share/bashish/main/bashish/init E: bashish: shell-script-fails-syntax-check ./usr/share/bashish/main/bashishtheme/init But, here's the culprit: head -n1 bashish-2.0.5/debian/bashish/usr/share/bashish/bt/defaults/theme #!/bin/sh I'm afraid that bashish is just crawling with, uhm, bashisms. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bashish -- Theme environment for text terminals
On Fri, Jul 14, 2006 at 11:58:26PM +0200, Thomas Eriksson wrote: > * Package name: bashish Basic usability test: Installed the package. Ran it as user (TERM=linux, SHELL=bash): a dialog popped up, asking whether to install it. Agreed. Got asked to restart the shell: === logout Debian GNU/Linux testing/unstable umbar tty1 umbar login: kilobyte Password: Last login: Sat Jul 15 08:44:10 2006 on tty10 Linux umbar 2.6.17-1-686 #1 SMP Thu Jul 13 14:30:26 UTC 2006 i686 No mail. /usr/share/bashish/main/terminal/init: line 29: /usr/share/bashish/main/terminal/engine/_bashish_vt1 00_title: No such file or directory /usr/share/bashish/main/terminal/sys/loadengine: line 82: _bashish_vt100_title: command not found [~]$ 8749A53C6BF63414171724D6541817966cf617100[~]$ === Also, "bashish -u", after popping up a dialog asking whether to uninstall (with default="Cancel"!), fails with: === Error: Expected at least 3 tokens for --msgbox, have 1. Use --help to list options. === Regards, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bashish -- Theme environment for text terminals
On Sat, Jul 15, 2006 at 03:50:20PM +0200, Thomas Eriksson wrote: > However, I am unable to reproduce your errors > "shell-script-fails-syntax-check", what I'm blindly guessing is that > lintian complains (rightfully so, albeit sh -n produces no error since > it is linked to bash :)) that the ksh functions contained therein are > not syntactically correct according to POSIX sh? Indeed, Lintian doesn't depend on dash or posh, and will find this problem only if /bin/sh is one of the pickier shells. Actually, since your program can run on a number of shells which implement common extensions, this raises the question what's the proper way to mark that. > My lintian --version reports "Lintian v1.23.22" > What does your "lintian --version" say? Same. > Could you check if its lintian clean now? It is :) > anyway > 2.0.5.1 up at sourceforge.net and mentors.debian.net > Now even more Lintian clean(tm) ;) And it now works on the console! Cool! Just as a note for the other reviewers: on many terminals, some of bashish themes don't work well, miss some glyphs, etc. This kind of things is impossible to detect -- at least not in any portable or semi-portable way. And termcap/terminfo are just bad jokes. I found only a number of very minor things: 1. a typo: Bashish is now removed from your user account. However, it is still availiable system-wide, consult your ^ package manager on how to completely remove Bashish. 2. debian/dirs spuriously lists /usr/sbin 3. neither config.guess nor config.sub are used -- you can save nearly 10% of your source size by axing them away Worth fixing in your private tree, but not warranting a new release IMO. Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bashish -- Theme environment for text terminals
On Sat, Jul 15, 2006 at 10:03:56PM +0200, Thomas Eriksson wrote:
> 2006/7/15, Adam Borowski <[EMAIL PROTECTED]>:
> >on many terminals, some of bashish themes don't work well, miss some
> >glyphs, etc. This kind of things is impossible to detect -- at least
> >not in any portable or semi-portable way. And termcap/terminfo are
> >just bad jokes.
>
> Yup, currently most fancy prompts in Bashish are hardcoded in UTF-8
> Let's see if I can hack together better 8859-1 support for 2.0.6
What I meant is that it's impossible to tell whether a given glyph is
present; downgrading to an 8-bit encoding can't help.
If you want to bother with supporting ancient charsets, utfness
actually _can_ be detected. In two ways:
1: checking the locale:
{
setlocale(LC_CTYPE, "");
charset_name=nl_langinfo(CODESET);
return !strcmp(charset_name, "UTF-8");
}
This relies on the user setting his locale set correctly -- but this
way is consistent with the vast majority of software in Debian.
Too bad, I'm unsure how to do this from shell. You can't check for
locales ending in .UTF-8, as this won't catch vi_VI, or, if gods and
the release team get reasonable, en_US or pl_PL in the near future.
2. writing something to the terminal:
(program attached)
This doesn't rely on the locale support.
And, the whole exercise is sort of pointless -- you need UTF-8 for
block graphics, which is NOT SUPPORTED IN ISO-8859-* ANYWAY. That
said, you can often switch to the IBM charset (dubbed "cp437" by a
certain unrelated company) with "\e[11m" and go back with "\e[10m".
So, detecting utfness just to tell them they can go to hell is not
worth your effort :p
> I really appreciate reviews or bug-reports of Bashish. Having Bashish
> in Debian would be really cool, but perhaps there are some features
> lacking now.
>
> If no one steps up to sponsor it right away, I'll just regulary upload
> packages anyway to http://mentors.debian.net :)
Just uploading to mentors doesn't work, I'm afraid. There is much
more sponsorees than sponsors, so no one appears to check old RFS or
listings such as sponsors.debian.net
Cheers and schtuff,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
/*
* small tool to figure whenever a tty runs in utf8 mode or not.
* writes a utf-8 multibyte sequence and then checks how far the
* cursor has been moved.
*
* return codes:
* 2 - don't know (stdin isn't a terminal, timeout, some error, ...)
* 1 - not in utf8
* 0 - utf-8
*
* Written by Gerd Krorr, minor changes by Adam Borowski.
*/
#include
#include
#include
#include
#include
#include
struct termios saved_attributes;
int saved_fl;
void
tty_raw()
{
struct termios tattr;
fcntl(0,F_GETFL,&saved_fl);
tcgetattr (0, &saved_attributes);
fcntl(0,F_SETFL,O_NONBLOCK);
memcpy(&tattr,&saved_attributes,sizeof(struct termios));
tattr.c_lflag &= ~(ICANON|ECHO);
tattr.c_cc[VMIN] = 1;
tattr.c_cc[VTIME] = 0;
tcsetattr (0, TCSAFLUSH, &tattr);
}
void
tty_restore()
{
fcntl(0,F_SETFL,saved_fl);
tcsetattr (0, TCSANOW, &saved_attributes);
}
int
select_wait()
{
struct timeval tv;
fd_set se;
FD_ZERO(&se);
FD_SET(0,&se);
tv.tv_sec = 3;
tv.tv_usec = 0;
return select(1,&se,NULL,NULL,&tv);
}
int
main(int argc, char **argv)
{
static char *teststr = "\r\xc3\xb6";
static char *cleanup = "\r \r";
static char *getpos = "\033[6n";
char retstr[16];
int pos,rc,row,col;
if (!isatty(0) || !isatty(1))
exit(2);
tty_raw();
write(1,teststr,strlen(teststr));
write(1,getpos,strlen(getpos));
for (pos = 0; pos < sizeof(retstr)-1;)
{
if (0 == select_wait())
break;
if (-1 == (rc = read(0,retstr+pos,sizeof(retstr)-1-pos)))
{
perror("read");
exit(2);
}
pos += rc;
if (retstr[pos-1] == 'R')
break;
}
retstr[pos] = 0;
write(1,cleanup,strlen(cleanup));
tty_restore();
rc = sscanf(retstr,"\033[%d;%dR",&row,&col);
if (2 == rc && 2 == col)
{
fprintf(stderr,"Terminal is in UTF-8 mode.\n");
exit(0);
}
fprintf(stderr,"Terminal is in single-char mode.\n");
exit(1);
}
RFS: chameleon-cursor-theme
Meep? Whee?
Hey, lookie! Shiny!
RFS:
* Package name: chameleon-cursor-theme
Version : 0.5-1
Upstream Author : Giuseppe Benigno
* URL (upstream) : http://www.kde-look.org/content/show.php?content=38459
* License : GPL
Section : x11
Binaries : chameleon-cursor-theme - a modern but not gaudy X11 mouse theme
ITP : #378746
(new package)
All of: lintian, linda, pbuilder, piuparts are happy with it.
I assigned the priority for x-cursor-theme to 49 for all but one
themes, setting one to 50.
Since I needed to repack .orig anyway (5 separate .tar.bz2 balls),
I removed the already built parts, leaving just the source -- the
source and ready-to-install pieces were stuffed in the packages
together. Per the usual rules, this repacking can be done with a
script: debian/makeorig -- it will download things from the upstream
("wget", "bzip2" and "file" required).
The sources are at:
http://mentors.debian.net/debian/pool/main/c/chameleon-cursor-theme
or aptable at:
deb-src http://mentors.debian.net/debian unstable main
An upload would be cool.
Regards and schtuff,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tstat
On Sun, Aug 20, 2006 at 08:21:47AM -0700, tony mancill wrote: > Sandro Tosi wrote: > > * Package name: tstat > > IANAL (I am not a lawyer), but I wonder if we shouldn't ask debian-legal > about these license clauses for erf.c: > > 3. All advertising materials mentioning features or use of this software > must display the following acknowledgement: >This product includes software developed by Endace Technology Ltd., >Hamilton, New Zealand, and its contributors. > 4. Neither the name of Endace Technology nor the names of its contributors > may be used to endorse or promote products derived from this software > without specific prior written permission. This is exactly the wording of the 4-clause BSD license, with just the name of UC Berkeley replaced with Endace. It's thus DFSG-free, even though it's strongly discouraged. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tstat
On Tue, Aug 22, 2006 at 08:37:30AM +0900, Charles Plessy wrote: > Le Mon, Aug 21, 2006 at 11:20:35AM +0200, Adam Borowski a écrit : > > On Sun, Aug 20, 2006 at 08:21:47AM -0700, tony mancill wrote: > > > 3. All advertising materials mentioning features or use of this software > > > must display the following acknowledgement: > > >This product includes software developed by Endace Technology Ltd., > > >Hamilton, New Zealand, and its contributors. > > > 4. Neither the name of Endace Technology nor the names of its > > > contributors > > > may be used to endorse or promote products derived from this software > > > without specific prior written permission. > > > > This is exactly the wording of the 4-clause BSD license, with just the name > > of UC Berkeley replaced with Endace. It's thus DFSG-free, even though it's > > strongly discouraged. > > Last week-end I was told by a DD that the 4-clause BSD licence was > non-free... Do you have any link in the archives which proves the > contrary? This is very interesting for me as I am interested in bringing > to Debian an unofficial package whose software is under this licence... I have a very urgent piece of work to do, so I won't dig the archives right now, but for example, openssl uses these words and is in main (although not GPL-compatible). Out of the top of my brain, http://fsf.org/licenses/, although it's a non-Debian source. I really dislike this license, it is dangerously close to the Gnon-FDL in this regard, but at least I don't see the right for unharassed advertising to be a fundamental freedom. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
On Fri, Aug 10, 2007 at 11:24:08AM +0100, David Given wrote: > Ben Finney wrote: > [...] > > That sounds like a bug. I was under the impression that the default > > encoding of everything in lenny was supposed to be UTF-8. > > > > What tool is it that has this different default encoding? > > Well, I tried UTF-8 with the assumption that it would work, and it threw up a > lintian warning and produced gibberish when viewing the man page (with default > 'man'). After searching the 'net I found this list in the LFS: > > http://www.linuxfromscratch.org/lfs/view/6.2/chapter06/man-db.html > > (See 6.45.2.) I would call this a bug, in Etch it was "only" "important". ANY file on a modern system installed by the distribution (and not in the user's private data, /mnt/win/ or an upstream source tarball) is bad for a number of reasons, mangling people's surnames being one of less important ones. All data files should be in UTF-8 (or UCS4, or any other format which does not include data loss). If an user then chooses to use a broken charset due to his/her historic preferences, so be it -- but you cannot inflict data loss on others. If man-db does this, it needs to be beaten with a large cluestick. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
On Sun, Aug 12, 2007 at 08:12:24PM +0900, Osamu Aoki wrote: > On Sun, Aug 12, 2007 at 08:09:06PM +1000, Ben Finney wrote: > > There's an important difference between "beat the program with a large > > cluestick" and "beat the person with a large cluestick". Adam's > > assertion was only that the former was necessary. > > Technically true. I'm terribly sorry if my post could be read as insulting the _maintainer_. >>> "If man-db does this, it needs to be beaten with a large cluestick." I believe this line was quite clear, but if it was not, please accept my apologies. The maintainer is fine, the state of man pages is not. > > If the person with the necessary clue is the package maintainer, they > > are more than welcome to issue the beating upon the software. This > > isn't an arrogant or insulting statement, because it's the software > > that is being declared clueless, not the person. > > But that still takes volunteer time and efforts for small benefit. Please. Don't say that avoiding the encoding hell is a "small benefit" anywhere someone from Poland or most eastern European countries. For example, most of old (>10 years old) data I see is encoded in Mazovia, then it's often win852, then win1250. Compared to the mix, UTF-8 is a silver bullet. The only real way to get rid of the encoding hell is to move everything into a single common encoding. > Even if it was UTF-8 encoded, if you do not have proper font installed, > you get "TOFU"(white box) on your screen. Please note man-db does > > $ LC_ALL=ja_JP.UTF-8 man man > > and displays correct text in English UTF-8 locale console if one has > Japanese font installed. If you can read Japanese, you're going to have Japanese font installed. If you don't, you won't really care. Yet, this is a large issue for those of us who use Latin scripts with characters not included in 8 bit charset of someone's choice. If you don't know what is the difference between "n" and "ń", you should still get it rendered at least as a "n". Iconv is perfectly capable of this feat (by //translit), yet it needs to get non-mangled data in in the first place. > (The source data is still in eucJP). And in my opinion that's exactly the source of problems we are seeing. > I was not comfortable since the poster did not even check the fact first > and bashed current quality of the software. The quality of software is > closely related to and inseparable from its upstream and its maintainer, > i.e., Colin in my eyes. The software doesn't support the official Debian's charset, that's the problem. Support for ancient encodings is optional, support for Unicode is not. So the current quality of the software is bad. Is this the maintainer's fault? Not really -- this is a large task, and it needs to see more effort thrown at it. So, let me start. Current state = The man pages have no encoding markers inside, encoding is currently derived partially from the language and partially from the user's charset. Unless they happen to be the same, manpages will be mangled unless they're written solely in 7-bit ASCII. Existing manpages = Among the manpages installed on the desktop box I'm writing these words on, I've got: 4511 purely 7-bit files 778 ones encoded in legacy charsets 23 wrongly (prematurely) encoded in UTF-8 Of course, those 23 ones are rendered similar to: "Michel Dänzer" instead of "Michel Dänzer" in radeon(4) "â’in 384u-216u" instead of "…" in piuparts(1) Issues to fix = A. man output B. groff processing C. man input Fixes for A. and B. are mostly local to "man-db", fixing C. would be a Debian-wide issue. My proposal for A. and B. = Unless someone comes up with a better idea, let's completely drop all support for non-UTF-8 locales (but read on) all the way on. That would eliminate the current complexity, leaving only one charset to maintain. Only at the very last stage the output would be passed to iconv //translit (_not_ iconv -c). The difference between //translit and -c is, the latter will blackhole characters while the former tries to find substitutes among the target charset first before resorting to using a question mark. German text: "Michel Dänzer" will yield "Michel Danzer" Polish text: "Gdański" -> "Gdanski" Japanese text: "? ??? ??? " -- at least you know something's there Source files As there are no markers inside the troff files, we can resort to a hack. If you check if the input is a properly encoded UTF-8 file, you can sometimes mistakenly recognize a file in a legacy charset as UTF-8. Yet, I ran a check on 1059 packages installed, and there wasn't a single false positive. Thus, it's a way to get proper UTF-8 support as of tomorrow. My proposal for C. == 1. Let's check the whole archive for false positives. Only if any packages would be found would there be any need for a transition. 2. Change "man"
Re: Man pages and UTF-8
On Sun, Aug 12, 2007 at 08:44:13PM -0700, Russ Allbery wrote: > Adam Borowski <[EMAIL PROTECTED]> writes: > > > Issues to fix > > = > > > A. man output > > B. groff processing > > C. man input > > > Fixes for A. and B. are mostly local to "man-db", fixing C. would be a > > Debian-wide issue. > > What I was trying to get at earlier is that I believe groff can't handle > UTF-8 input. So fixing B, if I'm correct, is certainly not local to > man-db. Yeah, it's mostly a groff issue. Yet, groff and man-db are very closely related. > I believe that fixing groff to handle multibyte character sets > property is a substantial amount of work. Of course. The thing is, Red Hat has already done this work. They also already converted all their man pages into UTF-8 in 2004. > groff can apparently produce UTF-8 *output*, but I think the encodings of > all of its input at the moment are in other character sets. The current Debian groff can produce UTF-8 output only for a narrow range of characters, ones which happen to be present in 8 bit charsets. It cannot handle UTF-8 input at all; on the other hand, Red Hat's version seem to be working just fine. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
(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...) 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? > Interested peoples should read #196762 An interesting read. > 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. UTF-8 input: works perfectly. dev utf8 works almost perfectly; we can change to 10 to get full Unicode coverage and mark u2..u2 as doublewidth to get rare Kanji formatted right. Neither of these are supported by euc_JP or any other legacy character set anyway. dev html works well for Latin1, Japanese and basic Chinese -- supports only characters it knowns. Trivially fixable by outputting either UTF-8, or, trading massive space waste for content-type independency, numbered HTML entities. Doesn't work for Latin2, Cyrillic, Greek, Arabic, etc without fixing. dev ps seems to be broken. My misconfiguration or real brokenness? dev dvi ditto dev latin1, dev nippon, etc supposed to be replaced by dev utf8. So with tty and HTML support working, it looks like input is just fine. > [CVS groff] > There is at least one remaining issue, which is that it does not recognize > family of glyphs. Thus all glyphs are considered of the same size (we > won't provide a font description file with the list of every UTF > characters), and thus the output of groff is ugly. Any such description file would work only as long as you hard-code any fonts, and somehow provide them for any potential reader. Without this, wcwidth() is as good as you can get for fixed-width fonts. For comparison, Red Hat makes a wild assumption that everything u0800..u is doublewide. > (Except for this issue, I could display nicely French, English, Japanese > and Vietnamese UTF-8 manpages) Cool, and what for Cyrillic, Arabic, Indic, etc? > I will port the part of ENABLE_MULTIBYTE which permits to specify ranges > of characters, and see if it looks OK. Do you want to assume that all characters within a family have the same width? Then it's better to give wcwidth() a try. > 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. > Note: the only real issue with lack of UTF-8 support for manpages in > Debian is that it is not possible to provide manpages translated in > languages whose only valid encoding is UTF (e.g. Vietnamese). > Otherwise our man-db/groff combination works really nicely and permits to > display manpages with very little annoyances (i.e. I don't consider having > to drop my cedilla in manpages to be a real issue). I do consider it to be one -- if you go carelessly in one place, you'll likely screw the characters where it really matters. Having "ń" in the name of my town, I'm tired of having billing address rejected because the bank expects "ń" but a form won't allow it; and while I can have stuff delivered to "Starogard Gdański", I pity the poor Russian schmuck who tries to mail-order something. Another real issue is the inability to talk about any non-Latin1 character in manpages. What about mans dealing with i18 stuff? But that is still not the biggest issue here. 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. > UTF-8 is supported on output, so it is really transparent for users. If you consider having all unsupported characters silently dropped as being transparent. I'll try to do what I can, but with my knowledge of groff being slim, I doubt I can even touch stuff like ps or dvi output. I attached my test manpage. It lacks test cases for combining chars and Indic scripts yet. Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's ra
Re: RHS: libterm-ansicolor-ruby
On Tue, Aug 14, 2007 at 09:53:12PM +0200, Nico Golde wrote: > * Deepak Tripathi <[EMAIL PROTECTED]> [2007-08-14 20:44]: > > libterm-ansicolor-ruby - Ruby library that colors strings using ANSI escape > > > sequences > [...] > > I am a bit curious why should someone not want to use curses > but ansi escapes in ruby? curses does only full-screen display, and is useless for anything line-based. And being capable of colouring your display is a MAJOR thing if you want to be able to read text quickly. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
On Tue, Aug 14, 2007 at 04:13:17PM -0700, Russ Allbery wrote:
> Adam Borowski <[EMAIL PROTECTED]> writes:
>
> > Any such description file would work only as long as you hard-code any
> > fonts, and somehow provide them for any potential reader. Without this,
> > wcwidth() is as good as you can get for fixed-width fonts. For
> > comparison, Red Hat makes a wild assumption that everything u0800..u
> > is doublewide.
>
> The correct thing to do is to use the information from the latest version
> of the Asian character width property table:
>
> http://www.unicode.org/Public/UNIDATA/EastAsianWidth.txt
> u0800..u is a bad approximation that misses several ranges and is
> actually wrong for most of the range up to u1100.
Except, the few scripts supported by old groff (Japanese, Chinese, Latin1,
...) have no characters handled wrongly in that range. It becomes a bug
only when we start to provide support for Indic and so on -- which we
certainly want.
> For another application, I use the approximation of:
>
> our @WIDE = qw(\x{2E80}-\x{303E} \x{3041}-\x{33FF} \x{4E00}-\x{9FBB}
>\x{AC00}-\x{D7A3} \x{FF01}-\x{FF60});
Heh. Similar here, I used
#define isw2width(x) ((x)>=0x1100 && ((x)<=0x11ff || \
(x)>=0x2e80) && ((x)<=0xd7ff || \
(x)>=0xf900) && ((x)<=0xfaff || \
(x)>=0xfe30) && ((x)<=0xfe6f || \
(x)>=0xff01) && ((x)<=0xff60 || \
(x)>=0xffe0) && ((x)<=0xffe6 || \
(x)>=0x2) && (x)<=0x2)
for portability to not depend on GNU-only wcwidth(), before I just copied in
wcwidth.c
>
> but even that is not a particularly good approximation compared to using
> the real table.
>
> My guess is that wcwidth's answer is based on the latest version of that
> table at the time that glibc released, although I'd have to double-check
> to be sure.
Yes: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
It has two different answers, based on the new and historic handling of
CJK Ambiguous characters. The new handling actually boils down to:
(ucs >= 0x1100 &&
(ucs <= 0x115f ||/* Hangul Jamo init. consonants */
ucs == 0x2329 || ucs == 0x232a ||
(ucs >= 0x2e80 && ucs <= 0xa4cf &&
ucs != 0x303f) || /* CJK ... Yi */
(ucs >= 0xac00 && ucs <= 0xd7a3) || /* Hangul Syllables */
(ucs >= 0xf900 && ucs <= 0xfaff) || /* CJK Compatibility Ideographs */
(ucs >= 0xfe10 && ucs <= 0xfe19) || /* Vertical forms */
(ucs >= 0xfe30 && ucs <= 0xfe6f) || /* CJK Compatibility Forms */
(ucs >= 0xff00 && ucs <= 0xff60) || /* Fullwidth Forms */
(ucs >= 0xffe0 && ucs <= 0xffe6) ||
(ucs >= 0x2 && ucs <= 0x2fffd) ||
(ucs >= 0x3 && ucs <= 0x3fffd)));
so our approximations were not far off. wcwidth() though will return 0 for
combining characters -- something important if support for Indic is a goal.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RHS: libterm-ansicolor-ruby
On Wed, Aug 15, 2007 at 04:02:57PM -, Thomas Dickey wrote: > The Fungi <[EMAIL PROTECTED]> wrote: > > > Of course, I can't imagine an ANSI library would be anything more > > than a few dozen string constant definitions, unless you wanted > > man tput > > (no point in hardcoding "a few dozen string" definitions, unless one > _likes_ the nasty comments that people make when they read the code ;-) I'm afraid the very concept of termcap/terminfo is thoroughly broken. It makes the following assumptions: * all TERM strings are known to all machines. Mere ssh will break otherwise. And even after all these years, Solaris still doesn't know what TERM="linux" means (the last time I checked it didn't, at least). * TERM strings are unique. Because of the above, no one who makes a terminal emulator will use a real string as it would make his terminal useless. Thus, anything popular uses either: + "xterm": - xterms of all Unices -- no matter what differences between them are, often interpreting vt100+ codes in creative ways (compared to how I would read the docs), - libvt based stuff (totally incompatible with xterms), - konsole and derivatives (totally incompatible with the rest _and_ buggy) - PuTTY (one of the best nowadays, used to be terrible) + "rxvt": - aterm, wterm, etc. None of them sync bugfixes with the others. + "linux": - real Linux text console. + "vt100": - physical terminals, even if they're rather vt19578394. + "screen": - reinterprets everything in its own dialect, usually for good results, sometimes for bad. In other words, "TERM" is totally useless. How is it supposed to tell me that I have to write spaces to every position instead of usual means of clearing the screen if bgcolor isn't transparent (older putties) -- and even if it could, neither termcap nor terminfo have means to convey this info. Or, do I need to restore the \e[???m attrs after moving the cursor (libvt in some cases)? Or, what are the effects of \n on the line right to the cursor? Or, how to be told if arrow keys pressed are Kpad ones or the new-style "gray" ones? >From my own experience, the only way to get decent portability is, ironically, hard-coding a certain subset of vt100ish codes. Querying termcap/terminfo tends to lose rather fast in comparison. So there's no point in using tstuff unless one _likes_ the nasty comments that people make when they try to either use the program or read the code ;-) -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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/
Re: Man pages and UTF-8
On Tue, Sep 11, 2007 at 09:55:44AM +0100, Colin Watson wrote: > > 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"... > > If you do work on patches, please make sure they're against current bzr; > there have been a lot of changes since 2.4.4. Noted. > > > 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. > > No, we don't. Seriously, I understand the problem and it's not > necessary. man-db can stick iconv pipes in wherever it likes and it's > all fine. When we upgrade groff at some future point we can just declare > versioned dependencies or conflicts as necessary, but it is *not* > necessary for this transition. A basic rule of release management is > that the more you decouple the easier it will be. Yet if groff cannot accept any encoding other than ISO-8859-1 with hacks for ja/ko/zh, you end with data loss for anything not representable in 8859-1. > > 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. > > (Point of information: Red Hat doesn't use man-db.) I didn't look that far, I didn't bother with installing a whole Red Hat system, just did: ./test-groff -man -Tutf8 http://angband.pl/deb/man/test.png > Thus what you're saying seems to be that Red Hat uses the ascii8 device, > or its equivalent (ascii8 passes through any 8-bit encoding untouched, Actually, their -Tascii8 is completely broken, they use -Tutf8 instead. > although certain characters are still reserved for internal use by groff > which is why it doesn't help with UTF-8). groff upstream has repeatedly > rejected this as typographically wrong-headed; I don't want to > perpetuate it. groff is supposed to know what the characters really are, > not just treat them as binary data. I fully agree. The multibyte patch for 1.8 (which Red Hat refers to everywhere as "the Debian patches") lets groff store characters as Unicode code points; the input/output issues are what we're trying to fix in this thread, and properties of particular characters are an orthogonal matter. > Obviously we have to cope with what we've got, so ascii8 is a necessary > evil, but it is just plain wrong to use it when we don't have to. So let's skip it? > > 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). > > None of this is immediately necessary. Leave groff alone for the moment > and the problem is simpler. iconv pipes are good enough for the time > being. When we do something better, it will be a proper upgrade of groff > converging on real UTF-8 input with proper knowledge of typographical > meanings of glyphs (as upstream are working on), not this badly-designed > hodgepodge. Isn't reading input into a string of Unicode codepoints good enough for now? It's a whole world better than operating on opaque binary strings (ascii8), and works well where RTL or combining chars support is not needed. > > Yet: > > [~/man]$ grep ^U mans.enc |wc -l > > 843 > > [~/man]$ grep ^U mans.enc |grep '\.UTF-8'|wc -l > > 21 > > > > So you would leave that 822 manpages broken. > > If the alternative is breaking the 10522 pages listed in your analysis > that are ISO-8859-* but not declared as such in their directory name, > absolutely! Yeah, breaking those 10522 pages would be outright wrong. But with a bit of temporary ugliness in the pipeline we can have both the 10522 ones in legacy charsets and the 822 prematurely transitioned working. > > 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. > > So, last night I was thinking about this, and wanted to propose a > compromise where we recommend in Debian policy that pages be installed > in a directory that explicitly specifies the encoding (you might not > like this, but it makes man-db's life a lot easier, it's much easier to > tell how complete the transition is, and it's what the FHS says we > should do), but for compatibility with the RPM world we transparently > accept UTF-8 manual pages installed in /usr/share/man/$LL/ anyway. So you would want to have the old ones put into /usr/share/man/ISO-8859-1/ (or man.8859_1) instead of /usr/share/man/? That would work, too. I'm opposed to spelling /usr/share/man/UTF-8/ in full on aesthethic grounds, as the point in Unicode is to forget something called "charset" which needed to be set
Re: Making mentors.debian.net a .org
On Fri, Jan 20, 2012 at 01:07:02AM -0500, Michael Gilbert wrote: > On Thu, Jan 19, 2012 at 6:47 AM, Arno Töll wrote: > > That's the plan, but again: tracking sponsor requests as bugs, and > > integrate mentors.debian.net into Debian are unrelated problems. Any > > proposal can be implemented without touching the status-quo of the other. > > They are intimately related as we need a pseudo-package to even begin > the bug-based workflow, and that needs to be a .org. So the official > domain is required first. I fail to see any connection between the domain name and pseudo-package, unless you somehow want to name it "debian-mentors.XXX.org" rather than just "debian-mentors". This reeks of "openoffice.org" as the package name. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Re: RFS: gcc-4.5-doc-non-dfsg
On Sat, Jan 21, 2012 at 05:09:35PM +0100, Jakub Wilk wrote: > * Samuel Bronson , 2012-01-21, 00:38: > >* Package name: gcc-4.5-doc-non-dfsg > > Does "non-dfsg" really need to be a part of source package name? > What if FSF decides to free the documentation one day? Then this source package will disappear, and its binary will be built from pristine gcc sources. It contains parts that have been removed from gcc-4.5, all of them are non-free due to GFDL issues. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Re: What is autobuilder? Please help me understand this bug.
On Wed, Jan 25, 2012 at 12:20:12AM -0600, Paul Elliott wrote: > > Source: libswe > > > > Automated builds of libswe are failing because unoconv (used to > > produce PDF and HTML documentation) assumes a writable home directory, Seems like a matter of setting HOME=`pwd` > > Given that the documentation winds up in a separate > > architecture-independent binary package anyway, I'd suggest arranging to > > build it only in full builds, which presumably run in less restrictive > > environments. This won't fix the bug, merely let official buildds proceed. Every single package is supposed to be autobuildable, not merely arch-dependent ones. > For instance, libswe just appeared in debian unstable, that means someone > must have built it. Your sponsor did, by hand, on i386. > How does the build environment of the autobuilder's differ from the one > that built libswe on its path to unstable? It hasn't been built in a controlled environment anywhere yet. You can approximate one using pbuilder. > Why is the autobuilder's environment correct? In other words, why is this > not a bug against the autobuilder's software? You shouldn't assume any directory outside of your build path and /tmp/ is writeable. Here, the bug appears to be in unoconv (if the report is correct, which I did not check), yet it can be trivially worked around by setting $HOME. > What is a "full" build and can I be sure that a full build will never > occur in the autobuilder? Every package must be fully buildable from source -- as in, every binary package must be reproduceable depending on nothing you did not explicitely declare in Build-Depends (-Indep, -Arch) and build-essential. > If I make a fix to this problem, how can I test that it will work in the > autobuilder's evnironment? pbuilder is not 100% identical but should be good enough. And a FTBFS in pbuilder is bad enough. Hope this helps. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: RFS: bibtool
On Thu, Jan 26, 2012 at 12:14:15PM +0100, Jerome BENOIT wrote: > The debian/copyright was corrected as well: > lintian failed to detect non ASCII chars. Because they're perfectly fine. You're not supposed to mangle the names of copyright holders, etc. It should use UTF-8. I somehow can't seem to find a policy paragraph specifying this (an omission?), but at least common sense specifies that :p -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120126152300.ga14...@angband.pl
encoding of the copyright file (was: Re: RFS: bibtool)
On Fri, Jan 27, 2012 at 06:30:11PM +0900, Charles Plessy wrote: > Le Thu, Jan 26, 2012 at 04:23:00PM +0100, Adam Borowski a écrit : > > On Thu, Jan 26, 2012 at 12:14:15PM +0100, Jerome BENOIT wrote: > > > The debian/copyright was corrected as well: > > > lintian failed to detect non ASCII chars. > > > > Because they're perfectly fine. You're not supposed to mangle the names of > > copyright holders, etc. > > > > It should use UTF-8. I somehow can't seem to find a policy paragraph > > specifying this (an omission?), but at least common sense specifies that :p > > And in the particular case of this package, that uses the machine-readable > copyright format, it is indirectly mandated by the Policy: > > DEP 5: The syntax of the file is the same as for other Debian control files, > as specified in the Debian Policy Manual. See its section 5.1 for > details. > > Policy §5.1: All control files must be encoded in UTF-8. DEP5 isn't mandatory. Before requesting this to be added to the policy, I wanted to check how many packages fail this requirement. There are 65, here's dd-list: Alexander Wirt pytone Alexandre Fayolle pyqonsole Ana Beatriz Guerrero Lopez cycle empy Anders Hammarquist sformat Andreas Barth rp-pppoe Bill Allombert gap-ctbllib gap-gdat Brian Nelson aspell-is aspell-sk Carlo Segre libdatetime-format-mail-perl (U) libmath-round-perl (U) Clint Byrum mysql-5.5 (U) Damyan Ivanov libdatetime-format-mail-perl (U) David Martínez Moreno libmpeg3 linux-ntfs Debian CLI Applications Team monodevelop Debian KDE Extras Team dvr Debian MySQL Maintainers mysql-5.5 Debian Perl Group libdatetime-format-mail-perl libmath-round-perl Debian QA Group lightspeed twisted-web2 Decklin Foster yafc Dominic Hargreaves libhtml-mason-psgihandler-perl Enrique Monge wmtictactoe Eric Madesclair le-dico-de-rene-cougnenc Esteban Manchado Velázquez pica picalib Florian Hinzmann libxml-dumper-perl Francois Gurin wmlongrun Frederic Schutz w3c-dtd-xhtml Free Ekanayaka polymer (U) Georges Khaznadar wims-extra GOTO Masanori lha plum xfonts-kappa20 xfonts-mplus xfonts-shinonome gregor herrmann libdatetime-format-mail-perl (U) Gregory Colpart (evolix) php-file Gürkan Sengün aclock.app Gürkan Sengün aclock.app Hamish Moffatt sortmail Itamar Almeida de Carvalho libxml-dt-perl Ivan Kohler libpod-simple-wiki-perl libtaint-util-perl Jaldhar H. Vyas libdatetime-format-mail-perl (U) Javier Fernandez-Sanguino Pen~a nat spellcast-doc vrrpd Jo Shields monodevelop (U) Laszlo Boszormenyi (GCS) manpages-hu sidplay-base Lionel Elie Mamane scsh-defaults Marcela Tiznado cadubi Mark Purcell dvr (U) Mathias Krause polymer Mickael Profeta tetex-frogg Mike Furr wmressel Mike Markley gkrellm-leds Mirco Bauer monodevelop (U) Miriam Ruiz cycle (U) Mohammed Adnène Trojette ooo2dbk Monty Taylor plywood Norbert Tretkowski mysql-5.5 (U) OHURA Makoto apt-show-source Pawel Wiecek crack doc-linux-pl Pierre Machard doc-linux-fr Python Applications Team cycle (U) Richard Holland libwww5.808-perl Sam Hocevar (Debian packages) tmview Shane Wegner dotconf Stefan Hornburg (Racke) dbix-easy-perl Steffen Moeller libwww5.808-perl (U) Thomas Bläsing python-libpcap Thomas Goirand extplorer Víctor Pérez Pereira perl-byacc Yu Guanghui zh-autoconvert -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: encoding of the copyright file
On Sat, Jan 28, 2012 at 12:36:23AM +0100, Adam Borowski wrote: > On Fri, Jan 27, 2012 at 06:30:11PM +0900, Charles Plessy wrote: > > Le Thu, Jan 26, 2012 at 04:23:00PM +0100, Adam Borowski a écrit : > > > On Thu, Jan 26, 2012 at 12:14:15PM +0100, Jerome BENOIT wrote: > > > > The debian/copyright was corrected as well: > > > > lintian failed to detect non ASCII chars. > > > > > > Because they're perfectly fine. You're not supposed to mangle the names > > > of > > > copyright holders, etc. > > > > > > It should use UTF-8. I somehow can't seem to find a policy paragraph > > > specifying this (an omission?), but at least common sense specifies that > > > :p > > [DEP5] > > Policy §5.1: All control files must be encoded in UTF-8. > > DEP5 isn't mandatory. > > Before requesting this to be added to the policy, I wanted to check how many > packages fail this requirement. > > There are 65, here's dd-list ... and while writing a lintian check, I noticed it's already there: debian-copyright-file-uses-obsolete-national-encoding -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: Providing a non-free alternative to a free package
On Wed, Feb 08, 2012 at 10:32:16AM -0800, Don Armstrong wrote: > On Wed, 08 Feb 2012, Olе Streicher wrote: > > This is something I have to discuss with the upstream author (who > > also sells the unobfuscated version). He probably would then make a > > specific license which would allow its distribution, but he is not > > willing to put the original source code under GPL. > > A license like MIT or Expat or another free non-copyleft license would > work. However, as it is now, Debian cannot comply with the license > terms to distribute the work at all, so it cannot go even into > non-free. Is slalib the contents of libraries/sla/ in the repository you linked to? If so, it appears the current upstream is not the sole copyright holder, and there are many other contributors dating from 2004 for sla, and 1989 for the project as a whole (counting only versioned history). This means, it is illegal to distribute the obfuscated version for anyone (including current upstream), and anyone who buys the unobfuscated one can pass it further under GPL. (This is only from looking at the version control, it's possible the proprietary version was correctly unliberated.) -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Tue, Feb 14, 2012 at 03:02:43PM -0500, Samuel Bronson wrote: > On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson wrote: > > On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko > > wrote: > > >> In good old days when I had time and motivation to maintain gcc-doc, I've > >> used git repos to managed entire thing. > > I'm holding off on updating the 4.4 control files and the -defaults > packages for the moment: I want to streamline the "new X.Y" process a > bit more first. Good, as there's 4.7 in experimental already. Not officially released and ICEs like hell, but it's meant to release soon... -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: fastest hack-build-run iteration
On Tue, Feb 21, 2012 at 09:58:45AM +0100, Joachim Wiedorn wrote: > Paul Wise wrote on 2012-02-21 09:28: > > On Tue, Feb 21, 2012 at 8:40 AM, David Roguin wrote: > > > > > I'm making some changes to the evolution package and every time I want > > > to test a tiny change I build a deb, install and run it. As you can > > > imagine that takes a lot of time. Are you testing changes to packaging or actual code? If the latter, I'd run the non-installed binary directly from the build dir. It probably expects support data but that's already installed (unless you changed that as well). If it's a library, you can LD_PRELOAD the new version. > > maint-guide used to recommend running ./debian/rules binary for that, > > not sure if it does now. > > And use ccache for using compiling results for the next time. If the package's makefile is sane, ccache is not needed since unchanged files won't be recompiled. And evolution uses automake which produces sane makefiles (at least in this regard). Too bad, in this case, a no-change rebuild still takes 1/4 of time needed for a clean build. It seems it's mostly: 1. installing mo files 2. dh_shlibdeps 3. debhelper/dpkg-dev It doesn't seem to me you can avoid especially 2. and 3. easily. (And no, I'm not proposing to replace 3. with fine techniques in http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc ☺). If you weren't using cdbs, debhelper can speed up things quite a bit with --parallel[¹], especially for packages with multiple binaries like evolution. And hey, these days if you don't have multiple cores, your phone is aged. [¹]. You need to export DEB_BUILD_OPTIONS=parallel=`grep ^processor /proc/cpuinfo|wc -l` as well, but that's something which should have been the default everywhere but on buildds. Packages that are not marked as parallelizable won't be affected so it's a safe thing to do. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: Mathgl build failure
On Fri, Feb 24, 2012 at 07:13:11PM +0100, Savvas Radevic wrote:
> > mgl_eps.cpp: In member function 'virtual void mglGraphPS::WriteEPS(const
> > char*, const char*)':
> > mgl_eps.cpp:308:55: error: conditional expression between distinct pointer
> > types 'gzFile' and 'FILE* {aka _IO_FILE*}' lacks a cast
> > mgl_eps.cpp:456:19: error: invalid conversion from 'void*' to 'gzFile' [-
> > fpermissive]
> > /usr/include/zlib.h:1488:24: error: initializing argument 1 of 'int
> > gzclose(gzFile)' [-fpermissive]
> >
>
> There's a similar error here:
> https://aur.archlinux.org/packages.php?ID=16851&detail=0&comments=all(Under
> "Comment by: ShadowKyogre on Mon, 06 Feb 2012 03:49:32 +")
>
> They suggested to add to the CXX_FLAGS "-fpermissive":
... which only papers over the bug instead of fixing it. The warning is
correct: this line:
void *fp = gz ? gzopen(fname,"wt") : fopen(fname,"wt");
tries to mix completely unrelated types. Both happen to be pointers but not
even that is guaranteed (gzFile is documented as an opaque type).
C allows implicit casts between void* and any pointer type (but not between
two distinct pointer types like in your ?: case!), C++ doesn't allow that.
A quick fix would be adding explicit casts. This may break on strange
architectures where, for example, pointers to objects of different size
cannot be mixed, but AFAIK it's enough on all Debian archs.
BTW, in your packaging, the "binary" target doesn't depend on "build", which
breaks Policy 4.9.
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
signature.asc
Description: Digital signature
Re: obsolete uploads to debian stable?
On Sat, Feb 25, 2012 at 07:05:36PM -0600, Paul Elliott wrote: > > Is there any archive where I can get obsolete superseded uploads to debian > unstable? I need to get one for historical reasons. snapshot.debian.org -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
ITAs on packages you intend to remove
Hi! One of my packages, tcng, is long dead upstream, and without upstream work it goes less and less usable. Thus, a while ago I decided to RFA it, intending to ask for removal if no one steps up before Wheezy. Someone (Jakob Haufe) did in september, but I haven't heard from him since. Due to an recent change in TeX, tcng started to FTBFS (#666336). The fix here is trivial, but I don't know whether it wouldn't be better to just proceed with asking for removal instead. I asked the ITPer (bug trace: ##612930) whether he'll take it over soon, take it over later but before Wheezy or not at all; I didn't get an answer. It's been only five days, though. Should I bother you with sponsoring an upload fixing the FTBFS (with the package likely going away soon), file a RM immediately, or ignore it for now? There's a yet another option, fixing the FTBFS and doing other minimal life support so the few remaining users (32 popcon votes) can have it in wheezy (tcng can't use any new improvements to netfilter, but old ways still work) -- perhaps I could make a final upload now and not remove it until after wheezy, looking if Jakob comes back? Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Bug#667092: RFS: tcng/10b-4 [RC, QA]
Package: sponsorship-requests
Severity: important
Hi, it turns out the person who wants to adopt this package is alive after
all, but won't have time soon. Thus, I'm making a last upload, orphaning
the package, fixing the new FTBFS and doing some minor clean-up.
The changelog entry:
tcng (10b-4) unstable; urgency=low
* Add textlive-latex-recommended to Build-Depends, needed for url.sty
(Closes: #666336).
* Bump standards to 3.9.3 (no changes), debhelper to 8 (dh_prep).
* Fix CFLAGS and LDFLAGS being ignored, get them from dpkg-buildflags.
* Implement missing build-{arch,indep}.
* Orphan the package.
Dgettable URL:
dget -x http://mentors.debian.net/debian/pool/main/t/tcng/tcng_10b-4.dsc
Popcon: 235 inst, 32 vote.
If someone could sponsor this, it'd be nice.
signature.asc
Description: Digital signature
Re: Bug#667092: RFS: tcng/10b-4 [RC, QA]
On Wed, Apr 04, 2012 at 01:04:28AM +0200, Arno Töll wrote: > On 04.04.2012 00:50, Adam Borowski wrote: > > * Orphan the package. > > if your intention is to orphan the package you should set the > maintainer to "Debian QA Group ", too. > > I didn't look any further but this was drawing my attention. Fixed, re-uploaded, thanks for noticing. Lintian now complains: W: tcng source: changelog-should-mention-qa but this seems wrong -- it's this very upload that is orphaning the package; lintian has no real way to know that, though. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: Bug#667092: RFS: tcng/10b-4 [RC, QA]
On Wed, Apr 04, 2012 at 01:21:55AM +0200, Arno Töll wrote: > On 04.04.2012 01:19, Adam Borowski wrote: > > Lintian now complains: W: tcng source: changelog-should-mention-qa > > but this seems wrong -- it's this very upload that is orphaning the > > package; lintian has no real way to know that, though. > > Just add "* QA Upload" to the changelog entry to make Lintian shut up. Should I be rather Lintian correct, or what-seems-to-be-right correct? This one seems to be on the edge, as the last maintainer upload. Still, a changelog line doesn't really break things any way. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: Bug#667092: RFS: tcng/10b-4 [RC, QA]
On Wed, Apr 04, 2012 at 12:55:32PM -0400, David Prévot wrote: > Le 04/04/2012 06:38, Adam Borowski a écrit : > > > Should I be rather Lintian correct, or what-seems-to-be-right correct? > > Reading the long description usually helps: > > > $ lintian-info --tags changelog-should-mention-qa > > W: changelog-should-mention-qa > > N: > > N: If this upload is to orphan this package, please mention this fact on > > N: the first line of the changelog. If this is a QA upload, please > > N: mention "QA (group) upload" there. Beh, so the order of changelog lines matters? I've read this description but never suspected this is actually the case. Fixed. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: [Uploaded] RFS: jquery-jplayer/2.1.0-1
On Mon, May 14, 2012 at 11:37:31AM +0200, Pau Garcia i Quiles wrote: > Next I'm going to package the jPlayer skins (Blue Monday and Pink > Flags). I'm not exactly versed in licenses for artwork but MIT/GPL for > a GIF animation and PSD files looks wrong. Typically it's XCF or PSD files that are the preferred form of modification for images, so this sounds just right to me. GPL can apply to any software, not just programs. GIFs tend to be a flattened/reduced version from some source, but since so many people throw away intermediate files (sadly, often me included), it's plausible the GIF is the best extant form for modification. And you can edit it, so there are no big GPL/DFSG issues. If you include an OGG sound effect of a cat's meow in a GPLed work, no reasonable person will demand including the cat even though it's the real source... -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: How to build flavored package if upstream doesn't grok OOT build
On Sat, Jun 23, 2012 at 03:23:03PM +0200, Arno Töll wrote: > On 23.06.2012 15:17, Marc Haber wrote: > > How can I build two flavors of a program with different configure > > parameters if upstream does not properly handle out-of-tree building > > and I do not want to ditch dh? > > You copy the source tree as a preparation and recurse into all flavors > for the configure/build/(install) stages. Take a look at the Apache 2.2 > source package for a (complex) example. Better: link it. If you want to be able to resume partial builds as well, the rules are: tree-stamp: dh_testdir mkdir flavour1 cp -ldpR dir1 dir2 dir3 flavour1/ mkdir flavour2 cp -ldpR dir1 dir2 dir3 flavour2/ touch tree-stamp -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120623141844.ga26...@angband.pl
Re: freeze policy - open requests for sponsorship
On Mon, Jul 02, 2012 at 09:06:25AM -0600, Paul Wise wrote: > Perhaps use wheezy-ignore for stuff that shouldn't be in wheezy? Isn't that completely contrary to that tag's usual meaning? You set it for stuff that should be in wheezy despite the bug. What we'd want here, is some way to convey "do not waste your time messing with this bug if you care only about the next stable release". This includes unstable-only packages like gcc-snapshot. -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702234122.ga13...@angband.pl
Re: upstream changelog at website only
On Tue, Jul 17, 2012 at 10:24:07AM +0200, Simon Chopin wrote: > Quoting Jerome BENOIT (2012-07-17 10:11:16) > > The upstream source package contains no changelog file, > > but the library website provides matter to extract one for it. > > > > I guess that I may have to extract the changelog file from the website: > > may I forget it ? > > A debian source package should be self-contained, which means that it > should not rely on any resource outside of the source itself and its > build-dependencies. If you'd download something off the internet, it > would mean that rebuilding your package with the same system would not > necessarily produce the same outcoming binary packages. Plus, there are > buildds without Internet access. > > I'd contact upstream to see whether they would include the changelog in > the tarball from the next release on, but in the mean time just don't > worry about it, I don't think any potential sponsor will hold that > against you. I'd ship the upstream changelog inside your packaging instead. -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 signature.asc Description: Digital signature
Re: RFC: xinetd autoreconf
On Fri, Jul 27, 2012 at 09:28:49AM +0200, Salvo Tomaselli wrote: > the current package has a patch that basically is a replacement of the > configure script. The patch is extremely complicated and i guess not really > meant for human eyes. > > What i was trying to do is to use dh_autoreconf and have the configure script > regenerated automatically instead of including a patch i can't check. > > But the autoreconf command fails. I've tried multiple versions and it always > fails giving a long list of warnings about missing template and then > > autoreconf: /usr/bin/autoheader failed with exit status: 1 Ie, the package is shipping code without source. A "configure" script is as far away from something readable/editable as you can be while still using shell. I don't think anyone can possibly call it "a preferred form for modification" with a straight face. Yet another example why --disable-maintainer-mode is bad. -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120727150302.ga13...@angband.pl
Re: vector format and freesofware
On Fri, Sep 21, 2012 at 11:11:52AM +0800, Paul Wise wrote: > On Fri, Sep 21, 2012 at 9:30 AM, Mohsen Pahlevanzadeh wrote: > > > Which of vector format of pic are FOSS? such as svg? > > The format of vector images isn't relevant, the license is what makes > a vector image FOSS or not. And often, the ability to manipulate the image with free tools. -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120921031912.ga18...@angband.pl
Re: Bug#680546: RFS: cinnamon/1.6.1-1 [ITP] -- Innovative and comfortable desktop
On Fri, Sep 28, 2012 at 05:56:49PM +0200, Nicolas Bourdaud wrote: > I am looking for a sponsor for my package "cinnamon" for experimental. Why experimental? That'd just mean you will need an extra unnecessary upload. As there's no old version of cinnamon in Debian, shunting it to experimental doesn't make sense (unless the package is actually unfit for unstable yet). -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929110616.ga20...@angband.pl
Bug#693249: RFS: etw/3.6+svn140-4 [RC] [ITA] arcade-style soccer game
On Sat, Nov 17, 2012 at 05:25:35PM -0500, Michael Gilbert wrote:
> I've just reviewed this, and it looks mostly good. I did notice
> things like the following:
>
> + FILE *f;
> ++char path[1024];
> ++sprintf(path, "%s/%s", getenv("HOME"), ".etw/etw.cfg" );
> + D(bug("Reading configuration...\n"/*-*/));
>
> Note that a hardcoded 1024 isn't very portable. C defines PATH_MAX
> for this purpose. Please use that instead.
1024 is more portable than PATH_MAX...
This define should have died a couple of decades ago, and it's kept only for
compat purposes. If you use it, you'll get a FTBFS on Hurd, as they decided
to force the issue and get rid of the blighter.
You can sometimes get suggestions to use pathconf(_PC_PATH_MAX), which is
even worse, as you'd be dynamically allocating a static buffer.
And obviously, the code above has a buffer overflow, no matter if you use
1024 bytes or PATH_MAX. You'd want asprintf() or an equivalent.
--
How to squander your resources: those silly Swedes have a sauce named
"hovmästarsås", the best thing ever to put on cheese, yet they waste it
solely on mere salmon.
signature.asc
Description: Digital signature
Re: manual pages
On Mon, Mar 16, 2009 at 10:00:26PM +0800, Chow Loong Jin wrote: > On Mon, 2009-03-16 at 14:53 +0100, Jaromír Mikeš wrote: > > having problem to build package with manual pages. > > I edited and rename manpage.1.ex > jnoise.1 > > Also uncomment line "dh_installman" in debian/rules "binary-indep" section > > > > But when I install package there are not man pages > You need to add debian/jnoise.1 into debian/packagename.manpages. If it > doesn't exist, create it. Or, saving an unnecessary file, specify it on the command line of dh_installman. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: upload key error
On Wed, Mar 18, 2009 at 01:33:44PM +0100, Grammostola Rosea wrote: > upload error: > > /var/cache/pbuilder/result$ dupload -t mentors rumor_1.0.3b-1_i386.changes > dupload note: no announcement will be sent. > Checking signatures before upload...GPG signature is missing > dupload fatal error: Pre-upload '/usr/share/dupload/gpg-check %1' failed > for rumor_1.0.3b-1_i386.changes > at /usr/bin/dupload line 223 You'd need to "debsign rumor*.changes" first. Of course, that requires a valid gpg key, but it doesn't have to be signed by a DD or anything. Rawr! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: kbtin (new)
Meow? I'd like to ask for a sponsor for new package "kbtin". It's a MUD client, something that once was deemed dead, but judging by a recent influx of support requests, it is certainly not dead yet. Apparently, some people still prefer books (text games) to TV (mmorpgs). The package is lintian clean, ITP is #213361. It can be grabbed from: URL: http://mentors.debian.net/debian/pool/main/k/kbtin deb-src http://mentors.debian.net/debian unstable main dget http://mentors.debian.net/debian/pool/main/k/kbtin/kbtin_1.0.13.1-1.dsc It's a fork of existing package tintin++, however, these two have forked over 13 years ago so the codebase has little in common. Compared to tintin++, KBtin has: * no known buffer overflows (tintin++ has one for almost every command!) * SSL support * better Unicode support, also support for server charset different from client * handling of half-messages (split on network packet boundary) * running local commands (#run a debuild) and so on. Uploading this can increase your coolness score! Mrraow. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Use, "Depends: locales-all|locales" or not
On Thu, Jan 07, 2010 at 09:50:23AM -0800, Russ Allbery wrote: > The problem is that Lintian depends on locales, but it doesn't just depend > on the locales package. Having locales installed doesn't help. Lintian > specifically depends on having a UTF-8 locale available. > > The best solution is to do something that ensures a C.UTF-8 locale is > always available. This would also help other problems in Debian. Hell yeah. Get the glibs folks to make C.UTF-8 built-in like "ISO-8859-1" and "koi8-r" used to be, and you'll be my hero. In the past, those were removed since they shouldn't be special cased above all other locales -- but it's long overdue to give UTF-8 preferential treatment. And since the set_locale() call has to read multiple files, it takes over 20% of typical process startup+shutdown time. > Absent that, we're considering adding some sort of ugly hack to Lintian to > force the locales package to generate a UTF-8 locale if one isn't already > available. Unfortunately, there's no straightforward way to do that in > Debian without doing things that are kind of questionable. You can tell it to generate a locale to a local dir. mkdir -p locales localedef -i en_US -c -f UTF-8 locales/en_US.UTF-8 LOCPATH=`pwd`/locales your-thing-to-do -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: go
On Thu, Mar 18, 2010 at 01:25:21PM +0100, Dominique Dumont wrote: > On Thursday 18 March 2010 11:27:16 Ivan Wong wrote: > > * Package name: go > > It builds these binary packages: > > go - Google's Go programming language compiler > > Hmm, when I've the the subject of this mail, My first thought was about the > venerable go game. In a software distribution, computer languages should get strong priority over games. You don't say "C-lang" or "perl-lang". -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100319090836.ga26...@angband.pl
Re: migration to testing
On Tue, Apr 06, 2010 at 01:05:52AM +0400, Stanislav Maslovski wrote: > As the original poster of that question on debian-mentors, I would > like to ask anyone who has access to a Debian/kFreeBSD installation to > test if fuse-convmvfs from sid works there (provided that fuse4bsd is > installed). My package builds on that architecture just fine, but > unfortunately I cannot test myself if it works there. Just install it yourself in virtualbox (slow, always works) or kvm (requires hardware support). I just lost several hours today trying, so here's a list of pitfalls: * You need to change the virtual network card. VirtualBox's default, "PCnet-FAST III (Am79C973)", is recognized by kfreebsd but doesn't see the network. "PCnet-PCI II (Am79C970A)" works fine. * You need a particular d-i build: http://d-i.debian.org/daily-images/kfreebsd-i386/20100221-11:20/monolithic/ (I assume -amd64 works too). Current d-i dailies are broken (the partitioner fails, even with a pre-partitioned disk, not letting you assign mount points). Don't use the sysinstall images either (they install but filesystem operations randomly fail). Rumours that d-i builds 20100306 or 20100223 are ok are untrue as well (won't even boot past the splash screen). -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100405230539.ga32...@angband.pl
Re: RFS: xburst-tools
On Sat, Jun 05, 2010 at 12:38:15PM +0800, Paul Wise wrote: > On Sat, Jun 5, 2010 at 12:13 PM, Jonathan Nieder wrote: > > This part was my doing, sorry. It should be possible to build these > > on mipsel [...], but that makes it difficult for people without access > > to a non-pocket-sized MIPS machine to test the build process. From > > > > http://db.debian.org/machines.cgi?sortby=architecture&sortorder=asc > > > > I infer that there is not even a mipsel porterbox available to DDs. > > A temporary solution to this would be to find a sponsor with a Debian > mips/mipsel install on MIPS hardware. Is there any reason qemu-mipsel isn't good enough? You can find a detailed howto at: http://www.aurel32.net/info/debian_mips_qemu.php but if you want just an usable system ASAP, go straight to: http://people.debian.org/~aurel32/qemu/mipsel/ and two wgets and apt-get install qemu later, you're one command away from fully working lenny. It's not a speed demon so dist-upgrade further will take a while, but then, the real thing isn't fast either... Meow! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: RFS: xburst-tools
On Sat, Jun 05, 2010 at 07:59:58PM +0800, Paul Wise wrote: > On Sat, Jun 5, 2010 at 7:21 PM, Adam Borowski wrote: > > Is there any reason qemu-mipsel isn't good enough? > > There was a concern (flamewar) a few years ago that doing that would > result in broken binaries. I don't know how true that would be today > or if it is now consider acceptible. qemu-user-*, I can understand that. But qemu-system-*, which emulates the whole machine? Unless there is some insidious bug in qemu which shows up only for some rare opcode or for some corner case of hardware access, I can't see how it is supposed to produce broken binaries. Unless you get close to the metal, things either work or not. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100605122112.ga7...@angband.pl
Re: reinclude removed package: soci
On Sat, Sep 04, 2010 at 05:29:00PM +0200, Julian Taylor wrote: > Hi, > the soci library (C++ Database Access Library [1]) has recently been removed > from the testing archives[2]. > Now I would like to adopt this package. I have familiarized myself with > packaging and am in contact with upstream. > But I am not clear about the procedure to get it back into debian. > Do I file a ITP bug or do I reopen the orphan bug? You already properly retitled it to ITA (#583846). It was then closed by a ftpmaster when the package was removed, but it appears to be done in a (semi-?)automated way, without any ill will towards you. I'd just reopen it. > Also it only had one minor bug filed against it (which can be fixed easily) > and was removed a just few days ago. > Is it to late to get it back into squeeze? The rules for migrating to testing are pretty strict now, so I'm afraid that yeah. Meow! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100904213406.ga15...@angband.pl
Re: Include 0AD, a new fancy 3D RTS
On Wed, Sep 08, 2010 at 03:40:53PM +0200, Johan Van de Wauw wrote: > On Wed, Sep 8, 2010 at 9:38 AM, Vincent Fourmond wrote: > > > DXT compression is based on Simon Brown's squish library. The library > > also contains an alternative GPU-accelerated compressor that uses CUDA > > and is one order of magnitude faster. > > > > This might make it not suitable for main, since DXT seems to be patented: > https://bugzilla.redhat.com/show_bug.cgi?id=407561 Dammit. Could we please have non-US-Germany-Japan back, so the rest of the world with no such nonsense doesn't suffer? -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908154239.ga16...@angband.pl
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote: > Matthew Palmer wrote: > > > sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d > > Yeah, that isn't going to work -- what if the next SHA you want to > > package is 12345[blah]... it'll look like a lesser version to dpkg. > I had a similar problem when I moved roxterm to git [1]. I only use > git-derived versions for testing between releases but it's still useful. > Here's a bit of script that can help: > > Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'` > Rev=`date -d "$Date" -u +'%Y%m%d%H%M%S'` Why won't you just use `git --describe`? It produces nice version numbers of the format -- (or just when you're packaging a release) The "start of hash" is a way to disambiguate in the case of multiple branches based on the same release that happen to have the same number of commits past that it; it will be the minimal repo-wide unambiguous hash not shorter than (by default) 7 characters. Unlike homebrewed versioning schemes, this one can be understood by git without changes, no matter if you say 0.8.0-a0-1247-gf38ef2b, f38ef2b or f38ef2ba31de828e4b1961efe9b9e3cf91aadea6. Depending on your upstream's versioning scheme you may want to stick a tilde somewhere. For example, if the upstream tagged a branch that is to-be 0.8 as "0.8.0-a0", you'd want to make that "0.8.0~a0". This way, "0.8.0-a0-1247-gf38ef2b" will become "0.8.0~a0-1247-gf38ef2b" and final "0.8" -- just "0.8.0". I recommend against using dates to mark revisions, since there probably will be multiple commits in a single day, so there is no way to tell which exactly version you did package. Meow! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100915131820.ga31...@angband.pl
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 03:12:22PM +0100, Tony Houghton wrote: > Adam Borowski wrote: > > Why won't you just use `git --describe`? [...] > > Depending on your upstream's versioning scheme you may want to stick a > > tilde somewhere. For example, if the upstream tagged a branch that is > > to-be 0.8 as "0.8.0-a0", you'd want to make that "0.8.0~a0". This way, > > "0.8.0-a0-1247-gf38ef2b" will become "0.8.0~a0-1247-gf38ef2b" and final > > "0.8" -- just "0.8.0". > > Don't upstream version numbers have to be without hyphens so that Debian > can easily distinguish the Debian revision from the upstream? Or is it > OK, because it takes anything after the last hyphen to be the Debian > revision? The latter, Debian revision can not contain hyphens, but the upstream one is allowed to (Policy 5.6.12). > To make it absolutely clear that the release is newer than any > pre-release snapshots I reserve *.0 version numbers for pre-release > snapshots and use *.1 for release, so in your example I'd have 0.8.0* > for snapshots and then 0.8.1 for release. Then I would use 0.8.1-* until > releasing 0.8.2, then 0.9.0* for testing a major new feature to be > released in 0.9.1. Then it's a bit nicer for you -- you don't need to bother with tildes. Most upstreams use versions like 1.0pre23 followed by 1.0, which does not sort properly. The tilde is a hack to deal with such cases. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100915143021.ga31...@angband.pl
Re: Doubts in Sigar packaging
On Thu, Sep 16, 2010 at 03:22:31PM +1000, Matthew Palmer wrote: > On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: > > Why won't you just use `git --describe`? > > It produces nice version numbers of the format > > -- > > (or just when you're packaging a release) > > > > The "start of hash" is a way to disambiguate in the case of multiple > > branches based on the same release that happen to have the same number > > of commits past that it; it will be the minimal repo-wide unambiguous > > hash not shorter than (by default) 7 characters. > > You cannot use hashes in your version strings, because you can't assume that > the "later" version is going to sort after the "earlier" version. If > - isn't sufficiently unique, you're stuffed. You can't compare unversioned branches to other branches anyway. If you move from one branch to another, you need to label that manually. Git's scheme provides enough versioning to handle anything that can be done in automated way. Indeed, packaging multiple branches stemming from the same tag may give versions that are not sufficiently sortable, but there's no way to tell which branch is the "lesser" and which is the "greater" one without human intervention. The hash prefix is there just to catch cases where you have some unofficial or cherry-picked patches, or the branch is not exactly what the reader expects. > Using a tag, however, is a possibility I hadn't considered. If you merge > from upstream at relevant points and then tag in your repo, you could use > 0.x.y~ as the upstream version. Again, README.source would need to > document this convention, but you can control the content of the tag to make > it monotonically increasing. This would be bad, as your tags won't say anything about the version you package. Without a mapping between your tags and particular commits, there's no way to tell what upstream source you refer to. > If it is ambiguous, you can always put that sort of information in the Debian > changelog, or perhaps README.source. git --describe doesn't have that pesky requirement. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916075943.ga16...@angband.pl
Re: Doubts in Sigar packaging
On Fri, Sep 17, 2010 at 06:23:17PM +1000, Matthew Palmer wrote: > On Thu, Sep 16, 2010 at 12:44:47PM +0100, Tony Houghton wrote: > > Did you miss the bit? I think that makes it > > ideal provided each release is tagged with its version number. > > Because tags aren't globally unique. Since you yourself said that tags > weren't suitable, in and of themselves, when I proposed it, I can't imagine > how a tag plus a commit count is of any use. The addition of a hash doesn't > help, for the non-sortable reason I gave. Tags are unique in all even marginally sane projects. They may at most be limited to a certain group of people -- usually, upstream won't have your tags but you will have theirs. The reasons new tags are unsuitable are: * upstream or people pulling from upstream won't have them, so the tags would be meaningless * he is looking for versioning that works in an automated way. There's no reason to add tags that have no other use than attaching them to a single build. In general, "tag" means "release", the --describe thing is there to help with versioning between releases. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100917124421.ga27...@angband.pl
Re: RFS: emerald
On Thu, Sep 23, 2010 at 07:25:38PM +0200, Janos Guljas wrote: > I am looking for a sponsor for my package "emerald". I reviewed it, and it appears to work just fine. There's a lot of warnings about gratuitous linkage of unnecessary libs, but that's mostly an upstreamish problem. The only big issue I noticed is that the package is targetted at experimental instead of unstable -- is there any reason for that? -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100923210529.ga13...@angband.pl
Re: RFS: emerald-themes
On Thu, Sep 23, 2010 at 07:27:55PM +0200, Janos Guljas wrote: > I am looking for a sponsor for my package "emerald-themes". * it's targetted at experimental, again * the upstream changelog is installed twice * plenty of dirs include a file "theme.ini.bak" with obviously useless content But functionality wise, it appears to work just fine. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100923211634.gb13...@angband.pl
Re: RFS: emerald
On Fri, Sep 24, 2010 at 08:23:01PM +0200, Janos Guljas wrote: > > I reviewed it, and it appears to work just fine. > > Thank you for a review. Note that I'm not a DD and cannot upload this for you. So sponsors, do you hear me? Please handle this fine gentelman. > > The only big issue I noticed is that the package is targetted at > > experimental instead of unstable -- is there any reason for that? > > Experimental is targeted because of the freeze and this will be in > new. If you think that unstable is acceptable, I'm glad to change? The only reason to avoid uploading release-quality packages to unstable is to get some more testing for bugfixes to testing since more people run unstable than testing+t-p-u. For a new package, that's totally irrelevant, and it would force you to do a separate upload later. If you could upload it yourself, that would waste "just" buildd resources, and since you can't, you'd have to bother a sponsor again. Unless there's some other reason I don't know about, I'd go straight to unstable. Meow! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100925101201.ga31...@angband.pl
Re: RFS - mapcatcher
On Sat, Oct 09, 2010 at 05:00:42AM -0700, D Haley wrote: > * Although marked as GPL2 or any later, the actual python programs do not > * have the pre-amble in the source files, as required by the licence. Uhm, no. The GPL merely lists that as one of possible ways to do so, and, even though it is advertised as the "safest" way, it is universally despised by anyone who's not in love with legal texts. Including nearly a page of junk with A NUMBER OF PHRASES that are RANDOMLY PUT IN ALL CAPS into every single source file is not only ugly but also makes you waste a second or two every time you try to edit or read the file in question. While merely shipping a copy of the GPL without a word that it actually applies to the project in question is not enough, a file that states the copyright holder, date, and declares that the project is GPLed satisfies the requirement while not being obnoxious. Miaow! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101009183458.ga27...@angband.pl
