Bug#612855: ITP: libfile-util-perl -- File::Util - Easy, versatile, portable file handling
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libfile-util-perl Version : 3.27 Upstream Author : Tommy Butler c...@atrixnet.com|mailto:c...@atrixnet.com * URL or Web page : http://search.cpan.org/dist/File-Util/ * License : Artistic or GPL-1+ Description : File::Util - Easy, versatile, portable file handling File::Util provides a comprehensive toolbox of utilities to automate all kinds of common tasks on file / directories. Its purpose is to do so in the most portable manner possible so that users of this module won't have to worry about whether their programs will work on other OSes and machines. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.11ED5146265@vanaheim
Bug#612856: ITP: libmousex-nativetraits-perl -- Extend your attribute interfaces for Mouse
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libmousex-nativetraits-perl Version : 1.04 Upstream Author : Goro Fuji (gfx) gfuji(at)cpan.org * URL or Web page : http://search.cpan.org/dist/MouseX-NativeTraits/ * License : Artistic or GPL-1+ Description : Extend your attribute interfaces for Mouse While Mouse attributes provide a way to name your accessors, readers, writers, clearers and predicates, MouseX::NativeTraits provides commonly used attribute helper methods for more specific types of data. . As seen in the SYNOPSIS, you specify the data structure via the traits parameter. These traits will be loaded automatically, so you need not load MouseX::NativeTraits explicitly. . This extention is compatible with Moose native traits, although it is not a part of Mouse core. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.24C3214627B@vanaheim
Bug#612857: ITP: libconfig-pit-perl -- Perl module for Manage settings
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libconfig-pit-perl Version : 0.04 Upstream Author : cho45 ch...@lowreal.net * URL or Web page : http://search.cpan.org/dist/Config-Pit/ * License : Artistic or GPL-1+ Description : Perl module for Manage settings Config::Pit is account setting management library. This library automates editing settings used in scripts. . Original library is written in Ruby and published as pit gem with management command. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.03B58146263@vanaheim
Bug#612858: ITP: libclass-ooorno-perl -- Give your module classic AND OO interfaces
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libclass-ooorno-perl Version : 0.011 Upstream Author : Tommy Butler c...@atrixnet.com|mailto:c...@atrixnet.com * URL or Web page : http://search.cpan.org/dist/Class-OOorNO/ * License : Artistic or GPL-1+ Description : Give your module classic AND OO interfaces Class::OOorNO helps your module handle the input for its subroutines whether called in object-oriented style (as object methods or class methods with the arrow syntax -), or in functional programming style (as subroutines imported to the caller's namespace via Exporter). . The bulk of this module comprises a lightweight, pure-Perl emulation of the Devel::Caller library's called_as_method() routine which is written in C. . Devel::Caller dives deep into the internals of of the Perl interpreter (see perlguts) to trace stack frames and can get the input for any call in the stack. It's really handy for Devel::opment and debugging. . This module is much more lightweight and focuses more on your module's Class:: methods themselves. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073830.F271A146262@vanaheim
Bug#612859: ITP: libanyevent-http-perl -- simple but non-blocking HTTP/HTTPS client
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libanyevent-http-perl Version : 2.03 Upstream Author : (information incomplete) * URL or Web page : http://search.cpan.org/dist/AnyEvent-HTTP/ * License : Artistic or GPL-1+ Description : simple but non-blocking HTTP/HTTPS client AnyEvent::HTTP is an AnyEvent user, you need to make sure that you use and run a supported event loop. . This module implements a simple, stateless and non-blocking HTTP client. It supports GET, POST and other request methods, cookies and more, all on a very low level. It can follow redirects, supports proxies, and automatically limits the number of connections to the values specified in the RFC. . It should generally be a good client that is enough for most HTTP tasks. Simple tasks should be simple, but complex tasks should still be possible as the user retains control over request and response headers. . The caller is responsible for authentication management, cookies (if the simplistic implementation in this module doesn't suffice), referer and other high-level protocol details for which this module offers only limited support. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073830.ED4DCF202D@vanaheim
Bug#612860: ITP: libexception-handler-perl -- perl module Exception::Handler
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libexception-handler-perl Version : 1.004 Upstream Author : Tommy Butler c...@atrixnet.com * URL or Web page : http://search.cpan.org/dist/Exception-Handler/ * License : Artistic or GPL-1+ Description : perl module Exception::Handler This Perl module reportx exceptions with formatted text call-stack. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.0CC71146264@vanaheim
Bug#612861: ITP: libwww-mechanize-autopager-perl -- Automatic Pagination using AutoPagerize
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libwww-mechanize-autopager-perl Version : 0.02 Upstream Author : Tatsuhiko Miyagawa miyag...@bulknews.net * URL or Web page : http://search.cpan.org/dist/WWW-Mechanize-AutoPager/ * License : Artistic or GPL-1+ Description : Automatic Pagination using AutoPagerize WWW::Mechanize::AutoPager is a plugin for WWW::Mechanize to do automatic pagination using AutoPagerize user script. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.3F483146262@vanaheim
Re: RFA: all my packages
Hi Decklin (2011.02.11_00:11:05_+0200) python-beautifulsoup and mpd need attention for proposed-updates; I missed getting them into Squeeze. rxvt-unicode is a total clusterfuck. I'm happy to take beautfulsoup (and share it with DPMT) What were you considering for proposed-updates? 3.2? That would probably cause regressions for anyone who has worked around the pain that 3.1 brought. I can't see this easily getting into proposed-updates, but I'm happy to investigate... Reuben: I'm willing to co-maintain the netcats too. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211080058.gj1...@bach.rivera.co.za
Bug#612862: ITP: sludge -- Adventure game development kit and runtime engine
Package: wnpp Severity: wishlist Owner: Tobias Hansen tobias.han...@physik.uni-hamburg.de * Package name: sludge Version : 2.0.1 Upstream Author : Tim Furnish, Rikard Peterson, Tobias Hansen tobias@gmx.de * URL : http://opensludge.sourceforge.net/ * License : (GPL (development kit), LGPL (engine)) Programming Lang: (C, C++) Description : Adventure game development kit and runtime engine SLUDGE is an open source adventure game engine. It combines a scripting language with graphical tools to easily create adventure games. Several games have been created using SLUDGE and they require the SLUDGE engine to be played. See http://opensludge.sourceforge.net/games.html for a list of available SLUDGE games. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211001033.26196.52984.reportbug@tobi-laptop
Bug#612865: ITP: libwww-youtube-download-perl -- Very simply YouTube video download interface.
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libwww-youtube-download-perl Version : 0.22 Upstream Author : Yuji Shimada * URL or Web page : http://search.cpan.org/dist/WWW-YouTube-Download/ * License : Artistic or GPL-1+ Description : Very simply YouTube video download interface. WWW::YouTube::Download is a download video from YouTube. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.4F3F0146265@vanaheim
Bug#612866: ITP: libwww-nicovideo-download-perl -- Download FLV/MP4/SWF files from nicovideo.jp
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libwww-nicovideo-download-perl Version : 0.06 Upstream Author : Tatsuhiko Miyagawa miyag...@cpan.org * URL or Web page : http://search.cpan.org/dist/WWW-NicoVideo-Download/ * License : Artistic or GPL-1+ Description : Download FLV/MP4/SWF files from nicovideo.jp WWW::NicoVideo::Download is a module to login, request and download video files from Nico Nico Douga. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.49FC5146264@vanaheim
Bug#612867: ITP: libwww-mechanize-decodedcontent-perl -- decode Mech content using its HTTP response encoding
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libwww-mechanize-decodedcontent-perl Version : 0.01 Upstream Author : Tatsuhiko Miyagawa miyag...@bulknews.net * URL or Web page : http://search.cpan.org/dist/WWW-Mechanize-DecodedContent/ * License : Artistic or GPL-1+ Description : decode Mech content using its HTTP response encoding WWW::Mechanize::DecodedContent is a plugin to add decoded_content utility method to WWW::Mechanize. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.4499C146263@vanaheim
Bug#612868: ITP: libhtml-autopagerize-perl -- Utility to load AutoPagerize SITEINFO stuff
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libhtml-autopagerize-perl Version : 0.01 Upstream Author : Tatsuhiko Miyagawa miyag...@bulknews.net * URL or Web page : http://search.cpan.org/dist/HTML-AutoPagerize/ * License : Artistic or GPL-1+ Description : Utility to load AutoPagerize SITEINFO stuff HTML::AutoPagerize is an utility module to load SITEINFO defined in AutoPagerize. AutoPagerize is an userscript to automatically figure out the next link of the current page, then fetch the content and insert the content by extracting the page element. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.1861D146266@vanaheim
Bug#612869: ITP: libtest-fatal-perl -- incredibly simple helpers for testing code with exceptions
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libtest-fatal-perl Version : 0.003 Upstream Author : Ricardo Signes r...@cpan.org * URL or Web page : http://search.cpan.org/dist/Test-Fatal/ * License : Artistic or GPL-1+ Description : incredibly simple helpers for testing code with exceptions Test::Fatal is an alternative to the popular Test::Exception. It does much less, but should allow greater flexibility in testing exception-throwing code with about the same amount of typing. . It exports one routine by default: exception. . This description was automagically extracted from the module by dh-make-perl. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.2EBFE14627F@vanaheim
Bug#612870: ITP: libmousex-types-path-class-perl -- A Path::Class type library for Mouse
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libmousex-types-path-class-perl Version : 0.06 Upstream Author : NAKAGAWA Masaki mas...@cpan.org * URL or Web page : http://search.cpan.org/dist/MouseX-Types-Path-Class/ * License : Artistic or GPL-1+ Description : A Path::Class type library for Mouse MouseX::Types::Path::Class creates common Mouse types, coercions and option specifications useful for dealing with Path::Class objects as Mouse attributes. . Coercions (see Mouse::Util::TypeConstraints) are made from both Str and ArrayRef to both Path::Class::Dir and Path::Class::File objects. If you have MouseX::Getopt installed, the Getopt option type (=s) will be added for both Path::Class::Dir and Path::Class::File. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.29A3114627D@vanaheim
Bug#612871: ITP: libtext-microtemplate-perl -- Micro template engine with Perl5 language
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libtext-microtemplate-perl Version : 0.18 Upstream Author : Kazuho Oku kazuhooku gmail.com * URL or Web page : http://search.cpan.org/dist/Text-MicroTemplate/ * License : Artistic or GPL-1+ Description : Micro template engine with Perl5 language Text::MicroTemplate is a standalone, fast, intelligent, extensible template engine with following features. . standalone Text::MicroTemplate does not rely on other CPAN modules. . fast Based on Mojo::Template, expressions in the template is perl code. . intelligent Text::MicroTemplate automatically escapes variables when and only when necessary. . extensible Text::MicroTemplate does not provide features like template cache or including other files by itself. However, it is easy to add you own (that suites the most to your application), by wrapping the result of the module (which is a perl expression). . The module only provides basic building blocks for a template engine. Refer to Text::MicroTemplate::File for higher-level interface. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.33D95146281@vanaheim
Bug#612872: ITP: libtwiggy-perl -- AnyEvent HTTP server for PSGI (like Thin)
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libtwiggy-perl Version : 0.1010 Upstream Author : Tatsuhiko Miyagawa * URL or Web page : http://search.cpan.org/dist/Twiggy/ * License : Artistic or GPL-1+ Description : AnyEvent HTTP server for PSGI (like Thin) Twiggy is a lightweight and fast HTTP server with unique features such as: . PSGI Can run any PSGI applications. Fully supports *psgi.nonblocking* and *psgi.streaming* interfaces. . AnyEvent This server uses AnyEvent and runs in a non-blocking event loop, so it's best to run event-driven web applications that runs I/O bound jobs or delayed responses such as long-poll, WebSocket or streaming content (server push). . This software used to be called Plack::Server::AnyEvent but was renamed to Twiggy. See NAMING for details. . Fast header parser Uses XS/C based HTTP header parser for the best performance. (optional) . Lightweight and Fast The memory required to run twiggy is 6MB and it can serve more than 4500 req/s with a single process on Perl 5.10 with MacBook Pro 13 late 2009. . Superdaemon aware Supports Server::Starter for hot deploy and graceful restarts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.396FEF202D@vanaheim
Bug#612873: ITP: libmousex-getopt-perl -- A Mouse role for processing command line options
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libmousex-getopt-perl Version : 0.33 Upstream Author : NAKAGAWA Masaki mas...@cpan.org, FUJI Goro gf...@cpan.org, Tokuhiro Matsuno tokuhi...@cpan.org, Stevan Little ste...@iinteractive.com, Brandon L. Black blbl...@gmail.com, Yuval Kogman nothingm...@woobling.org, Ryan D Johnson r...@innerfence.com, Drew Taylor d...@drewtaylor.com, Tomas Doran bobtf...@bobtfish.net, Florian Ragwitz r...@debian.org, Dagfinn Ilmari Mannsaker ilm...@ilmari.org, Avar Arnfjord Bjarmason a...@cpan.org, Chris Prather perig...@cpan.org * URL or Web page : http://search.cpan.org/dist/MouseX-Getopt/ * License : Artistic or GPL-1+ Description : A Mouse role for processing command line options This is a role which provides an alternate constructor for creating objects using parameters passed in from the command line. . MouseX::Getopt attempts to DWIM as much as possible with the command line params by introspecting your class's attributes. It will use the name of your attribute as the command line option, and if there is a type constraint defined, it will configure Getopt::Long to handle the option accordingly. . You can use the trait MouseX::Getopt::Meta::Attribute::Trait or the attribute metaclass MouseX::Getopt::Meta::Attribute to get non-default commandline option names and aliases. . You can use the trait MouseX::Getopt::Meta::Attribute::Trait::NoGetopt or the attribute metaclass MouseX::Getopt::Meta::Attribute::NoGetopt to have MouseX::Getopt ignore your attribute in the commandline options. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211073831.1D7F4146267@vanaheim
Re: RFA: all my packages
Hi, I would like to join your team because of my usage of lastfmsubmitd. Best Regards, Ferdinand Am Friday 11 of February 2011, 07:12:05 schrieb Alexander Wirt: Decklin Foster schrieb am Thursday, den 10. February 2011: I'm looking for a new maintainer for, well, any of these. My heart is not in it anymore and most of them have been neglected for a while. Recently my free time has been taken up by other things (mainly my job) and I forsee that continuing. http://qa.debian.org/developer.php?login=decklin%40red-bean.com As I am a heavy mpd user I would like to take these over and form a team for mpd related packages. Are they still for adoption? Alex signature.asc Description: This is a digitally signed message part.
Re: RFA: all my packages
On Thu, Feb 10, 2011 at 07:02:16PM -0500, Yaroslav Halchenko wrote: On Thu, 10 Feb 2011, Decklin Foster wrote: rxvt-unicode is a total clusterfuck. if noone ever comes up (I am already overloaded somewhat) -- I guess I will need to look at this cluster..ck since I am using it ;-) Speaking of rxvt... shouldn't this clusterϫϫck become the only rxvt in Debian? Both rxvt and rxvt-beta, completely dead upstream for 10 and 8 years respectively, besides having terrible support for terminal codes lack even such a tiny detail as UTF-8 support. I'd say there should be no place in Debian in 2011 for software that can't do UTF-8, especially if near-identical forks exist. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211084733.ga30...@angband.pl
Re: RFA: all my packages
Le vendredi 11 février 2011 à 09:47 +0100, Adam Borowski a écrit : I'd say there should be no place in Debian in 2011 for software that can't do UTF-8, especially if near-identical forks exist. That would make a nice addition to the policy, wouldn’t it? -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1297414335.13596.67.camel@meh
git-buildpackage branch names
Hi, if one manages two versions of a software : 2.0, the latest, which goes to experimental and 1.0.x, still maintained by upstream, going to unstable. What's the best way to name gbp branches ? I thought of something like : 2.0 1.0.x master master-1.0.x upstreamupstream-1.0.x pristine-tarpristine-tar-1.0.x is there some common practice ? Regards, Jérémy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d54f755.6010...@melix.org
Re: RFA: all my packages
On Thu, 10 Feb 2011 17:11:05 -0500, Decklin Foster wrote: I'm looking for a new maintainer for, well, any of these. My heart is not in it anymore and most of them have been neglected for a while. Recently my free time has been taken up by other things (mainly my job) and I forsee that continuing. http://qa.debian.org/developer.php?login=decklin%40red-bean.com python-beautifulsoup and mpd need attention for proposed-updates; [..] I'll take beautifulsoup. Thanks for your work on this! David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFA: all my packages
On Fri, Feb 11, 2011 at 09:56, David Paleino da...@debian.org wrote: On Thu, 10 Feb 2011 17:11:05 -0500, Decklin Foster wrote: I'm looking for a new maintainer for, well, any of these. My heart is not in it anymore and most of them have been neglected for a while. Recently my free time has been taken up by other things (mainly my job) and I forsee that continuing. http://qa.debian.org/developer.php?login=decklin%40red-bean.com python-beautifulsoup and mpd need attention for proposed-updates; [..] I'll take beautifulsoup. see 20110211080058.gj1...@bach.rivera.co.za -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=iu+7zjs_rw-ldwtuhxfxdtwsqeyg0hyshn...@mail.gmail.com
Re: RFA: all my packages
On Fri, 11 Feb 2011 10:03:58 +0100, Sandro Tosi wrote: On Fri, Feb 11, 2011 at 09:56, David Paleino da...@debian.org wrote: On Thu, 10 Feb 2011 17:11:05 -0500, Decklin Foster wrote: I'm looking for a new maintainer for, well, any of these. My heart is not in it anymore and most of them have been neglected for a while. Recently my free time has been taken up by other things (mainly my job) and I forsee that continuing. http://qa.debian.org/developer.php?login=decklin%40red-bean.com python-beautifulsoup and mpd need attention for proposed-updates; [..] I'll take beautifulsoup. see 20110211080058.gj1...@bach.rivera.co.za Aha, I missed it. Thanks Sandro for spotting this. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFA: all my packages
Hi Stefano, On Fri, 11 Feb 2011 10:00:58 +0200, Stefano Rivera wrote: Hi Decklin (2011.02.11_00:11:05_+0200) python-beautifulsoup and mpd need attention for proposed-updates; I missed getting them into Squeeze. rxvt-unicode is a total clusterfuck. I'm happy to take beautfulsoup (and share it with DPMT) I had already opened an ITA for beautifulsoup. I'm setting you as the bugowner, please close it when you upload :) http://bugs.debian.org/612875 Sorry for the noise, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Spell checker as reasonable SPAM prevention tool
Hi, since some time we get more and more SPAM which is easily to detect for me (and most probably automatically): SPAM in languages I do simply not understand and which are definitely not English. Wouldn't it be a reasonable means for a SPAM filter to mark mails which blatantly fail a spell checker to mark as potential SPAM and just apply this filter to all Debian lists. We have defined languages for each list and the one mail per month were a user just writes in the wrong language by accident will probably not harm the project. Just my 0.02 Euro Andreas. PS: I assume that a spell checker can be configured that way that it can distinguish between writing an English text with some / several mistakes and a text with say 50% error rate which is probably not understandable anyway. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211091907.gd30...@an3as.eu
Re: git-buildpackage branch names
On Fri, 11 Feb 2011 09:46:13 +0100, Jérémy Lal wrote: Hi, if one manages two versions of a software : 2.0, the latest, which goes to experimental and 1.0.x, still maintained by upstream, going to unstable. What's the best way to name gbp branches ? I thought of something like : 2.0 1.0.x mastermaster-1.0.x upstream upstream-1.0.x pristine-tar pristine-tar-1.0.x is there some common practice ? I usually use something like: master exp/master for, respectively, unstable and experimental and upstream exp/upstream. You can achieve the latter by passing --upstream-branch=exp/upstream to git-import-orig. If you don't expect new upstream versions of 1.0.x for unstable (which AIUI is not the case for your software), you could use upstream both for unstable *and* experimental (i.e. just git import-orig in the correct order). You'll just need to use some appropriate switches when building. Now you can run git-buildpackage. Depending on the branch you're on (master or exp/master), it will use that as debian branch. Then you need to specify the upstream branch: $ git-buildpackage --upstream-branch=exp/upstream This is for building the experimental version, in case the upstream branches are split. If you use a unified upstream branch, i.e. only the latest code is available there (2.0), and you need to build the unstable version, you can even use tags: $ git-buildpackage --upstream-branch=upstream/1.0.x I don't know if there's any better layout though :) Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFA: all my packages
On 11/02/11 09:52, Josselin Mouette wrote: Le vendredi 11 février 2011 à 09:47 +0100, Adam Borowski a écrit : I'd say there should be no place in Debian in 2011 for software that can't do UTF-8, especially if near-identical forks exist. That would make a nice addition to the policy, wouldn’t it? So long as it is not a MUST, else I have a feeling we'll find many many packages RC... That aside, I agree with this idea. Cheers, Vincent -- Vincent Fourmond, Debian Developer http://vince-debian.blogspot.com/ His followers called him Mahasamatman and said he was a god. He preferred to drop the Maha- and the -atman, however, and called himself Sam. -- Roger Zelazny, Lord of Light Vincent, listening to South Bound Saurez (Led Zeppelin) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d54fbef.7060...@debian.org
Re: RFA: all my packages
* Vincent Fourmond fourm...@debian.org, 2011-02-11, 10:05: I'd say there should be no place in Debian in 2011 for software that can't do UTF-8, especially if near-identical forks exist. That would make a nice addition to the policy, wouldn’t it? So long as it is not a MUST, else I have a feeling we'll find many many packages RC... *cough* #139861 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211093231.ga2...@jwilk.net
Make Unicode bugs release critical?
On pe, 2011-02-11 at 10:05 +0100, Vincent Fourmond wrote: On 11/02/11 09:52, Josselin Mouette wrote: Le vendredi 11 février 2011 à 09:47 +0100, Adam Borowski a écrit : I'd say there should be no place in Debian in 2011 for software that can't do UTF-8, especially if near-identical forks exist. That would make a nice addition to the policy, wouldn’t it? So long as it is not a MUST, else I have a feeling we'll find many many packages RC... That aside, I agree with this idea. A release goal or release requirement might be another way of achieving this. However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. The first Unicode standard was published in 1991. That's twenty years ago. Any software that processes text at all and is incapable of dealing with UTF-8 should be considered with extreme suspicion. Making all such bugs be release critical (which includes the notion that release managers may ignore the bug in particular cases) sounds like a good way to get things under control. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1297417074.3105.6.ca...@havelock.lan
Re: Spell checker as reasonable SPAM prevention tool
Andreas Tille, le Fri 11 Feb 2011 10:19:07 +0100, a écrit : PS: I assume that a spell checker can be configured that way that it can distinguish between writing an English text with some / several mistakes and a text with say 50% error rate which is probably not understandable anyway. Mmm, I think we've already had users that have even 50% error rate, simply because they mispell things. Yes, not everybody has even a basic knowledge level in english, but they still can provide useful input to a mailing list. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211094249.ga5...@const.bordeaux.inria.fr
Re: git-buildpackage branch names
hi jérémy, On Fri, Feb 11, 2011 at 09:46:13AM +0100, Jérémy Lal wrote: What's the best way to name gbp branches ? I thought of something like : 2.0 1.0.x mastermaster-1.0.x upstream upstream-1.0.x pristine-tar pristine-tar-1.0.x is there some common practice ? personally, i don't use master or references to specific upstream versions at all in the branching, and use something like the following: debian-experimental/upstream-experimental debian-sid/upstream-sid debian-squeeze/upstream-squeeze (etc). the pkg-php php.git would be a good example of that. i find this system is generally intuitive and trouble free, as long as you don't end up needing to support multiple versions of the software in the *same* release. fyi about git-buildpackage: you can put the branch names and any other release-specific stuff in ./debian/gbp.conf, on the respective debianized branch, which means you can have different configurations on a per-branch basis, and don't need to pass all those pesky options to gbp every time you run it :) sean -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211093303.ga3...@cobija.connexer.com
Re: RFA: all my packages
Hi. Le vendredi 11 février 2011 à 10:00 +0200, Stefano Rivera a écrit : Hi Decklin (2011.02.11_00:11:05_+0200) python-beautifulsoup and mpd need attention for proposed-updates; I missed getting them into Squeeze. rxvt-unicode is a total clusterfuck. I'm happy to take beautfulsoup (and share it with DPMT) What were you considering for proposed-updates? 3.2? That would probably cause regressions for anyone who has worked around the pain that 3.1 brought. I can't see this easily getting into proposed-updates, but I'm happy to investigate... May I suggest to further discuss this in #564160 ? Hope this helps. Best regards, -- Olivier BERGER olivier.ber...@it-sudparis.eu http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1297416019.7880.1.ca...@inf-8657.int-evry.fr
Re: Spell checker as reasonable SPAM prevention tool
Samuel Thibault sthiba...@debian.org (11/02/2011): Mmm, I think we've already had users that have even 50% error rate, simply because they mispell things. I like the intended pun! KiBi. signature.asc Description: Digital signature
Re: Make Unicode bugs release critical?
On Fri, Feb 11, 2011 at 09:37:54AM +, Lars Wirzenius wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. Mostly it is just the old stuff like - eterm, aterm - elvis - X tools from the basic package (xman, xmessage, xmore, ...) - TeX without additional packages -- Miroslav Kure -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211101442.ga29...@pharaoh.inf.upol.cz
Re: Spell checker as reasonable SPAM prevention tool
Hello Samuel Thibault, Am 2011-02-11 10:42:49, hacktest Du folgendes herunter: Andreas Tille, le Fri 11 Feb 2011 10:19:07 +0100, a écrit : PS: I assume that a spell checker can be configured that way that it can distinguish between writing an English text with some / several mistakes and a text with say 50% error rate which is probably not understandable anyway. Mmm, I think we've already had users that have even 50% error rate, simply because they mispell things. Yes, not everybody has even a basic knowledge level in english, but they still can provide useful input to a mailing list. In the arround 600 latvian spams I have gotten the last 3 weeks, there are enough keywords which identify the mais as spam and I do not know why, but spamassassin gaved the messages a score of -4 and greater. Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsystems@tdnet France EURL itsystems@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature
Re: Make Unicode bugs release critical?
On Fri, Feb 11, 2011 at 11:14:42AM +0100, Miroslav Kure wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. Mostly it is just the old stuff like - eterm, aterm - elvis - X tools from the basic package (xman, xmessage, xmore, ...) - TeX without additional packages - tr(1) -- WBR, wRAR signature.asc Description: Digital signature
Re: Spell checker as reasonable SPAM prevention tool
On Fri, Feb 11, 2011 at 10:42:49AM +0100, Samuel Thibault wrote: Andreas Tille, le Fri 11 Feb 2011 10:19:07 +0100, a écrit : PS: I assume that a spell checker can be configured that way that it can distinguish between writing an English text with some / several mistakes and a text with say 50% error rate which is probably not understandable anyway. Mmm, I think we've already had users that have even 50% error rate, simply because they mispell things. Yes, not everybody has even a basic knowledge level in english, but they still can provide useful input to a mailing list. It might be a topic of fuerther investigation what limit on the error rate to put but I'm quite positive that there are reasonable algorithms to detect in what language a text is in or rather to detect whether a text atempts to be written in a certain language (which is probably easier than to guess a language). The question whether it is worth doing some stats on the mailing list archive about this is rather if we finally want this language detection method for a SPAM filter or not. My guess is that you will find a ratio of misspelled words / total number of words which is a clear sign for non-English text, than you have some intermediate area where those postings like you are afraid about are belonging to and than there are the postings which are obviosely trying hard to write some English. I'd like to get rid of the clearly non-English texts. I have the impression that we get more and more of these since some time and I assume that bayesian filters are not (yet) trained good enough to detect these as SPAM. So we need to find some other means. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211104413.gb2...@an3as.eu
Re: Make Unicode bugs release critical?
Hi there! On Fri, 11 Feb 2011 11:14:42 +0100, Miroslav Kure wrote: On Fri, Feb 11, 2011 at 09:37:54AM +, Lars Wirzenius wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. Mostly it is just the old stuff like - eterm, aterm - elvis - X tools from the basic package (xman, xmessage, xmore, ...) - TeX without additional packages Plus a2ps (see #180236), something a lot of people use before KSPs, even if there are various alternatives, some of them already in Debian: Message-ID: 4d3f1bf6.1060...@sanctuary.nslug.ns.ca URL: http://lists.debian.org/msgid-search/%3c4D3F1BF6.1060604%40sanctuary.nslug.ns.ca%3e Everything should be at http://wiki.debian.org/UTF8BrokenApps. Thx, bye, Gismo / Luca pgpUwauikQgCE.pgp Description: PGP signature
Re: Make Unicode bugs release critical?
On Fri, Feb 11, 2011 at 11:14:42AM +0100, Miroslav Kure wrote: On Fri, Feb 11, 2011 at 09:37:54AM +, Lars Wirzenius wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. Mostly it is just the old stuff like - eterm, aterm - elvis - X tools from the basic package (xman, xmessage, xmore, ...) - TeX without additional packages XeTeX and XeLaTeX allow native UTF-8 input. Should be made the default, IMO, given how obsolete and broken the standard TeX encodings are. Being able to write in actual text rather than a lot of illegible incantations was a major revelation, and it's a bit sad it was in that situation in the first place. It also sorts out the awful font support, so you can use standard freetype-registered fonts, again without the pain. Result: a document you can actually read in the editor! IMO all those broken terminal emulators, editors and tools should be put in the bin. There are plenty of non-broken replacements, so why keep them around to bitrot even further? It's not like it's going to cause massive inconvenience--they are long obsolete. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: RFA: all my packages
On Fr, Feb 11, 2011 at 07:12:05 (CET), Alexander Wirt wrote: Decklin Foster schrieb am Thursday, den 10. February 2011: I'm looking for a new maintainer for, well, any of these. My heart is not in it anymore and most of them have been neglected for a while. Recently my free time has been taken up by other things (mainly my job) and I forsee that continuing. http://qa.debian.org/developer.php?login=decklin%40red-bean.com As I am a heavy mpd user I would like to take these over and form a team for mpd related packages. Are they still for adoption? If our team rules/development guidelines (basically the git-buildpackage recommended workflow)suit your development style, you could join and maintain the mpd packages in the pkg-multimedia team: http://wiki.debian.org/DebianMultimedia/ -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y65m3htt@faui44a.informatik.uni-erlangen.de
Re: RFA: all my packages
Ryan Kavanagh ryana...@kubuntu.org writes: Hi, On Thu, Feb 10, 2011 at 07:02:16PM -0500, Yaroslav Halchenko wrote: On Thu, 10 Feb 2011, Decklin Foster wrote: rxvt-unicode is a total clusterfuck. if noone ever comes up (I am already overloaded somewhat) -- I guess I will need to look at this cluster..ck since I am using it ;-) I don't think I have the time and nor the ability to properly maintain rxvt-unicode solo, but since it's my terminal of choice, I'm willing to co-maintain it. Kind regards, Ryan I am a rxvt-unicode user too. I'm not a DM or DD, but i am learning packaging now. I have lots of time. So I'm willing to co-maintain it. Hope i can do some help. -- Regards Lei -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d55255c.23968e0a.09ce.2...@mx.google.com
Re: Make Unicode bugs release critical?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am Fr den 11. Feb 2011 um 10:37 schrieb Lars Wirzenius: The first Unicode standard was published in 1991. That's twenty years ago. Any software that processes text at all and is incapable of dealing with UTF-8 should be considered with extreme suspicion. Making all such bugs be release critical (which includes the notion that release managers may ignore the bug in particular cases) sounds like a good way to get things under control. I think you are mixing stuff together. First there is unicode. There are several definitions for unicode (unicode-16, unicode-32, ...) but UTF-8 is not unicode it is just one implementation of unicode and in my eyes the most problematic as it has undefined states and is variable length. However, UTF-8 was created to allow using unicode in non-unicode environments. For me that was always a pointless plan and the unreadable UTF-8 characters all around buggy software that cannot handle encodings correct (and there are many around) and ignorant users who are using UTF-8 in environments that are not specified for multibyte charsets (IRC) is the most annoying one. As there are places where UTF-8 makes perfect sense and is the best solution it is not the best solution for all ignorance users (me too ;-) have. So specifying to be UTF-8 capable is somewhat inconsequent. Software has to be capable to handle every encoding as long as they are specified for that encodings. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.ch/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen kl...@ethgen.de Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTVUksZ+OKpjRpO3lAQoxGgf/WRdHVqOQ+4A/VkbaLRkXk7uZMKk1uNMT t5gIbmtkIZLRhGkVZIzuVNXT7Zlq+tS3HwpbUaHNmd7ImNUlN+m9dP1gJFacZaGd zYeM0L1G9nfh4iwNmNIqQ/ZhF3lnOUtV6kDqvlZ4EgIwXfAPDZeFMgCxkCeh8mbq H2MABIqwGxahqQoZ6Oql0npvE4QMVB7Use2iT2pPiNBSsB1hFzH9sqNu+uNdbko9 mI82BLHhMwwjhIo3ceFEHkah5pCPlJpTJHgRLd5nYf6/BUkEiR+ECnohdbkjjX5d 1ftp+4Q7Bngve1+5vM4yKQJAEx5vV1kV8U+GaQGE8Kad+op2BhWL+Q== =VYai -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011025946.ga4...@ikki.ethgen.ch
Bug#612897: ITP: wreport -- C++ library for working with weather reports
Package: wnpp Severity: wishlist Owner: Enrico Zini enr...@debian.org * Package name: wreport Version : 1.5 Upstream Author : Enrico Zini enr...@enricozini.org * URL : http://www.arpa.emr.it/dettaglio_documento.asp?id=2927idlivello=64 * License : GPL Programming Lang: C++ Description : library for working with weather reports libwreport is a C++ library for working with weather reports. . The main feature of libwreport is a powerful decoder and encoder for the BUFR and CREX formats. . It also provides a useful abstraction to handle values found in weather reports, with awareness of significant digits, measurement units, variable descriptions, unit conversion and attributes on variables. . Features provided: . * Read and write BUFR version 2, 3, and 4 * Read and write CREX * Unit conversion * Handling of physical variables Besides being a proper, powerful, tested, free codec for BUFR and CREX, this is going to be a dependency for the new upstream version of the dballe package. Ciao, Enrico -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211122344.1593.83249.reportbug@localhost
Re: Make Unicode bugs release critical?
Am -10.01.-28163 20:59, schrieb Andrey Rahmatullin: On Fri, Feb 11, 2011 at 11:14:42AM +0100, Miroslav Kure wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. Mostly it is just the old stuff like - eterm, aterm - elvis - X tools from the basic package (xman, xmessage, xmore, ...) - TeX without additional packages - tr(1) grep, sed, awk, bash, ... Torsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d552988.1020...@debian.org
Re: Make Unicode bugs release critical?
On Fri, Feb 11, 2011 at 01:20:24PM +0100, Torsten Werner wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. Mostly it is just the old stuff like - eterm, aterm - elvis - X tools from the basic package (xman, xmessage, xmore, ...) - TeX without additional packages - tr(1) grep, sed, awk, bash, ... http://bugs.debian.org/495677 -- WBR, wRAR signature.asc Description: Digital signature
Re: Make Unicode bugs release critical?
On pe, 2011-02-11 at 13:20 +0100, Torsten Werner wrote: grep, sed, awk, bash, ... grep, sed, and awk, at least, seem to work acceptably for me with UTF-8. The support can be improved, I'm sure. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1297428633.3105.56.ca...@havelock.lan
Re: there is /usr/lib64 symlink but no /usr/local/lib64
On 2011-02-04 19:02:33 +0100, Tollef Fog Heen wrote: ]] Yaroslav Halchenko | /usr/lib64 - /usr/lib Not really, apart from some broken software that will look for stuff there and be confused if it doesn't exist. I think we should drop it. Thanks would be a good thing. Otherwise users should either avoid upstream GCC's or add similar symbolic links for every directory (e.g. $HOME/lib64 - $HOME/lib if the user installs software in his home directory). FYI, here's the problem I had under Debian because of this symbolic link: http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html (and followups) -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211125238.gg15...@prunille.vinc17.org
Re: Make Unicode bugs release critical?
On Fr, 11 Feb 2011, Roger Leigh wrote:
XeTeX and XeLaTeX allow native UTF-8 input. Should be made the
default, IMO, given how obsolete and broken the standard TeX
encodings are. Being able to write in actual text rather than
Please don't write rubbish if you don't know what you are talking about!!!
You have apparently no idea between input and font encoding.
LaTeX can easily useutf8 with the appropriate inputenc, as well
as dozens of other encoding. Not all of the world is using UTF8.
UTF( is still taileored to western roman script, thus very unpopular
in Japan for example.
sorts out the awful font support, so you can use standard
freetype-registered fonts, again without the pain. Result: a
document you can actually read in the editor!
Argg, PLEASE STOP THAT RUBBISH
I never use xetex, I write a lot in German (umlauts), Japanese,
Italian, ...
TeX is different, don't try to throw away working solutions of 20 years
because of your ignorance.
ARrggg. I love people blabbering like drunkyards.
IMO all those broken terminal emulators, editors and tools should
be put in the bin. There are plenty of non-broken replacements, so
why keep them around to bitrot even further? It's not like it's
So what is the replacement for tex?
Yeah iknow, it is *luatex* but we are FAR fro being stable and
usable.
XeTeX is nice for certain things, but not for all. Have you tried to
set Tibetan text with XeTeX? The last time I tried it was a mess.
And with Khmer (the language and script of Cambodia) it is even worse.
Only because you are only using ASCII characters please don't make the
rest of the world laugh on you.
Best wishes
Norbert
(mumbling throw away in the bin*, *standard freetype*, ...)
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
HAGNABY (n.)
Someone who looked a lot more attractive in the disco than they do in
your bed the next morning.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211124629.ga1...@gamma.logic.tuwien.ac.at
Re: Make Unicode bugs release critical?
On 02/11/11 14:20, Torsten Werner wrote: grep, sed, awk, bash, ... ? $ echo αβγ | sed 's/./a/' aβγ Regards, Φαίδων :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d553373.5060...@debian.org
Re: Make Unicode bugs release critical?
On 2011-02-11 21:46:29 +0900, Norbert Preining wrote: On Fr, 11 Feb 2011, Roger Leigh wrote: XeTeX and XeLaTeX allow native UTF-8 input. Should be made the default, IMO, given how obsolete and broken the standard TeX encodings are. Being able to write in actual text rather than Please don't write rubbish if you don't know what you are talking about!!! You have apparently no idea between input and font encoding. LaTeX can easily useutf8 with the appropriate inputenc, Which one??? FYI, utf8 is very incomplete and utf8x is broken (bug 601365). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211131843.gh15...@prunille.vinc17.org
Re: git-buildpackage branch names
Jérémy Lal wrote: pristine-tar pristine-tar-1.0.x You should never need more than one pristine-tar branch for a package. (Unless you're importing pristine tarballs that have identical filenames, but different content.) -- see shy jo signature.asc Description: Digital signature
Re: Make Unicode bugs release critical?
On Fri, Feb 11, 2011 at 09:46:29PM +0900, Norbert Preining wrote: On Fr, 11 Feb 2011, Roger Leigh wrote: XeTeX and XeLaTeX allow native UTF-8 input. Should be made the default, IMO, given how obsolete and broken the standard TeX encodings are. Being able to write in actual text rather than Please don't write rubbish if you don't know what you are talking about!!! Um, no need to be rude. Please keep your reply to technical points; if I've said something incorrect, by all means correct me, but insults is a step too far. I haven't said anything that could justify it, other than the fact that you disagree with my /opinion/. You have apparently no idea between input and font encoding. I only mentioned UTF-8 with regard to input, so you are assuming too much. LaTeX can easily useutf8 with the appropriate inputenc, as well as dozens of other encoding. Not all of the world is using UTF8. UTF( is still taileored to western roman script, thus very unpopular in Japan for example. The inputenc hack only gets you so far. I tried to go this way, and ran into all sorts of issues with UTF-8 in macro definitions getting scrambled and other sources of pain. With XeLaTeX I had no such troubles. So IME inputenc was not a suitable solution for serious UTF-8 work. sorts out the awful font support, so you can use standard freetype-registered fonts, again without the pain. Result: a document you can actually read in the editor! Argg, PLEASE STOP THAT RUBBISH What you are calling rubbish is not in any way false. It's given me the ability to have nice legible UTF-8-encoded documents, with excellent font support. There may be other ways. There may be better ways. But it's not wrong. [snip rant] IMO all those broken terminal emulators, editors and tools should be put in the bin. There are plenty of non-broken replacements, so why keep them around to bitrot even further? It's not like it's So what is the replacement for tex? Yeah iknow, it is *luatex* but we are FAR fro being stable and usable. Well I thought the jury was still out on which was the better solution. I really couldn't care less which wins; I'm using the solution which works right now, and I'll happily adopt whatever is better down the line. XeTeX is nice for certain things, but not for all. Have you tried to set Tibetan text with XeTeX? The last time I tried it was a mess. And with Khmer (the language and script of Cambodia) it is even worse. Only because you are only using ASCII characters please don't make the rest of the world laugh on you. You are again making unwarranted assumptions. I might not be using it for difficult-to-set languages, but I'm certainly not using ASCII characters only, or I wouldn't be needing UTF-8 input. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Make Unicode bugs release critical?
On 2011-02-11 15:33:49 +0500, Andrey Rahmatullin wrote: On Fri, Feb 11, 2011 at 11:14:42AM +0100, Miroslav Kure wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. Mostly it is just the old stuff like - eterm, aterm - elvis - X tools from the basic package (xman, xmessage, xmore, ...) - TeX without additional packages - tr(1) less has problems with new Unicode characters (bug 597918). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211133024.gi15...@prunille.vinc17.org
Re: Make Unicode bugs release critical?
On Fri, Feb 11, 2011 at 12:59:46PM +0100, Klaus Ethgen wrote: Am Fr den 11. Feb 2011 um 10:37 schrieb Lars Wirzenius: The first Unicode standard was published in 1991. That's twenty years ago. Any software that processes text at all and is incapable of dealing with UTF-8 should be considered with extreme suspicion. Making all such bugs be release critical (which includes the notion that release managers may ignore the bug in particular cases) sounds like a good way to get things under control. I think you are mixing stuff together. First there is unicode. There are several definitions for unicode (unicode-16, unicode-32, ...) but UTF-8 is not unicode it is just one implementation of unicode and in my eyes the most problematic as it has undefined states and is variable length. There is just one definition of Unicode, any new versions merely add extra characters, collating rules, etc. There are several ways to represent Unicode as a stream of bytes. Only one of them is fit for external storage, and that's UTF-8 since it doesn't break the assumptions that are true for text files: 1. no null bytes 2. basic newlines, etc are always newlines, never a part of a bigger character (not true for some ancient multibyte encodings) 3. not affected by endianness or any other internal detail Also, _all_ Unicode encodings are of variable length. However, UTF-8 was created to allow using unicode in non-unicode environments. For me that was always a pointless plan and the unreadable UTF-8 characters all around buggy software that cannot handle encodings correct (and there are many around) and ignorant users who are using UTF-8 in environments that are not specified for multibyte charsets (IRC) is the most annoying one. UTF-8 was never meant as merely a tool to allow using unicode in non-unicode environments. UTF-32 is useful only as an internal representation if you do care about a string of code points. Since a single character can consist of multiple such code points, it doesn't give you much unless you have to pass every code point through a function like wcwidth() -- ie, you are implementing something low-level which cares about properties of characters and their parts. You should never place UTF-32 into external storage that is not private to your program or can possibly be moved. UTF-16 is never, ever useful. It is a sad trap for win32 and Java developers, due to a bad engineering decision suggested, as I was told, by delegates from Microsoft and Sun, who wanted to conserve disk space and memory by storing separately code points and a language tag -- ie, exactly the thing Unicode was supposed to get us rid of. Even on day one, it was known that you can't fit all characters into 16 bits, and the decision to put all rare characters into a private area that needs out of band information was pretty ridiculous. The end result is, you have an encoding with all downsides of UTF-8 but none of the advantages. Since neither UTF-16 nor UTF-32 can be considered text, the decision all UNIX systems made was to use UTF-8 in the libc's API in all Unicode locales. Otherwise, you'd need separate APIs like FooBarA()/FooBarW() on Windows, which cause no end of problems. So specifying to be UTF-8 capable is somewhat inconsequent. Software has to be capable to handle every encoding as long as they are specified for that encodings. No, there is only one encoding left, as long as you don't have to talk to Windows. We can start purging away all the support for ancient charsets in places that do not need to handle foreign data. Debian has used UTF-8 as default for 5 releases already, and if you try to use an ancient locale, do not expect good results since no one bothers fixing bugs there. And maintaining unused code costs time and causes a risk of bugs, so good riddance! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211133612.ga2...@angband.pl
Bug#612901: O: asused -- To run a check on the usage of your registry's allocations
Package: wnpp Severity: normal X-Debbugs-CC: debian-devel@lists.debian.org I intend to orphan the asused package. It only supports IPv4 and upstream is dead since ages. The package description is: This is a tool used for checking various aspects of IP allocations and assignments as stored in the RIPE database. signature.asc Description: This is a digitally signed message part.
Re: Make Unicode bugs release critical?
On Fr, 11 Feb 2011, Roger Leigh wrote:
Um, no need to be rude.
Well, you started with throw TeX into the bin! (cum grano salis)
The only possible answer to that is mine. Or shutting up and ignoring
that kind of rants from your side.
insults is a step too far. I haven't said anything that could justify
it, other than the fact that you disagree with my /opinion/.
Very simple: replaceing *tex* wiht *xetex* will break existing
documents. And that is a no-go. That is TeX world.
You are taling about WinWord world.
You have apparently no idea between input and font encoding.
I only mentioned UTF-8 with regard to input, so you are assuming
too much.
You mentioned *fontconfig* which is font encoding, and has nothing
whatsoever to do with inputenc. I don't assume too much.
The inputenc hack only gets you so far. I tried to go this way, and
Agreed. Improvements are welcome, please help and fix the
shortcomings.
sorts out the awful font support, so you can use standard
freetype-registered fonts, again without the pain. Result: a
document you can actually read in the editor!
Argg, PLEASE STOP THAT RUBBISH
What you are calling rubbish is not in any way false. It's given
It *IS* wrong.
You are stating that using freetype-registered fonts makes a document
readable by the editor. Sorry this is rediculous.
- different fonts might register themselves under different names
to fontconfig
- fonts might not be available her or there and migh tnot be embedded
in the pdf
DEK wrote his own font loading mechanism because he wanted to be sure
that docuemtns *can* be typeset also on any other machine, and that
works.
If you use xetex that might work, or might not work, or might work
but you are missing suddently some characters
(there is for example a version of the palatino fonts with cyrillic
characters, and a version without cyrillic characters, some systems
have these *enriched* fonts and don't embedd them properly. THen,
suddenly, on the target system, characters disappear. Is THIS
the way you want to typeset documetns?)
I repeat: RUBBISH.
Well I thought the jury was still out on which was the better solution.
Most people I know in the TeX community are seeing the real future with
luatex.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
MARYTAVY (n.)
A person to whom, under dire injunctions of silence, you tell a secret
which you wish to be fare more widely known.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211134338.gh1...@gamma.logic.tuwien.ac.at
Bug#612902: O: arpalert -- Monitor ARP changes in ethernet networks
Package: wnpp Severity: normal X-Debbugs-CC: debian-devel@lists.debian.org I intend to orphan the arpalert package. I no longer use arpalert and active upstream development seems stoped. The package description is: This package provides the arpalert daemon. It listens on a network interface (without using 'promiscuous' mode) and catches all conversations of MAC address to IP request. It then compares the mac addresses it detected with a pre-configured list of authorized MAC addresses. If the MAC is not in list, arpalert launches a pre-defined user script with the MAC address and IP address as parameters. This software can run in daemon mode; it's very fast (low CPU and memory consumption). It responds at signal SIGHUP (configuration reload) and at signals SIGTERM, SIGINT, SIGQUIT and SIGABRT (arpalert stops itself). If you need to use a list of authorized MAC addresses, this package should suit your needs, otherwise arpwatch may be also fine. signature.asc Description: This is a digitally signed message part.
Re: Make Unicode bugs release critical?
Am 11.02.2011 14:02, schrieb Faidon Liambotis: $ echo αβγ | sed 's/./a/' aβγ Okay. But... $ echo αβγ | busybox sed 's/./a/' a�βγ :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d553bf6.9020...@debian.org
Re: Make Unicode bugs release critical?
On Fri, Feb 11, 2011 at 02:30:24PM +0100, Vincent Lefevre wrote: On 2011-02-11 15:33:49 +0500, Andrey Rahmatullin wrote: On Fri, Feb 11, 2011 at 11:14:42AM +0100, Miroslav Kure wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. less has problems with new Unicode characters (bug 597918). Unicode 6.0 came out in october 2010, well after Squeeze's freeze, so you can't expect support for new characters already. There are in no fonts shipped with squeeze, so not recognizing the characters as valid is not a big problem. Less shouldn't maintain a private copy of character properties if all that data is already present in libc -- but guess what, wcwidth(0x1F4A9) and iswprint() don't know them too. So oh well, Squeeze won't display such vital characters as kitten[1], ghost, japanese ogre or pile of shit. Gotta invest in a crystal ball that will tell us what new characters will be. [1]. To see my examples, you can grab: http://angband.pl/debian/pool/main/t/ttf-ancient-fonts/ttf-ancient-fonts_2.52-1.0kb1_all.deb (newer than the version in unstable, Gürkan Sengün's version is 404-compliant, let's poke him so we have _one_ Unicode 6.0 font in Debian). -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211140202.gb2...@angband.pl
Re: Make Unicode bugs release critical?
On Fri, Feb 11, 2011 at 10:43:38PM +0900, Norbert Preining wrote: On Fr, 11 Feb 2011, Roger Leigh wrote: Um, no need to be rude. Well, you started with throw TeX into the bin! (cum grano salis) The only possible answer to that is mine. Or shutting up and ignoring that kind of rants from your side. Please read what I said carefully, rather than imagined slights. I did not at any point state that TeX should be thrown in the bin; that was with regard to broken terminal emulators, editors and tools. I fully believe we should remove obsolete tools which have superior replacements. I did not include TeX in that category. You have apparently no idea between input and font encoding. I only mentioned UTF-8 with regard to input, so you are assuming too much. You mentioned *fontconfig* which is font encoding, and has nothing whatsoever to do with inputenc. I don't assume too much. No, I mentioned fontconfig because XeTeX allows use of system fonts via fontconfig. That was completely separate from UTF-8 input. sorts out the awful font support, so you can use standard freetype-registered fonts, again without the pain. Result: a document you can actually read in the editor! Argg, PLEASE STOP THAT RUBBISH What you are calling rubbish is not in any way false. It's given It *IS* wrong. You are stating that using freetype-registered fonts makes a document readable by the editor. Sorry this is rediculous. - different fonts might register themselves under different names to fontconfig - fonts might not be available her or there and migh tnot be embedded in the pdf [...] I repeat: RUBBISH. I didn't state any of those things. Please calm down, and please read what I actually wrote, rather than what you thought I wrote. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Make Unicode bugs release critical?
On Fr, 11 Feb 2011, Roger Leigh wrote:
read what I actually wrote, rather than what you thought I wrote.
So *what* is your proposal, instead of discussing uselessly and wasting
bytes?
Is it:
ln -sf tex xetex
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
LITTLE URSWICK (n.)
The member of any class who most inclines a teacher towards the view
that capital punishment should be introduced in schools.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211141749.gl1...@gamma.logic.tuwien.ac.at
Re: RFA: all my packages
Reinhard Tartler schrieb am Friday, den 11. February 2011: On Fr, Feb 11, 2011 at 07:12:05 (CET), Alexander Wirt wrote: Decklin Foster schrieb am Thursday, den 10. February 2011: I'm looking for a new maintainer for, well, any of these. My heart is not in it anymore and most of them have been neglected for a while. Recently my free time has been taken up by other things (mainly my job) and I forsee that continuing. http://qa.debian.org/developer.php?login=decklin%40red-bean.com As I am a heavy mpd user I would like to take these over and form a team for mpd related packages. Are they still for adoption? If our team rules/development guidelines (basically the git-buildpackage recommended workflow)suit your development style, you could join and maintain the mpd packages in the pkg-multimedia team: http://wiki.debian.org/DebianMultimedia/ I'm not sure (I am a little bit old-fashioned) but I'll have a look. Thanks for the hint Alex -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211142146.ge3...@smithers.snow-crash.org
question about qq shutdown
Dear Sir or Madam: I am a user of Debian squeeze , and have one unsolved problems here, is I has been install QQ message tools in debian 506 , successfully, and when I use it in 6.0 or others Test version, it will be automatic shutdown, closed , and cant work. Please help me , I try to use others multi messager , and it will still not work with QQ account, you know that it is really popular in China, and please help us solve this problem. maybe I can call the QQ company, but , I wants you know that . thanks. there also have one good news , is that I have been install the TI CCS 5.0.1 ( Code Comprosser Studio ) on squeeze , thanks . and I solved gigabite network card driver problems , and FreeCAD for giveup 3d google sketchup in windows history, and feel the most software is strong. thanks yours bob
Re: Spell checker as reasonable SPAM prevention tool
On Fri, Feb 11, 2011 at 10:19:07AM +0100, Andreas Tille wrote: since some time we get more and more SPAM which is easily to detect for me (and most probably automatically): SPAM in languages I do simply not understand and which are definitely not English. Wouldn't it be a reasonable means for a SPAM filter to mark mails which blatantly fail a spell checker to mark as potential SPAM and just apply this filter to all Debian lists. We have defined languages for each list and the one mail per month were a user just writes in the wrong language by accident will probably not harm the project. I've been thinking about this some as well for my personal domain. Debian has tools that can determine the language of a document (libtextcat and friends). Emails that are 70% or more composed of languages that I have no hope of speaking or understanding (i.e., everything but English, Spanish, French, and Portuguese) would be rejected. I chose 70% as the threshold because sometimes Debian lists get mails from users in both English and another language (in hopes of being understood) and I wouldn't want to penalize those users. I haven't implemented this, but I might at some point. Obviously, this would have to be adjusted per-list; we wouldn't want to reject German-language emails to debian-user-german. I also think language testing is better than spell checking for English because honestly English has a lot of pretty irregular and bizarre spellings; I say this as someone whose native language is English and who spells fairly decently. A spell checker might catch more legitimate emails than we'd like. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Make Unicode bugs release critical?
On 2011-02-11 15:02:02 +0100, Adam Borowski wrote: On Fri, Feb 11, 2011 at 02:30:24PM +0100, Vincent Lefevre wrote: On 2011-02-11 15:33:49 +0500, Andrey Rahmatullin wrote: On Fri, Feb 11, 2011 at 11:14:42AM +0100, Miroslav Kure wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. less has problems with new Unicode characters (bug 597918). Unicode 6.0 came out in october 2010, The character mentioned in my bug report (U+1E9F LATIN SMALL LETTER DELTA) appeared in Unicode 5.1.0 (March 2008). well after Squeeze's freeze, so you can't expect support for new characters already. Well, March 2008 was more than 1 year before Squeeze's freeze. There are in no fonts shipped with squeeze, so not recognizing the characters as valid is not a big problem. Fonts containing the character in question are shipped with Squeeze: the character appears correctly in xterm. Less shouldn't maintain a private copy of character properties if all that data is already present in libc I agree. -- but guess what, wcwidth(0x1F4A9) and iswprint() don't know them too. No problems with U+1E9F: Property alnum : yes Property alpha : yes Property cntrl : no Property digit : no Property graph : yes Property lower : yes Property print : yes Property punct : no Property space : no Property upper : no Property xdigit: no wcwidth = 1 So, if less were using libc, it wouldn't have any problem with this character. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211143511.gj15...@prunille.vinc17.org
Use language determination tool for SPAM prevention (Was: Spell checker as reasonable SPAM prevention tool)
On Fri, Feb 11, 2011 at 02:27:03PM +, brian m. carlson wrote: I've been thinking about this some as well for my personal domain. Debian has tools that can determine the language of a document (libtextcat and friends). So this is even better. Emails that are 70% or more composed of languages that I have no hope of speaking or understanding (i.e., everything but English, Spanish, French, and Portuguese) would be rejected. I chose 70% as the threshold because sometimes Debian lists get mails from users in both English and another language (in hopes of being understood) and I wouldn't want to penalize those users. I haven't implemented this, but I might at some point. Publishing the implementation would be cool. Obviously, this would have to be adjusted per-list; This is for sure obvious and that's why I did not mention this. We have a default language per list which makes for sure a need for configurable filtering per list - but this should be easy enough if we get it implemented at all. we wouldn't want to reject German-language emails to debian-user-german. I also think language testing is better than spell checking for English because honestly English has a lot of pretty irregular and bizarre spellings; I say this as someone whose native language is English and who spells fairly decently. A spell checker might catch more legitimate emails than we'd like. My shot at the spell checker was just to detect a language - it might perfectly be that we have better tools than a spell checker to detect a language in which an e-mail is written in which makes the implementation of the suggestion probably easier. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211143843.gg9...@an3as.eu
RFA: sonata, mpdscribble,...
Hi as I don't use MPD for quite a long time now, it somehow does not make sense to maintain MPD related packages anymore. Simply I don't have environment to test them. The packages given for adoption are: mpdris http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612907 mpdscribble http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612908 python-mpd http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612909 sonata http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612910 -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: RFA: sonata, mpdscribble,...
On Fri, Feb 11, 2011 at 03:14:51PM +0100, Michal Čihař wrote: mpdscribble http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612908 I use this so I'll take care. -- WBR, wRAR signature.asc Description: Digital signature
Re: RFA: sonata, mpdscribble,...
On Fri, 11 Feb 2011 at 15:14:51 +0100, Michal Čihař wrote: as I don't use MPD for quite a long time now, it somehow does not make sense to maintain MPD related packages anymore. Simply I don't have environment to test them. On Decklin Foster's RFA thread, there was talk of forming a mpd team, or possibly maintaining mpd and friends in pkg-multimedia. It'd seem sensible for them all to go to the same team? S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211150306.ga22...@reptile.pseudorandom.co.uk
Re: RFA: sonata, mpdscribble,...
On Fri, Feb 11, 2011 at 03:03:06PM +, Simon McVittie wrote: as I don't use MPD for quite a long time now, it somehow does not make sense to maintain MPD related packages anymore. Simply I don't have environment to test them. On Decklin Foster's RFA thread, there was talk of forming a mpd team, or possibly maintaining mpd and friends in pkg-multimedia. It'd seem sensible for them all to go to the same team? I already have two MPD client packages (qmpdclient and gkrellm-gkrellmpc) so I'm interested too. -- WBR, wRAR signature.asc Description: Digital signature
chromium-browser is taking over all URLs
Hi everyone, esp chromium and mime devs,
since some time chromium has taken over all http/https urls. I checked
every place I could for the correct settings, but I didn't manage to
find the real culprit. It seems that gnome/VTE/whatever uses xdg-open,
which in turn uses gvfs-open.
Reading throught the straces of gvfs-open I see references to mime.
I checked:
- alternatives of: x-www-browser, sensible-browser, www-browser, gnome-browser
and all of them point to iceweasel
- checked the preferred applications in GNOME and it also shows
iceweasel
- checked with
xdg-settings get default-web-browser
also iceweasel
I am a bit lost now where to go, I always get chromium, which I don't want,
but I want to keep it around in case I need it for some web sites.
Please advice anyone?!
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SKELLOW (adj.)
Descriptive of the satisfaction experienced when looking at a really
good dry-stone wall.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211152016.gm1...@gamma.logic.tuwien.ac.at
Re: chromium-browser is taking over all URLs
Norbert Preining prein...@logic.at (12/02/2011): I checked: - alternatives of: x-www-browser, sensible-browser, www-browser, gnome-browser and all of them point to iceweasel - checked the preferred applications in GNOME and it also shows iceweasel - checked with xdg-settings get default-web-browser also iceweasel I am a bit lost now where to go, I always get chromium, which I don't want, but I want to keep it around in case I need it for some web sites. -(cyril@talisker)-(~)-() $ grep x-scheme-handler/http /usr/share/applications/mimeinfo.cache x-scheme-handler/http=midori.desktop;chromium-browser.desktop; x-scheme-handler/https=midori.desktop;chromium-browser.desktop; And it takes precedence over what you quoted. KiBi. signature.asc Description: Digital signature
Re: Make Unicode bugs release critical?
Lars Wirzenius wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. We chose an 80% quickfix to get where we are, and so now we have the other 80% to go. It's been whittled away at for the past 10 years or so, but still a lot left. And, that's utf8 support, only. It's probably a pipe dream to expect other unicode encodings to work half as well, and surely other encodings fare even worse overall. If anything, utf8 probably makes the overall situation worse for other encodings, since we expect it to just work, and give up on handling the other complexity. The first Unicode standard was published in 1991. That's twenty years ago. Any software that processes text at all and is incapable of dealing with UTF-8 should be considered with extreme suspicion. Most languages still make it easy to get wrong, in my experience. It can be as simple as software written trusting language documentation that says strings are processed in unicode and doesn't point out all the exceptions that can let non-unicode data in. For example, this simple haskell program processess a file's content utf-8 cleanly, but prints its name like foö. import System.Environment main = do args - getArgs let file = head args putStrLn $ file is: ++ file putStr = readFile file This program has an entirely different failure mode; type in foö (touch it first), and it will complain that fo� doesn't exist. main = getLine = readFile = putStr Neither of these failure modes is obvious from any documentation I've seen. Both of these programs are something a typical developer would expect to work. (Both also have unexpected failure modes when LANG=C.) Probably every thousand lines of perl has a unicode encoding bug of some sort. Based on data from my own code. Any perl code that uses an XS module probably has an encoding bug. I assume that python had some problems with its unicode support too, since they saw fit to radically change it in python 3. And it sounds like the python 3 changes will break unicode in many programs ported over to it, unless file opens etc are audited and fixed. Stackoverflow has 1600 matches for python unicode questions. The best case is probably a language that has a restructed enough interface that most of these problems are avoided. (But, stackoverflow still has 500 javascript unicode questions.) Making all such bugs be release critical (which includes the notion that release managers may ignore the bug in particular cases) sounds like a good way to get things under control. It would probably be a large load on the RMs. It's easy to pick some random program that works great with unicode and find an edge case. The RMs would probably prefer to not have git getting RC bugs filed just because it sometimes exposes filenames written like fo\303\266. :) -- see shy jo, who deals with at least 1 unicode bug a week on average. 4 this week signature.asc Description: Digital signature
Re: chromium-browser is taking over all URLs
On Fr, 11 Feb 2011, Cyril Brulebois wrote:
$ grep x-scheme-handler/http /usr/share/applications/mimeinfo.cache
x-scheme-handler/http=midori.desktop;chromium-browser.desktop;
x-scheme-handler/https=midori.desktop;chromium-browser.desktop;
And it takes precedence over what you quoted.
Thanks a lot!!!
Ahhh, and how does one fix that? This is misbehaviour. Whom should
this bug reported to? mime or chromium?
The point is that xdg/gvfs/whatever should use what is configured for
it.
Why do we need:
- *-browser in alternatives
- dedicated gnome setting
- whatever else
if at the end gvfs-open uses mime which is messed up?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
GREELEY (n.)
Someone who continually annoys you by continually apologising for
annoying you.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211154947.ga30...@gamma.logic.tuwien.ac.at
Re: RFA: all my packages
On Thu, 10 Feb 2011 17:11:05 -0500, Decklin Foster wrote: I'm looking for a new maintainer for, well, any of these. My heart is not in it anymore and most of them have been neglected for a while. http://qa.debian.org/developer.php?login=decklin%40red-bean.com I move the two perl packages: liblivejournal-perl libpoe-component-client-ping-perl to the pkg-perl group. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Dire Straits: Romeo And Juliet signature.asc Description: Digital signature
Re: chromium-browser is taking over all URLs
On 11/02/11 16:49, Norbert Preining wrote: On Fr, 11 Feb 2011, Cyril Brulebois wrote: $ grep x-scheme-handler/http /usr/share/applications/mimeinfo.cache x-scheme-handler/http=midori.desktop;chromium-browser.desktop; x-scheme-handler/https=midori.desktop;chromium-browser.desktop; And it takes precedence over what you quoted. Thanks a lot!!! Ahhh, and how does one fix that? This is misbehaviour. Whom should this bug reported to? mime or chromium? I noticed the same issue here a few days ago. Adding the x-scheme-handler/http;x-scheme-handler/https; entries to iceweasel.desktop doesn't really solve the issue, because there doesn't seem to be a mechanism to define priorities in update-desktop-database, so gvfs-open uses the first entry in mimeinfo.cache. I'd say it should probably be reported as a minor bug in gvfs-open, to respect gnome settings before falling back to mimeinfo.cache. Thoughts? Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ij3n4d$jes$1...@dough.gmane.org
Re: chromium-browser is taking over all URLs
iceweasel.desktop doesn't really solve the issue, because there doesn't
seem to be a mechanism to define priorities in update-desktop-database,
so gvfs-open uses the first entry in mimeinfo.cache.
Umpf, so we are either forced to always use what comes
alphabetically first, or remove packages?
I'd say it should probably be reported as a minor bug in gvfs-open, to
respect gnome settings before falling back to mimeinfo.cache.
I consider that not minor. If alphabetic order is what I am forced to
live with, that is 60ies computing style.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCRONKEY (n.)
Something that hits the window as a result of a violent sneeze.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211161500.gc1...@gamma.logic.tuwien.ac.at
Re: Make Unicode bugs release critical?
Excerpts from Joey Hess's message of Sex Fev 11 13:39:08 -0200 2011: (...) It can be as simple as software written trusting language documentation that says strings are processed in unicode and doesn't point out all the exceptions that can let non-unicode data in. For example, this simple haskell program processess a file's content utf-8 cleanly, but prints its name like foö. import System.Environment main = do args - getArgs let file = head args putStrLn $ file is: ++ file putStr = readFile file This program has an entirely different failure mode; type in foö (touch it first), and it will complain that fo� doesn't exist. main = getLine = readFile = putStr Neither of these failure modes is obvious from any documentation I've seen. Both of these programs are something a typical developer would expect to work. (Both also have unexpected failure modes when LANG=C.) http://hackage.haskell.org/trac/ghc/ticket/3307 Greetings. (...) signature.asc Description: PGP signature
Re: RFA: sonata, mpdscribble,...
Hi Dne Fri, 11 Feb 2011 15:03:06 + Simon McVittie s...@debian.org napsal(a): On Fri, 11 Feb 2011 at 15:14:51 +0100, Michal Čihař wrote: as I don't use MPD for quite a long time now, it somehow does not make sense to maintain MPD related packages anymore. Simply I don't have environment to test them. On Decklin Foster's RFA thread, there was talk of forming a mpd team, or possibly maintaining mpd and friends in pkg-multimedia. It'd seem sensible for them all to go to the same team? It would definitely make sense to maintain them together. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: RFA: sonata, mpdscribble,...
Michal Čihař schrieb am Friday, den 11. February 2011: Hi as I don't use MPD for quite a long time now, it somehow does not make sense to maintain MPD related packages anymore. Simply I don't have environment to test them. The packages given for adoption are: mpdris http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612907 mpdscribble http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612908 python-mpd http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612909 sonata http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612910 In general it would be good if all those package would be maintained under the to be formed new mpd team. I'll request a new alioth project for mpd later. It would be nice to have all mpd related packages in that team. Alex signature.asc Description: Digital signature
Re: RFA: all my packages
Alexander Wirt schrieb am Friday, den 11. February 2011: Decklin Foster schrieb am Thursday, den 10. February 2011: I'm looking for a new maintainer for, well, any of these. My heart is not in it anymore and most of them have been neglected for a while. Recently my free time has been taken up by other things (mainly my job) and I forsee that continuing. http://qa.debian.org/developer.php?login=decklin%40red-bean.com As I am a heavy mpd user I would like to take these over and form a team for mpd related packages. Are they still for adoption? Just for the record - I created pkg-mpd on alioth. Feel free to join if you are interested in maintaing mpd related packages. Alex -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211183326.gh3...@smithers.snow-crash.org
Re: Make Unicode bugs release critical? (was: Re: RFA: all my packages)
Hi, Adam Borowski wrote: Speaking of rxvt... shouldn't this clusterϫϫck become the only rxvt in Debian? Both rxvt and rxvt-beta, completely dead upstream for 10 and 8 years respectively, besides having terrible support for terminal codes lack even such a tiny detail as UTF-8 support. I'd say there should be no place in Debian in 2011 for software that can't do UTF-8, especially if near-identical forks exist. I'd replace especially with only in that sentence. Kicking out good and unique software, only because of missing or incomplete UTF-8 support, will surely lower Debian's quality more than missing or broken UTF-8 support in very few packages. And it would make those users (and devs) angry who need that software independently of working UTF-8 support or not. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211183343.gp12...@sym.noone.org
Bug#612941: ITP: python-iso8601 -- python module to parse ISO 8601 dates
Package: wnpp Severity: wishlist Owner: Benjamin Mako Hill m...@debian.org * Package name: python-iso8601 Version : 0.1.4 Upstream Author : Michael Twomey micktwomey+iso8...@gmail.com * URL : https://code.google.com/p/pyiso8601/ * License : MIT Programming Lang: Python Description : python module to parse ISO 8601 dates Many file formats and standards use the ISO 8601 date format (e.g. 2007-01-14T20:34:22+00:00) to store dates in a neutral, unambiguous manner. This simple Python module parses the most common forms encountered and returns Python datetime objects. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211185727.19038.1548.report...@istek.yukidoke.org
Re: Make Unicode bugs release critical?
On Fri, Feb 11, 2011 at 09:37:54AM +, Lars Wirzenius wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. ispell, aspell. I think hunspell got fix recently. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211203240.ga30...@roeckx.be
Re: Spell checker as reasonable SPAM prevention tool
On Fri, Feb 11, 2011 at 10:19:07AM +0100, Andreas Tille wrote:
[...]
I assume that a spell checker can be configured that way that it
can distinguish between writing an English text with some /
several mistakes and a text with say 50% error rate which is
probably not understandable anyway.
But could it reliably pass MBF announcements which are 99% package
names and (often numerous non-English) maintainer names? Or a
message which is 80% C source code because it contains a patch under
discussion? Those definitely seem to me like important test cases,
at least, which I don't think most human-language-oriented
spell-checkers would deal with well (though I'd love to be proven
wrong!).
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211211650.go9...@yuggoth.org
Bug#612953: ITP: jam-lib -- Java applications look and behave like native applications
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: jam-lib Version : SVN R297 Upstream Author : Andrew Rambaut a.ramb...@ed.ac.uk * URL : http://code.google.com/p/jam-lib/ * License : LGPL-3+ Programming Lang: Java Description : Java applications look and behave like native applications JAM provides classes for building desktop applications that look and behave like native applications. applications created using JAM will look native on Mac, Windows and Linux/UNIX machines. The packaging seems to be ready (modulo asking Debian Java team for checking) and is available at svn://svn.debian.org/svn/debian-med/trunk/packages/libjam-java/trunk/ It could be maintained by Debian Med team because it is a precondition for Java Evolutionary Biology Library. If somebody thinks this in principle not medicine / bio-medicine related package should better go under Debian Java hood that's fine as well. -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (50, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211211742.29440.22970.report...@mail.an3as.eu
Re: Upcoming FTPMaster meeting
On Thu, 10, Feb, 2011 at 09:43:08PM +0100, Sandro Tosi spoke thus.. On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert jo...@ganneff.de wrote: * Throwaway DD built .debs (well, let's have the fight^Wdiscussion) could you please keep in mind the bandwidth impaired and try something that avoids to upload those binary packages in the first place? but also something that avoids the risk of uploads without even trying to build the package first. To be honest, I've always thought that if people are doing that, we have bigger problems anyways. I don't really like the throw away debs idea personally (it seems a complete waste of bandwidth, time and effort), and would much rather go to source-only uploads. The opinions within the ftpteam vary on this though, so it's something we're going to have to figure out. Of course, this is orthogonal to having buildd support for .all debs which needs discussing with the buildd team. Mark -- Mark Hymers mhy at debian dot org That's why the good die young; it's because Death can't be bothered to check the paperwork. Andy Hamilton, Old Harry's Game -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211212908.ga8...@hymers.org.uk
Re: Upcoming FTPMaster meeting
On Thu, 10, Feb, 2011 at 09:27:14PM +0100, Josselin Mouette spoke thus.. Le jeudi 03 février 2011 à 22:05 +0100, Joerg Jaspert a écrit : Attached below is a tentative agenda. This is an unsorted list and we might not get to every point. We might also have missed any number of points, if so feel free to tell us about them. Would it be possible to add support for ddebs? I'll stick it on the agenda. I assume the details at http://wiki.debian.org/AutomaticDebugPackages are the most up to date notes you know of? Thanks, Mark -- Mark Hymers mhy at debian dot org ++?++ Out of Cheese Error. Redo From Start. Interesting Times, Terry Pratchett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211213019.gb8...@hymers.org.uk
Re: chromium-browser is taking over all URLs
See http://bugs.debian.org/612876 for the bug report. I encountered the same issue, and finally found the culprit through reading the chromium-browser changelog. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211213427.GA1939@feather
Re: Upcoming FTPMaster meeting
On Thu, 03 Feb 2011, Joerg Jaspert wrote: * Throwaway DD built .debs (well, let's have the fight^Wdiscussion) This would allow 1) distribution-wide compilation options (for solving things like #552688) 2) distribution-wide debbuging debs 3) uniform, known build environments the only major concern I keep hearing is bandwidth wasted in uploading throwaway binary debs, but as we currently spend that bandwidth anyway, that seems to be making the perfect the enemy of the good. [And we can fight the fight of whether to throw away the debs or allow binary-less uploads later.] Don Armstrong -- Your village called. They want their idiot back. -- xkcd http://xkcd.com/c23.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211220045.gu17...@rzlab.ucr.edu
Re: Make Unicode bugs release critical?
On Fri, 11 Feb 2011, Lars Wirzenius wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. 1. Stuff that cannot do one of UTF-8, UTF-16 or UCS-4. 2. Anything that cannot deal with Supplementary planes. This includes the use of UCS-2 instead of UTF-16, as it cannot represent the Supplementary planes. python 3 when not compiled to use UCS-4 memory hog mode is an example, I am told. We likely want to restrain ourselves to declaring (1) to be release critical for Wheezy. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211221653.gb18...@khazad-dum.debian.net
Re: Make Unicode bugs release critical?
On 02/11/2011 07:36 AM, Adam Borowski wrote: [snip] UTF-16 is never, ever useful. It is a sad trap for win32 and Java developers, due to a bad engineering decision suggested, as I was told, by [snip] No, there is only one encoding left, as long as you don't have to talk to Windows. Never useful except for 90% of the market? (I wonder how SAMBA deals with it...) -- The normal condition of mankind is tyranny and misery. Milton Friedman -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d55c263.90...@cox.net
Re: Use language determination tool for SPAM prevention (Was: Spell checker as reasonable SPAM prevention tool)
[Andreas Tille] On Fri, Feb 11, 2011 at 02:27:03PM +, brian m. carlson wrote: I've been thinking about this some as well for my personal domain. Debian has tools that can determine the language of a document (libtextcat and friends). So this is even better. Amazingly, SpamAssassin has a plugin based on the same algorithm as libtextcat. man Mail::SpamAssassin::Plugin::TextCat for SpamAssassin configuration information. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110212000858.ga10...@p12n.org
Re: Upcoming FTPMaster meeting
On Fri, 4 Feb 2011 08:20:02 +0100 Raphael Hertzog hert...@debian.org wrote: I have not seen any word about XZ support. When you deployed support for new source package formats, you forbid lzma because xz was coming along and you mentioned that wheezy could have xz enabled. I would like to see xz allowed both for source package and for binary packages. I want XZ support too, at least it reduce size for some font packages. e.g. $ ls -al otf-yozvox-yozfont*.deb -rw-r--r-- 1 henrich henrich 31053028 2011-02-12 08:33 otf-yozvox-yozfont-antique_13.03-dfsg-1+xz_all.deb -rw-r--r-- 1 henrich henrich 42877382 2011-02-12 08:46 otf-yozvox-yozfont-antique_13.03-dfsg-1_all.deb -rw-r--r-- 1 henrich henrich 20955718 2011-02-12 08:35 otf-yozvox-yozfont-cute_13.03-dfsg-1+xz_all.deb -rw-r--r-- 1 henrich henrich 29832102 2011-02-12 08:47 otf-yozvox-yozfont-cute_13.03-dfsg-1_all.deb -rw-r--r-- 1 henrich henrich 21121674 2011-02-12 08:37 otf-yozvox-yozfont-edu_13.03-dfsg-1+xz_all.deb -rw-r--r-- 1 henrich henrich 30301632 2011-02-12 08:47 otf-yozvox-yozfont-edu_13.03-dfsg-1_all.deb -rw-r--r-- 1 henrich henrich 21234852 2011-02-12 08:27 otf-yozvox-yozfont-new-kana_13.03-dfsg-1+xz_all.deb -rw-r--r-- 1 henrich henrich 30294686 2011-02-12 08:45 otf-yozvox-yozfont-new-kana_13.03-dfsg-1_all.deb -rw-r--r-- 1 henrich henrich 31286774 2011-02-12 08:30 otf-yozvox-yozfont-standard-kana_13.03-dfsg-1+xz_all.deb -rw-r--r-- 1 henrich henrich 42864814 2011-02-12 08:46 otf-yozvox-yozfont-standard-kana_13.03-dfsg-1_all.deb -rw-r--r-- 1 henrich henrich 4642 2011-02-12 08:25 otf-yozvox-yozfont_13.03-dfsg-1+xz_all.deb -rw-r--r-- 1 henrich henrich 4872 2011-02-12 08:45 otf-yozvox-yozfont_13.03-dfsg-1_all.deb 2/3 size, extremely efficient :) -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110212085417.18a526d4.henr...@debian.or.jp
Re: Make Unicode bugs release critical?
[Ron Johnson] Never useful except for 90% of the market? (I wonder how SAMBA deals with it...) I don't think you really want to know. There's a 'unicode' flag in much of the CIFS protocol that means filenames and such are in UTF-16 (I think UTF-16LE) instead of some-random-configured-code-page. Samba's been using that flag for about 10 years. You configure it to say what encoding your filenames are supposed to be on the server, and it expresses them in UTF-16 on the wire. Samba also supports non-Unicode-aware clients like Windows 3.11 - or at least it used to support these - you'd tell Samba what client code page to translate your filenames into on the wire. Fun stuff. Samba doesn't really deal with file _contents_, which is a much more interesting problem than filenames. It just serves contents as-is, like most file service protocols other than FTP. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110212003312.gb10...@p12n.org
Re: Make Unicode bugs release critical?
On Fri, Feb 11, 2011 at 08:16:54PM -0200, Henrique de Moraes Holschuh wrote: On Fri, 11 Feb 2011, Lars Wirzenius wrote: However, I'm curious: is there a lot of software that is broken with Unicode, particularly with the UTF-8 encoding? I can't remember anything much in recent times. 2. Anything that cannot deal with Supplementary planes. This includes the use of UCS-2 instead of UTF-16, as it cannot represent the Supplementary planes. python 3 when not compiled to use UCS-4 memory hog mode is an example, I am told. Using UCS-2 is hardly better than using ISO-8859-1 or any other ancient charset. Using either UTF-16 or UCS-4 can be a memory hog, that's why to pick UTF-8 for regular use. Except for some rare cases (CJK with no formatting or markup), it uses less memory and can be passed as-is to POSIX file functions. Picking a random subset of Unicode is like putting day-of-the-year in one byte variable since this way you support 70% of uses and it conserves memory... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110212020220.ga26...@angband.pl
Re: Make Unicode bugs release critical?
On Sat, 12 Feb 2011, Adam Borowski wrote: On Fri, Feb 11, 2011 at 08:16:54PM -0200, Henrique de Moraes Holschuh wrote: 2. Anything that cannot deal with Supplementary planes. This includes the use of UCS-2 instead of UTF-16, as it cannot represent the Supplementary planes. python 3 when not compiled to use UCS-4 memory hog mode is an example, I am told. Using UCS-2 is hardly better than using ISO-8859-1 or any other ancient charset. Using either UTF-16 or UCS-4 can be a memory hog, that's why to pick UTF-8 for regular use. Except for some rare cases (CJK with no Python 3 uses UCS-2 (or UCS-4) for the internal representation. Likely they wanted to have something that made it easy to address each character in an Unicode string in O(1). That might actually give better performance given how much people like to do string slicing and splicing in python. The O(N) often required by UTF-8 and UTF-16 might well be more painful than the much larger data cache footprint of UCS-4... but that is a damn big *maybe*, and very unlikely to be consistent across very different architectures. Well, not like I care. I don't even have Python 3 installed, and I will only do so the day something I need decides to pull it as a dependency. Picking a random subset of Unicode is like putting day-of-the-year in one UCS-2 is deprecated as all heck. As far as I could research through Google, it is not a valid Unicode representation since Unicode 2.0 (i.e. 1996). So it wouldn't even count as a random subset of Unicode. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110212035533.ga32...@khazad-dum.debian.net
Job positions - Offre d'emploi
Bonjour, Nous sommes présentement à la recherche de staff de bar et de promoteurs. Vous aimez sortir et vous voulez faire beaucoup d'argent ? Cette annonce vous est personellement adressée ! Nous lançons notre nouvelle compagne de recrutement de promoteurs et staff de bar et toutes les candiatures seront étudiées afin de vous offrir la chance de faire partie d'une équipe unique ! Une formation rémunérée sera offerte à tous les candidats et candidates qui seront sélectionnés(ées). Si vous êtes intéressés par ces positions, veuillez nous envoyer un courriel à cette adresse : j...@bainsdouches.ca PS : Pour une désinscription rapide et immédiate de notre liste de diffusion, veuillez répondre a ce courriel en mentionnant votre demande. Votre adresse courriel sera supprimée définitivement de notre base de données.
