Bug#278086: ITP: scim-m17n -- M17N Input Method Engine for SCIM
Package: wnpp Severity: wishlist * Package name: scim-m17n Version : 0.1.3 Upstream Author : James Su <[EMAIL PROTECTED]> * URL : http://www.freedesktop.org/ * License : (GPL2) Description : M17N Input Method Engine for SCIM . M17N (Multilingualization) Input Method Engine enables SCIM to input many non-latin characters from the keyboard using libm17n library. . Author: James Su <[EMAIL PROTECTED]> . For details about SCIM, please see the description of package scim. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Test package together with all other updated version of SCIM at deb http://people.debian.org/~osamu/package/ ./ deb-src http://people.debian.org/~osamu/package/ ./ This is maintained by few people now as a part of SCIM packages. Ming Hua <[EMAIL PROTECTED]> is leading but I do some parts too. Once pkg-scim at alioth accepted, we will move there. -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]> Brussels Belgium, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' "Our Priorities are Our Users and Free Software" --- Social Contract
Bug#278084: ITP: scim-hangul -- Hangul Input Method Engine for SCIM
Package: wnpp Severity: wishlist * Package name: scim-hangul Version : 0.1.2 Upstream Author : James Su <[EMAIL PROTECTED]> * URL : http://www.freedesktop.org/ * License : (GPL2) Description : Hangul Input Method Engine for SCIM SCIM (Smart Common Input Method) is an input method (IM) platform. . Hangul Input Method Engine enables SCIM to input Hangul (Korean) characters from the keyboard using the plugin modules and the data files. . Author: James Su <[EMAIL PROTECTED]> . For details about SCIM, please see the description of package scim. Test package together with all other updated version of SCIM at deb http://people.debian.org/~osamu/package/ ./ deb-src http://people.debian.org/~osamu/package/ ./ This is maintained by few people now as a part of SCIM packages. Ming Hua <[EMAIL PROTECTED]> is leading but I do some parts too. Once pkg-scim at alioth accepted, we will move there. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]> Brussels Belgium, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' "Our Priorities are Our Users and Free Software" --- Social Contract
debian.org e-mail address and SPF/SRS
Hi, Disclaimer: I am not asking Debian to use SPF[1] to filter incoming ML posts. If this has been discussed, excuse me. I am facing a problem with my ISP started filtering incoming mails with SPF. Since AOL adopted it, it seems becoming quite popular as I see it. I understand my ISP's rationale which is to reduce virus mails hitting ISP's mail server. I also understand that SPF will not be a bullet proof against mail forgery. It also seems that it is a relatively low CPU time cost method to reduce unwanted incoming messages. This SPF has caused very annoying problem to some people who implemented proper SPF policy with "-all" and tried to send me an e-mail through my DD account. The forwarded mail from Debian is REJECTED due to SPF policy on my ISP side.[2] SPF has known issue with e-mail forwarder such as pobox.com. I think debian.org mail address is no exception. This is expected behavior. Since debian.org address is used frequently used to receive debian bug report, this is not a desirable situation. Unless some serious concern was raised here, I think implementing SRS[3] type infrastructure will be nice. If you know easy way to avoid this problem exists, please let me know. (Changing ISP is certainly an option.) If it is a good idea to implement SRS at debian.org mail server, let's consider. Regards, Osamu References: [1] http://spf.pobox.com/mechanisms.html [2] Currently my ISP reject mail with "-all" policy. [3] http://spf.pobox.com/emailfwdpng.html
Re: debian.org e-mail address and SPF/SRS
Hi, On Thu, Nov 04, 2004 at 12:22:30PM +0100, Stephane Bortzmeyer wrote: > On Thu, Nov 04, 2004 at 12:15:19AM +0100, > Osamu Aoki <[EMAIL PROTECTED]> wrote > a message of 47 lines which said: > > > If you know easy way to avoid this problem exists, please let me > > know. > > I remail my email from debian.org machines, I do not forward it. So, I > do not have the problem (I have others, but it is a different story). > > master:~ % cat .procmailrc > > :0 > ! [EMAIL PROTECTED],[EMAIL PROTECTED] I though BSMTP is the only way and I never got around to do it [1]. This is so easy. I should have thought about it. Just did it. I hope this is not heavy on our server :-) Thanks, Osamu [1] http://people.debian.org/~osamu/memo.html
svn.debian.org
It took me a while to get SVN access to some projects at svn.debian.org. It will be nice if someone can update web page contents of svn.debian.org. Osamu - Here is example with pkg-ime. Although svn.debian.org lists for SubVersionN: svn://svn.debian.org/pkg-ime/ most obvious action caused as follows: $ svn co svn://svn.debian.org/pkg-ime/ svn: Can't open file '/svn/pkg-ime/format': Permission denied (This may be related to #debian-devel message "alioth: filesystems at 90+%, wrong perms") Alternative URL guessing from actual absolute path: $ svn co svn://svn.debian.org/svn/pkg-ime/ svn: Can't open file '/svn/svn/pkg-ime/format': Permission denied Then I tried (I have write access, so svn over ssh should work) $ svn co svn+ssh://svn.debian.org/pkg-ime/ svn: No repository found in 'svn+ssh://svn.debian.org/pkg-ime' Of couse, svn+ssh with absolute path /svn/pkg-ime/ worked but this is not so obvious from this svn.debian.org. But short message stating svn+ssh requires prepending of /svn/ or change all the listed URL to be with /svn/ may be more useful. (Assuming permission issues are gone and symlink svn --> . works) Osamu
Re: debian.org e-mail address and SPF/SRS
On Fri, Nov 05, 2004 at 06:31:05PM +0100, Osamu Aoki wrote: > Hi, > > On Thu, Nov 04, 2004 at 12:22:30PM +0100, Stephane Bortzmeyer wrote: > > On Thu, Nov 04, 2004 at 12:15:19AM +0100, > > Osamu Aoki <[EMAIL PROTECTED]> wrote > > a message of 47 lines which said: > > > > > If you know easy way to avoid this problem exists, please let me > > > know. > > > > I remail my email from debian.org machines, I do not forward it. So, I > > do not have the problem (I have others, but it is a different story). > > > > master:~ % cat .procmailrc > > > > :0 > > ! [EMAIL PROTECTED],[EMAIL PROTECTED] > > I though BSMTP is the only way and I never got around to do it [1]. > > This is so easy. I should have thought about it. Just did it. > > I hope this is not heavy on our server :-) Sigh, it does not fool SPF with this way. I resolved with DNS of imy counter part to use "softfail" ~all I guess I lern to set up BSMTP if I want to use debian.org without help from ISP. > [1] http://people.debian.org/~osamu/memo.html Osamu
Packaging true type fonts with minor variation
Hi folks,
I have a question on how to package true type fonts while making tiny
section of fonts to be made debconf selectable.
(This is related to ttf-arphic-{ukai|uming} font packages.)
Current solution I suggested to the packager was to provide binary diff
and apply it everytime debconf are run. (Yes we need a set of diff
files to patch and unpatch.)
But this is not really elegant. If I know the true type font file
structure better, maybe there is better solution.
If this is done properly, we can have an unicode fonts with its font style
customizable per each section
Anyone?
Osamu
--
Example of minor font change: 0 with/without center dot
Re: dependancy issues
On Mon, Jan 03, 2005 at 01:01:03AM +0100, Josselin Mouette wrote: > Le dimanche 02 janvier 2005 à 12:49 -0600, Steve Greenland a écrit : > > On 01-Jan-05, 21:14 (CST), Marc Wilson <[EMAIL PROTECTED]> wrote: > > > On Sat, Jan 01, 2005 at 05:07:42PM -0800, Carl B. Constantine wrote: > > > > I'm trying to trim my system a little bit. I wanted to purge Evolution > > > > from my system since I use Mutt for email. But doing that wants to > > > > remove Gnome. > > > > > > So it wants to remove the Gnome meta-package. So what? > > > > So doing so causes all the packages that the gnome meta-package depended > > on to be de-installed, if one is using package tool that tracks packages > > that were installed to fulfill a dependency; aptitude, for example. This > > can be disconcerting. > > > > It means you need to go in and (re-)select all the smaller > > meta-packages, etc. that you actually want to keep. Yep. That is a lot of "m". If new dependency is added with updated version of gnome package, we will never know :-( > Why in the world would you then want to install a metapackage if its > selection doesn't suit you? These meta packages are like recommendation package for me. If everyone uses "aptitude" with option for installing recommended packages turned on, these packages should be listed under "Recommends:" instead of "Depends:". I guess these are listed under "Depends" because the auto install should work under apt-get command etc.. The use of commands from "equivs" package seems to be only available work around. Maybe some easy access to equivs functionality from aptitude is desired feature for post sarge aptitude.
Re: library packaging doc...
On Mon, Jan 31, 2005 at 06:24:31PM +0100, Martin Schulze wrote: > Osamu Aoki wrote: > Or see and follow the instructions summarised on > http://master.debian.org/~joey/misc/webwml.html#ddp > > > PS: If you are in rush, I or javi should be able to add you as a pserver > > access user just like other non-DD. We need to check out CVSROOT/passwd > > file or so, I think. I have not done it. > > Negative. > > See above. Thanks for the clarification. Can you clarify what these DDP CVS messages means http://lists.debian.org/debian-doc/2005/01/msg00046.html There passwd file has commit from your account :-) Are they just bogus noise to list? Or you only have write access? We do not. It is owned by cvs_doc group. You mean cvs repouid patch limit access to the passwd file from non-pserver users too? Just curious. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
On Sat, Feb 05, 2005 at 10:46:27PM +0900, Junichi Uekawa wrote: > Hi Joey > > > > > > > Just request to [EMAIL PROTECTED] while pointing them our message on > > > this list. > > > > Or see and follow the instructions summarised on > > http://master.debian.org/~joey/misc/webwml.html#ddp > > > According to the page you pointed to, it seems to tell me > that I should send request to you, > after approval of debian doc people. Yes. But I thought previous discussion omplicitly gave you a status of being part of debian-doc. > Hereby I am sending a request. Just to be sure... hereby agreeing and requesting him a part of the group. > I consider that with this thread debian-doc people have given approval. Good luck. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tips wanted for debugging and testing Debian
On Tue, Mar 01, 2005 at 05:54:30PM +0100, Sascha Berkenkamp wrote: > * Adam Majer <[EMAIL PROTECTED]> [21:05h, 24.02.2005]: > > [Debian for Debugging and Testing] > > > http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot > > thank you. I tried it out and it works very good. Much more better and > more user friendly than emulating a second Debian via Bochs or other > emulator. > I like it to work from my _new_ Debian from a new console like tty10 or > something else. Please also look into pbuilder package once you get to understand some basics of cheroot. This is specialized chroot script which does a bit more than simple debootstrap described above too. See the latest (sid) version of maint-guide package (Section 7.6) for starting hints for what pbuilder does. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: self-depending packages
On Tue, Mar 01, 2005 at 12:13:56PM -0600, Adam Heath wrote: > On Tue, 1 Mar 2005, Tollef Fog Heen wrote: > > > * Antti-Juhani Kaijanaho > > > > | On 20050228T204520+, Andrew Suffield wrote: > > | > On Mon, Feb 28, 2005 at 09:49:41PM +0200, Antti-Juhani Kaijanaho wrote: > > | > > On 20050228T164806+, Andrew Suffield wrote: > > | > > > Unfortunately apt breaks the code. If you use dpkg directly it'll > > | > > > work. If you use apt it'll pick a random and unpredictable starting > > | > > > point. > > | > > > > | > > Doesn't apt usually unpack all packages first and then configure them > > in > > | > > one run, so that shouldn't matter? > > | > > > | > dpkg does the same thing > > | > > | So how does apt break it but using dpkg doesn't? > > > > apt invokes dpkg on the command line and due to maximum command line > > length it sometimes is split in an unfortunate place. > > > > This will be fixed once dpkg is librarified. > > Er, no, it won't. > > That part of dpkg is not set to be turned into a library. Then any plan to impliment command sequence to obtain package name from standard input? $ echo package-1 package-2 | dpkg -i -- - Maybe these are discussed already in BTS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Right Way to turn a native package in a non native package with a NMU
On Wed, Mar 09, 2005 at 07:03:41PM -0300, Lucas Wall wrote: > On 03/09/2005 03:35 AM, Christian Perrier wrote: > > >The .dsc file contains: > >.../... > >Files: > > fb6549efbab887efea88a8fcc4b4319f 451517 gnome-find_1.0.2.orig.tar.gz > > 7ea07e4e9226648422fb7a83d066ffe8 3400 gnome-find_1.0.2-1.1.diff.gz > > > >And the .changes: > >.../... > >Files: > > 733af0b63b2a63ac5ec3df7e46a9633a 659 utils optional > > gnome-find_1.0.2-1.1.dsc > > 7ea07e4e9226648422fb7a83d066ffe8 3400 utils optional > > gnome-find_1.0.2-1.1.diff.gz > > afea158735d04857e728d50312e17f7c 161412 utils optional > > gnome-find_1.0.2-1.1_i386.deb > > As waldi pointed out use -sa. The orig file should appear in the changes > file as well, not only the dsc. Yep. I think I added -sa option hints to new maint-guide recently since I scratch my head several times too when I cleaned BTS :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration -- TeX related FTBFS
Hi, I realize TeX is tough program to maintain. Thanks to Frank. One quick and easy way to avoid TeX related build issues are to avoid using TeX related tools during build time. So the results will be Debian only ships documentations in plain text and HTML. (No PS and no PDF). But is it what we should do? On Sat, Dec 17, 2005 at 01:38:25PM +1000, Anthony Towns wrote: > On Fri, Dec 16, 2005 at 11:24:39AM +0100, Frank Küster wrote: ... > > It's been in experimental for more than half a year. > > Err, that's kind of absurdly long too. But I din not use it then :-( ... > Six months is a lot of time; and experimental should provide you with > the space and machine power to handle the rebuilding. Yes and no. Rebuilding "Debian Reference" takes few hours on 2GHz machine. So it is not easy but possible with 6 months. But tracking down cause of failure is not that simple. tetex-base has over 70MB as installed (bigger than kernel source.) So it is quite time consuming and close to impossible for non-tex expert. > I don't know how > many source changes are necessary to do the rebuilding, though. The changes may be few strings but ... where? > > So either we could have delayed teTeX 3.0 until > > god-knows-when, > > Uh, no. The whole point is to delay _less_, not more. Yes. Many document build scripts implement some special case fix thus it will break with upgrades. Also new major upgrade tends to pull in minor bugs into huge tetex package. Thus these will cause FTBFS (RC) bugs on many documentation packages whose maintainers are not always ready for making complicated adjustment to TeX upgrades. Recent changes to TeTeX 3 was easier than woody days. For example, when I got FTBFS RC bug due to tetex, I reassigned it to tetex. I should have reduced severity but I did not do it partly because of my wish to get Frank's attention and his assistance to fix it from Tetex package. Sorry. This may be the reason Frank felt about FTBFS/RC. It is not FTBFS for him and that was not RC for him. I wish that tetex upgrade happens more like gcc upgrades. So testing both versions are much easier and, if needed, we can specify older version ones. > > Much worse, there are a couple of cases where we had to NMU the > > packages, either because the maintainers where inactive, or in one case > > because he said "no time here, just go ahead". Except for this one case > > this couldn't have been done with the packages in experimental, since > > failing to cooperate with a package in experimental isn't RC, is it? > > Not only do you not have to have an RC bug as an excuse to NMU; but > uploads to experimental (which these presumably would be) have even less > need for care and caution. > > > Of course, in principle, we could have created our own > > "compatible_with_teTeX-3.0" repository and uploaded fixed packages > > there, and do all the testing there. But then I don't understand what > > unstable is for... > > Generally, experimental fits the above role. Unstable's for uploading new > development of packages that will hopefully work, but might turn out not > to. In particular, though, they need to be fixed pretty quickly -- six > months in experimental, and another two so far in unstable isn't quickly. I agree. > > Yes, the problem is that bugs in other packages keep popping up slowly. > > Like #341849 in debiandoc-sgml: We already had checked that > > debiandoc-sgml didn't have one of the "usual" incompatibility bugs, but > > then it turned out that there is still one, which is only triggered when > > a far-east document is typeset in a certain encoding. It was FTBFS for documentation packages which used debiandoc-sgml. > "A far-east document is typeset in a certain encoding" doesn't sound like > an RC bug; and therefore not something that should hold up transitioning > to testing. Certainly, fix it ASAP once it's found, but that's the > desired result for any bug. Exactly. I should have reduced severity. ... > > That would be bad, but I can't see how I can speed up tetex's evolution > > to be releasable by letting it rot in experimental. > > That's true; the idea isn't to let it rot in experimental, it's to have > a quick pass through experimental that catches the most obscene bugs, > then to put it in unstable where you catch a few more, then to let > things progress to testing naturally, if necessary by having the RMs > remove tetex related packages that aren't getting updated to the latest > version in a timely or successful fashion. I think one to ease tension is to make tetex packages to coexist in archive just like many gcc. Current strict FTBFS rule will likely to make many documentations provided only in HTML, I think. Because fixing TeTeX related PDF/PS generation issues are quite difficult with short notice without tetex maintainer helping us. (They usually do.) We do not have soft and slow transition like gcc. I hope situation will be better soon but I am still struggling
Re: buildd administration -- TeX related FTBFS
Hi, On Tue, Dec 20, 2005 at 01:48:12PM +0100, Frank Küster wrote: > Osamu Aoki <[EMAIL PROTECTED]> wrote: ... > > I think one to ease tension is to make tetex packages to coexist in > > archive just like many gcc. > > That would be nice - but it would cause even more work, I fear. And it > would be the cause of even more bugs, because you can't just simply use > one symlink pointing to the right place, but need to maintain a complete > tree of TeX input and configuration files, in a setup where users can > mix up trees with one changed line in the central configfile... I should have been clear. I wish them to coexist only in "archive" but they can conflict each other to make only one of them to be installed. Maybe, dummy package to go with them is also nice. I know it is too much work to make them installable simultaneously. Maintaining 2 version are still a lot of work, though. As for auto-building some sections of archive in sid environment but overriding some packages with ones from experiment or local archive, I think pbuilder should be useful. (I will try it some time soonish. It should be quite simple.) Osamu
Re: switching to vim-tiny for standard vi? -> which editor should be standard?
Hi, Since I have not seem posting from Miquel... For this discussion of "Which editor should be installed as default on` the each Debian system?", I think more technical discussion should be done. This is old topic. We can always install nano, nvi or vim-* later as you wish by "sudo aptitude install " :-) (Disclaimer: I use vim exclusively.) > From: Stefano Zacchiroli <[EMAIL PROTECTED]> > Hi Joey, vim-tiny is available in debian/unstable. There are still some > minor bugs, but the package is fine. The installed-size of it and of > vim-common are as I anticipated (776 + 232 on i386); the only additional > dependencies are libc6 and libncurses5. Well is this small? By the way, we should also check nano too. Let me review some status of small editors. (Listed by the size) Package: elvis-tiny Priority: optional Installed-Size: 148 Maintainer: Miquel van Smoornburg <[EMAIL PROTECTED]> Version: 1.4-20 Pre-Depends: libc6 (>= 2.3.2.ds1-21), libncurses5 (>= 5.4-1) Size: 46090 Package: nano-tiny Priority: optional Installed-Size: 220 Source: nano Version: 1.3.9-1 Depends: libc6 (>= 2.3.5-1), libslang2 (>= 2.0.1-1) Size: 138512 Package: nvi Priority: important Installed-Size: 632 Version: 1.79-22 Depends: libc6 (>= 2.3.2.ds1-4), libncurses5 (>= 5.4-1) Size: 288166 Package: vim-tiny Priority: optional Installed-Size: 776 Version: 1:6.4-006+1 Depends: vim-common (= 1:6.4-006+1), libc6 (>= 2.3.5-1), libncurses5 (>= 5.4-5) Size: 377374 Package: vim-common Priority: optional Section: editors Installed-Size: 228 Version: 1:6.4-006+1 Recommends: vim | vim-tiny Size: 80504 --> This means vim-tiny, it took Installed-Size: 1004 and Size: 457878 Package: nano Priority: important Installed-Size: 1380 Version: 1.3.9-1 Depends: libc6 (>= 2.3.5-1), libncursesw5 (>= 5.4-5) Size: 461694 So aside from vim-tiny, what we have in sid priority important, nvi and nano, are not smallest editors for the job. From technical point, we should chose elvis-tiny and nano-tiny. Both of these editor have commands in /bin which is always with us. (What happens if you have NFS mounted /usr ?) In terms of updating editors which is installed as the default rescue system, we should chose small ones: nano-tiny and elvis-tiny. (elvis-tiny is another vi-clone.). Sarge installer installs nano and nvi. I thought it was sort of overlooked bug of installer. nano and nvi are in /usr/bin. Cheers, Osamu signature.asc Description: Digital signature
Priority=important: elvis-tiny & nano-tiny / Priority=optional: nvi, vim-tiny, nano, elvis, vim
On Sat, Dec 24, 2005 at 02:13:25PM +0100, Frans Pop wrote: > On Saturday 24 December 2005 14:15, Osamu Aoki wrote: > > Sarge installer installs nano and nvi. I thought it was sort of > > overlooked bug of installer. nano and nvi are in /usr/bin. > > s/installer/debootstrap/ Yes, thast is more precise. > And debootstrap just installs the base system based on package > characteristics (mainly priority), so it all boils down again to the > definition of the base system. For things like editor, we can istill review priority based on the size and technical merits. This should lead us to make elvis-tiny and nano-tiny important while others should stay as optional. We also have ed as important and cat is always with us. (None of the editor need to be required either. So removing them are also easy.) We have system with mawk (Priority=required) but usually no gawk (Priority=optional) nor original-awk(Priority=optional) installed. Out of these awk variants, original-awk seems to be the smallest. Changing this priority on awk just by size is something I do not want to see. But we can still do that with editor. So instead of adding more editor to our base by boosting packasge"s priority, we should have priority set to optional for most editors exept nano-tiny and elvis-tiny. (c)debootstrap should only install these 2 editors except talled otherwise. That is my observation. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITK: debmake
On Thu, Dec 29, 2005 at 07:13:05PM +0100, Santiago Vila wrote: > There are less than 80 packages in unstable still using it, and there > is an excellent package called debhelper which can do everything that > debmake does and probably much better, so it does not make much sense > to keep debmake alive forever. ... > *) If you maintain documentation from the DDP, you are welcome to > remove any documentation or howto explaining how to use debmake to > create a debian package. This includes translations. As I see in debian-reference: --- A.3.2 debmake debmake, a precursor to debhelper, is a more coarse-grained debian/rules assistant. It includes two main programs: deb-make, which can be used to help a maintainer convert a regular (non-Debian) source archive into a Debian source package; and debstd, which incorporates in one big shot the same sort of automated functions that one finds in debhelper. The consensus is that debmake is now deprecated in favor of debhelper. However, it's not a bug to use debmake. --- I should remove last sentence from all translations. As I see maint-guide (New Maintainers"s guide): --- Note: debmake is a package that contains some programs that function similar to dh-make, but its specific use is not covered in this document, because it is deprecated. Please refer to the Debmake manual for more information. --- I see no problem with this. Does anyone find any other issues? Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
developers-reference update for ITK: debmake
On Sat, Dec 31, 2005 at 06:22:20PM +, Roger Leigh wrote: > Osamu Aoki <[EMAIL PROTECTED]> writes: > > > As I see in debian-reference: Of course, it is developers-reference :-) > > --- > > A.3.2 debmake > > > > debmake, a precursor to debhelper, is a more coarse-grained debian/rules > > assistant. It includes two main programs: deb-make, which can be used to > > help a maintainer convert a regular (non-Debian) source archive into a > > Debian source package; and debstd, which incorporates in one big shot > > the same sort of automated functions that one finds in debhelper. > > > > The consensus is that debmake is now deprecated in favor of debhelper. > > However, it's not a bug to use debmake. > > --- > > I should remove last sentence from all translations. > > It might be better changing it to "It is a bug to use debmake in new > packages. New packages using debmake will be rejected from the > archive." CVS has been updated for English and Japanese. French still needs work but I can not do that. Merci. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITK: debmake
On Sun, Jan 01, 2006 at 02:50:36PM +0100, Adrian von Bidder wrote: > On Saturday 31 December 2005 18.48, Osamu Aoki wrote: > [debmake] > > > As I see in debian-reference: This should have been developers-reference :-) > > --- > > A.3.2 debmake > > > [...] > > However, it's not a bug to use debmake. > > --- > > I should remove last sentence from all translations. > > Or just drop mention of debmake alltogether? The description of the debmake > package already says it's deprecated and only needs a s/might/will/ in the > last paragraph for the next upload. Until debmake is really gone, maybe dropping is premature. It has been modified per Roger Leigh's comment. > > As I see maint-guide (New Maintainers"s guide): > > --- > > Note: debmake is a package that contains some programs that function > > similar to dh-make, but its specific use is not covered in this > > document, because it is deprecated. Please refer to the Debmake manual > > for more information. > > Same here - drop mention alltogether? For this being entry document, dropping or simply mentioning not to use may be good idea. If I hear others pushing along this, I will do so. But for now, current statement is in line with what it is and what will happen. Once debmake is really gone from archive, please file wishlist bug. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X
Package: wnpp Severity: wishlist Owner: Osamu Aoki <[EMAIL PROTECTED]> Package name: gsynaptics Version : 0.9.5 Upstream Author : Hiroyuki Ikezoe <[EMAIL PROTECTED]>, Takuro Ashie <[EMAIL PROTECTED]>, Ikuya Awashiro <[EMAIL PROTECTED]> URL : https://sourceforge.jp/projects/gsynaptics/ License : GPL Description : configuration tool for Synaptics touchpad driver of X GSynaptics is a configuration tool for Synaptics touchpad driver of X server. Before you use this package, please read /usr/share/doc/gsynaptics/README and configure X server properly. -- If you are using gnome, this should give you nice alternative to qsynaptics :-) As a matter of fact, it has been locally packaged based on the packaging by Ikuya for Ubunts. Minor dependency fix was neded to build on Debian. I also changed build script to use autotoools-dev. If Ikuya wants to maintain this on Debian, I will be happy to sponsor. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X
Hi, On Sat, Feb 11, 2006 at 07:34:22AM +0200, Lars Wirzenius wrote: > "Properly" is a bad word to use in this context, since the configuration > in question seems to result in a potential security problem. From the > xfree86-driver-synaptics README.Debian file: ... Good point. Here is revised control file: Description: configuration tool for Synaptics touchpad driver of X server GSynaptics is a configuration tool for Synaptics touchpad driver of X server. This enables you to modify driver parameters on the fly through GUI interface using "synclient" program as its backend. . SECURITY NOTE! This program requires you to enable the "SHMConfig" option in the X configuration file. This is *not* *secure* if you are in an untrusted multiuser environment. For typical laptop PC environment with only one user account where this package is most likely to be used, risks involved can be acceptable level. . Please read /usr/share/doc/gsynaptics/README. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X
Hi,
On Sat, Feb 11, 2006 at 10:50:19AM +0100, Christian Perrier wrote:
> > Description: configuration tool for Synaptics touchpad driver of X server
> > GSynaptics is a configuration tool for Synaptics touchpad driver
> > of X server. This enables you to modify driver parameters on the fly
> > through GUI interface using "synclient" program as its backend.
> > .
> > SECURITY NOTE! This program requires you to enable the "SHMConfig"
> > option in the X configuration file. This is *not* *secure* if you
> > are in an untrusted multiuser environment. For typical laptop PC
> > environment with only one user account where this package is most
> > likely to be used, risks involved can be acceptable level.
> > .
> > Please read /usr/share/doc/gsynaptics/README.
>
>
> I usually don't criticize the package descriptions but I'm not sure
> that such information actually pertains to the package description. It
> should rather go in README.Debian
Anyway, as installed, it does not change configuration --> Safe default
User will do so when reading README file.
> I would also advise against the use of exclamation marks and
> *pseudo-bold text*. Package descriptions os a place where neutral
> language should be used: facts, only facts and not opinions.
I guess just removing 2nd paragraph on will do the job. I will add
README.Debian.
> Addressing the users ("you") in package descriptions is also something
> I would discourage.
Noted.
Now, my control contains following only:
-
GSynaptics is a configuration tool for Synaptics touchpad driver
of X server. This enables you to modify driver parameters on the fly
through GUI interface using "synclient" program as its backend.
--
I inserted security note to README file provided by the upstream
so people will not miss it when seting "SHMConfig" to "on".
Osamu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X
I had a second thought so I need your help again. On Sat, Feb 11, 2006 at 02:29:10PM +0100, Christian Perrier wrote: > > Now, my control contains following only: > > - > > GSynaptics is a configuration tool for Synaptics touchpad driver > > of X server. This enables you to modify driver parameters on the fly > > through GUI interface using "synclient" program as its backend. > > -- > > Let's nitpick a little: Yes :-) > GSynaptics is a configuration tool for the Synaptics touchpad driver > of the X server. This allow for modifications of the driver s/allow/allows/ ? > parameters on the fly through a GUI interface by using > the "synclient" program as backend. What do you think about this alternative description: GSynaptics is a GUI configuration tool for the Synaptics touchpad driver of the X server. This allows for modifications of the driver parameters on the fly by using the "synclient" program as its backend. I will plug in the best one and upload package soonish :-) Osamu
Re: Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X
Oops. I think I was careless. On Sat, Feb 11, 2006 at 11:18:04PM +0900, Osamu Aoki wrote: > I had a second thought so I need your help again. > > GSynaptics is a configuration tool for the Synaptics touchpad driver > > of the X server. This allow for modifications of the driver > s/allow/allows/ ? > > parameters on the fly through a GUI interface by using > > the "synclient" program as backend. It looks like "synclient" is not always used. > > What do you think about this alternative description: > Maybe I should be safe to say: GSynaptics is a GUI configuration tool for the Synaptics touchpad driver of the X server. This allows for modifications of the driver parameters on the fly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X
Hi, On Sat, Feb 11, 2006 at 05:15:17PM +0100, Mattia Dongili wrote: > On Sat, Feb 11, 2006 at 11:38:03PM +0900, Osamu Aoki wrote: > > Oops. I think I was careless. ... > > It looks like "synclient" is not always used. > > Be really careful then! We have to synchronize uploads when the shared > memory segment layout of the driver changes. Hey, I hope I was not too careless :-) > I guess from the upstream. > Oh, wait. Gsynaptics already includes a different (much older) version > of struct SynapticsSHM. It won't work with the current synaptics driver > available in etch. Yep. > I tested 0.9.5 here that destroyed my runtime configuration :) > Probably taking synaptics.h from the driver sources and stripping the > unnecessary definitions (the non public part, see comments) is enough. Well, adjusting such differences are part of maintainership, I guess. I hope I did a useful job. gsynaptics (0.9.5-1) unstable; urgency=low * Initial package for Debian based on the work of Ikuya Awashiro <[EMAIL PROTECTED]> for Ubuntu with minor changes such as removing unused dpatch dependency. (closes: Bug#352303) * Update shared memory structure to match Debian xfree86-driver-synaptics-0.14.4-1 . -- Osamu Aoki <[EMAIL PROTECTED]> Fri, 10 Feb 2006 23:50:33 +0900 > BTW: I'll soon upload a new revision recommending [gk]synaptics. Hey, that sounds very interesting. If you see your packages does better job under GTK library environment, let me know. I will be happy to give way to your gsynaptics to avoid name space conflict. Keep me updated. Osamu PS: I am slow in responding to e-mail these days. Give me at least 10 days before getting annoyed. Oh, please make sure to respond to the BTS. Then I can easily check it from the web. Gmail spam filter is sometimes too aggressive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X
Hi, On Sun, Feb 12, 2006 at 06:03:07PM +0100, Mattia Dongili wrote: > On Sun, Feb 12, 2006 at 11:59:42PM +0900, Osamu Aoki wrote: > > Hi, > > ... > > > I tested 0.9.5 here that destroyed my runtime configuration :) > > > Probably taking synaptics.h from the driver sources and stripping the > > > unnecessary definitions (the non public part, see comments) is enough. > > > > Well, adjusting such differences are part of maintainership, I guess. > > Well, I'd expect upstream did that since 0.14.4 has been released > quite a while ago (Nov. 05) and gsynaptics' synshm.h is only compatible > only with 0.14.0 and 0.14.1. So maybe he is interested in such a change. > AFAICT upstream gsynaptics-0.9.5 is not compatible with ubuntu's > synaptics driver neither. Well, what I gathered from blog etc. writen in Japanese, original upstream (ikezoe) wrote it but gave to Mr. Ashie(makeinu) who seems to be quite active on OSS software thingy and make living with it. Packaging was done by another person (ikuya) who is pretty good at making package but lacks some attention to FTBFS issues. I guess this gsynaptics is somewhat stalled project which needs good contributor. > > I hope I did a useful job. > > > > gsynaptics (0.9.5-1) unstable; urgency=low > > > > * Initial package for Debian based on the work of Ikuya Awashiro > > <[EMAIL PROTECTED]> for Ubuntu with minor changes > > such as removing unused dpatch dependency. (closes: Bug#352303) > > * Update shared memory structure to match Debian > > xfree86-driver-synaptics-0.14.4-1 . > > > > -- Osamu Aoki <[EMAIL PROTECTED]> Fri, 10 Feb 2006 23:50:33 +0900 > > > > > BTW: I'll soon upload a new revision recommending [gk]synaptics. I should have read what you wrote more carefully. > > Hey, that sounds very interesting. If you see your packages does better > > job under GTK library environment, let me know. I will be happy to give > > way to your gsynaptics to avoid name space conflict. Keep me updated. > > Oh, I don't maintain ksynaptics nor qsynaptics and they are kde things > so a gtk configuration tool is really welcome (I admit I don't use it > but Suggest-ing all the graphical configuration tools will hopefully > ease the user's life. My bad I didn't do it before). Well, I have to say this upstream is half dead. So, active contribution is quite welcomed. Osamu PS: Mr. Ashie, if you are reading this, let me know what you think. I can read Japanese too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types -- use common sense
Hi, I hate to see to much dogmatism around Debian. We need to use common sense. Let's not use policy as the only guiding principle. On Fri, Feb 17, 2006 at 07:34:14AM +0200, Lars Wirzenius wrote: > pe, 2006-02-17 kello 01:10 +0100, Javier Fernández-Sanguino Peña > kirjoitti: > > Docbook/XML or SGML conversion to HTML is easy. Proper PS / PDF > > generation is not that easy (depends on toolchain and local > > configuration) and that's what your average user typically asks for > > when handling large documents (manny prefer printing bulky documents > > than reading them offline or online). I think that, when policy was written, it was aiming mostly typical HOWTO documents. The HTML was preferred over plain text or groff since there were good deal of reader programs for different situation. Screen / console width adjustment was the real advantage. > As a hypothesis, I propose that many people prefer to print PS/PDF files > rather than reading them from the screen because PS/PDF tend to be > unpleasant to read from the screen. It doesn't, for example, reformat > itself to the display/window/font size combination. HTML does that > better. Yes. Adjusting paper size/ font size is generation time parameters for PS/PDF. You can still expand page to larger page or print multiple page in a paper with few tricks for PS/PDF :-) > Anyway, I'm not opposed to providing a PDF version in a package, but I > really, really hope we're not going to switch away from HTML as the > primary format. I fully agree with you here. For most descriptive less than few page documents, I do not think it is worth bothering to create PDF/PS files unless you have fancy mathematical formula etc. in it. Considering headache of tool chain related FTBFS issues, I say it is not worth generating PS/PDF files./ I can say this loud since I do create them and know it quite well by experience. Of course, if anyone provide length manual, I think it is nice to have them in A4/letter compatible printable format. Osamu
Re: ./configure in debian/rules
On Fri, Feb 24, 2006 at 04:30:14PM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 24 Feb 2006, Frank Küster wrote: > > Per Olofsson <[EMAIL PROTECTED]> wrote: > > > Frank Küster: > > >> Were can I read up on how and why I should do this? > > > > > > /usr/share/doc/autotools-dev/README.Debian.gz > > > > Thanks - but I think this should be documented at a more visible place. > > If it's not the policy, developer's reference. > > Policy has nothing to do with it. The developer's reference already tells > you about that in appendix A.6.2. Also, as a part of recent maintenance update, the current "Debian New Maintainers' Guide" has following pointer at the start of "Chapter 3 - Modifying the source": Please make sure to read /usr/share/doc/autotools-dev/README.Debian.gz before proceeding. So you can not miss this information thesedays. Thanks hmh providing fine documentation. Osamu
Re: library packaging doc...
On Fri, Jan 28, 2005 at 11:05:14PM +0100, Javier Fernández-Sanguino Peña wrote: > On Fri, Jan 28, 2005 at 11:03:23PM +0900, Junichi Uekawa wrote: > > 3. can I get commit-access to CVS? Please get it. Having DOC in CVS makes easier for proofreader to correct things. For me, I initially got patches. But after a while, I developed mutual trust with few people. They start fixing it with write access sometimes later. But they always ask significant changes to me. It was nice way to get my English fixed. > Sure, any DD can get that access check out > http://www.debian.org/doc/cvs Not any more. (I think) After compromise of debian server, we are limitting access to DDP to the member of debian-doc or some group like that for DD. Just request to [EMAIL PROTECTED] while pointing them our message on this list. Unfortunately, I do not have access to gluck now. I do not know why, but it does not connect now. Osamu PS: If you are in rush, I or javi should be able to add you as a pserver access user just like other non-DD. We need to check out CVSROOT/passwd file or so, I think. I have not done it.
Re: Policy for devfs support
On Sat, Mar 26, 2005 at 07:24:05PM +0100, Marco d'Itri wrote: > On Mar 26, Roger Leigh <[EMAIL PROTECTED]> wrote: > > > Is there a project-wide policy for support for devfs (and devfs-style, > > e.g. udev devfs.rules) device naming? > No, but nearly all packages support both conventions. Nearly all... I know an exception: tpconfig 3.1.3-5configure touchpad devices Very quiet upstream and 18 month old binary package in testing :-) Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Warning: Some CVS repos are broken (was Re: gluck available again / filesystem shaked)
Hi, Thanks all for the work. This info may help you to fix CVS issues.
On Thu, Apr 07, 2005 at 07:47:17PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Thu, Apr 07, 2005 at 07:06:23PM +0200, Martin Schulze wrote:
>
> [ ... lots of stuff ... ]
>
> Thanks Joey for your dedication, it has become somewhat of a tradition that
> some Debian server breaks before the release (does it mean we are releasing
> this weekend?) :-)
>
> > The following CVS repositories are currently hosted on gluck:
> >
> > /cvs/webwml restored from backup
> (...)
> > /cvs/debian-doc restored from backup
>
> Unfortunately, it seems that at least that CVS repository is not properly
> restored from backup. There seem to be some files which are raw data and
> not proper RCS files so you get something like:
>
> cvs [update aborted]: EOF in value in RCS file
> /home/org/cvs.debian.org/cvs/webwml/webwml/english/debian.css,v
>
> when trying to do CVS operations :-(
>
> Maybe it's worth reviewing the output of running the following command:
>
> # find . -type f -exec file {} \; |grep ": data" | \
> egrep -v '\.(gz|gif|jpg|png|jpeg|pdf|tgz)'
>
> in the CVS repos.
>
> Joey, where are the backups of the CVS repos currently?
Here is info on situation of DDP CVS:
$ cvs up
| cvs server: Updating .
| cvs server: Updating articles
| cvs server: Updating articles/counting-potatoes
| cvs server: Updating articles/debian-international
| cvs server: Updating articles/debian-presentation
| cvs server: Updating articles/package-interfaces
| cvs server: Updating manuals.sgml
| cvs server: Updating manuals.sgml/apt-howto
| P manuals.sgml/apt-howto/ChangeLog
| P manuals.sgml/apt-howto/Makefile
| P manuals.sgml/apt-howto/apt-howto.de.sgml
| P manuals.sgml/apt-howto/apt-howto.el.sgml
| P manuals.sgml/apt-howto/apt-howto.en.sgml
| cvs update: checksum failure after patch to
manuals.sgml/apt-howto/apt-howto.en.sgml; will refetch
| P manuals.sgml/apt-howto/apt-howto.es.sgml
| cvs update: checksum failure after patch to
manuals.sgml/apt-howto/apt-howto.es.sgml; will refetch
| P manuals.sgml/apt-howto/apt-howto.it.sgml
| cvs [server aborted]: unexpected '\xffab' reading revision number in RCS
file /cvs/debian-doc/ddp/manuals.sgml/apt-howto/apt-howto.ja.sgml,v
| cvs client: refetching unpatchable files
| U manuals.sgml/apt-howto/apt-howto.en.sgml
| U manuals.sgml/apt-howto/apt-howto.es.sgml
It seems there is problem with RCS file of
/cvs/debian-doc/ddp/manuals.sgml/apt-howto/apt-howto.ja.sgml
Please note this original file apt-howto.ja.sgml uses ja_JP.eucJP
encoding. Editing file under UTF-8 locale editor will destroy file
contents. You need to use dumb 8 bit clean editor like mcedit (from mc)
preferably under C locale.
Osamu
new host key?: Re: compromise of gluck.debian.org, lock down of other debian.org machines
Hi, Are you sure it is Debian gluck issue? I can connect with SSH to it now with minor problem. On Sun, Jul 30, 2006 at 11:28:36AM +1000, Brian May wrote: ... > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Host 'gluck.debian.org' is known and matches the RSA host key. > debug1: Found key in /home/bam/.ssh/known_hosts:219 > debug1: ssh_rsa_verify: signature correct It looks like gluck's new SSH uses new host identification. I got following message when I connected with ssh -v ... @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! After removing old entries from ~/.ssh/known_hosts, I can update host key and login. Good luck. Osamu PS: It would have been nicer if old hosk identification was backuped and used in new system. signature.asc Description: Digital signature
Re: Bug#381568: ITP: med-fichier -- Library to exchange meshed data
Hi, On Tue, Aug 08, 2006 at 06:36:54AM +0900, Miles Bader wrote: > Andreas Tille <[EMAIL PROTECTED]> writes: > > but some kind of strange feeling continues if I hear this name (and > > the translation of it). It's just misleading. > > Er, just because you have a "strange feeling" doesn't mean the name is > misleading. > > "Med" is pretty ambiguous. _I_ certainly don't have any immediate > reaction that it contains "medical software," and I don't think it's a > generally used abbreviation for medical in the wider population -- Not that I live in USA... In USA, when an university student says "pre-med" , that kids is trying to go to medical school. It is certainly recognised as one short form for medical. But quick look up in google gives you "med" will lead you to things not only for www.med.stanford.edu but club med (resort club name: "med" implicitly means Mediterranean) . So it can be many other thigss too. (But you find mostly medical related words there) 3 letter acronyms tend to crash each other so much. Considering this being somewhat specialised purpose, I should say avoiding name crash was prudent thing to do. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
License question: Re: Bug#389598: ITP: xpbiff
Hi, On Tue, Sep 26, 2006 at 09:22:35PM +0200, Frank Küster wrote: > James Vega <[EMAIL PROTECTED]> wrote: > > > On Tue, Sep 26, 2006 at 07:29:05PM +0200, Gernot Salzer wrote: > >> Copyright: > >> > >> * xpbiff - popup biff for X > >> * > >> * Author: Kazuhiko Shutoh, 1993 > >> * > >> * Permission to use, copy, modify and distribute without charge this > >> software, > > > > Doesn't the 'without charge' bit violate DFSG #1? It is confusing for sure. But the intent of the author was probably to be a shorter funny version of MIT license. > If it is meant as it is written, yes. Often sentences like this can > also be read as "Permission, without charge, to use, copy, ...". But in > this particular case the "without charge" seems to be quite clearly > associated with "distribute". Let's ask the author nicely. It is a xbiff derivative. I think authour will be very likely to agree original MIT X license terms. Only his Imakefile and xpbiff.c seems to suffer this. Other sources in the tar-ball uses standard MIT X license. To be nice to him, I write following in Japanese. はじめまして。 DebianのMLのフォローです。 xpbiffですがImakefileとxpbiff.cのライセンスの文章が誤解を招いているのでは と心配しています。MITライセンスの文章を短くしちょっと冗談を入れられるのが 真意だと思うのですが。。。いかがでしょうか。 * Permission to use, copy, modify, and distribute this software and its * documentation for any purpose and without fee is hereby granted, provided * that the above copyright notice appear in all copies and that both that * copyright notice and this permission notice appear in supporting * documentation. Kazuhiko Shutoh makes no representations about the * suitability of this software for any purpose. It is provided "as is" * without express or implied warranty. The author assumes no * responsibility for lost sleep as a consequence of use of this software. このような標準的MITライセンスの文章でライセンスされているつもりだという 確認のメールを返答いただけないでしょうか？ 現状のまま文字どおり読むと、無償配布以外ではまったく配布できないので デビアンではXBIFF同様のDEBIANのMAINでの配布ができなくなりますのでお願 い致しました。 (デビアンは http://www.debian.org です。） お手数ですがよろしくお願いいたします。（できれば英語でYESと返答お願いします。） 青木
Re: xv and xorg
On Fri, Oct 06, 2006 at 08:18:32PM -0700, Marc Wilson wrote: > On Fri, Oct 06, 2006 at 05:37:10AM -0500, Ron Johnson wrote: > > Would you mind sharing the -39 or deb-src with us? > > xv isn't distributable by me as I'm not the copyright holder. Whoever > controls where the original -26 source lives may not be OK either, but > that's not for me to say. I do not care too much about xv but... You can still distributr diff.gz with instruction text to use xv upstrean tar ball. Noone can stop you. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making SELinux standard for etch
On Fri, Oct 06, 2006 at 07:33:40PM -0500, Manoj Srivastava wrote: > On Sat, 7 Oct 2006 01:04:50 +0200, Marco d'Itri <[EMAIL PROTECTED]> said: > > > On Oct 07, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > >> The size of the .debs for targeted policy is 2185702 Bytes, and > >> adds seven packages to the standard install. No special > > While I like much the idea of having solid and easy to deploy > > selinux-related packages, I object to installing them by default > > since they will still be disabled by default and realistically most > > people will not use them. > > Realistically, most people do not use vacation, finger, and > sharutils either. Are we talking about disk usage? I am not sure > that the increase in disk usage is perceptible on a normal install on > modern (read: made in this millennium) machines. > > People on low disk situations can always delete them -- none > of these packages is remotely essential, just remove the policy > package and everything goes. I like SELinux as a part of default install. But please make sure to use recommend or so as dependency. This should enable people to remove packages if they chose not to deploy SELinux. So people can still use packages without too much changes if they customize base install. Is there any SELInux for dummies HOWTOs for Debian? I do not need full SELInux knowledges but I hope to use some easy to use features for extra safety. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?
On Fri, Oct 13, 2006 at 12:45:09PM +0200, Marc Haber wrote: > On Tue, 10 Oct 2006 19:30:52 -0700, Don Armstrong <[EMAIL PROTECTED]> > wrote: > >So have a note in exim4's debconf which tells the users that, and only > >display the note if DEBCONF_RECONFIGURE=1 or $1='reconfigure'. > > That is what I did for the exim4 package uploaded on Tuesday. So far, that works nicely :-) I think we need to start advatizing configure-debian instead of dpkg-configure for user friendly but still low level configuration interface. There, it is obvious exim* has many packages. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397917: gsynaptics - lists s390 as supported
On Fri, Nov 10, 2006 at 02:00:32PM +0100, Bastian Blank wrote: > Package: gsynaptics > Version: 0.9.7-1 > Severity: serious > > gsynaptics lists s390 as supported (Architecture: any) but > xserver-xorg-input-synaptics is not available. This leads to > uninstallable binary packages. I see. But xserver-xorg-input-synaptics has Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc This looks agry. Because I need to track new architectures. Can I do Architecture: !s390 Anyone have suggestion? Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397917: gsynaptics - lists s390 as supported
Hi, On Fri, Nov 10, 2006 at 03:04:54PM -0800, Steve Langasek wrote: > On Fri, Nov 10, 2006 at 11:17:57PM +0900, Osamu Aoki wrote: > > On Fri, Nov 10, 2006 at 02:00:32PM +0100, Bastian Blank wrote: > > > Package: gsynaptics > > > Version: 0.9.7-1 > > > Severity: serious > > > > gsynaptics lists s390 as supported (Architecture: any) but > > > xserver-xorg-input-synaptics is not available. This leads to > > > uninstallable binary packages. > > > I see. But xserver-xorg-input-synaptics has > > > Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc > > > This looks agry. Because I need to track new architectures. > > > Can I do > > > Architecture: !s390 > > No, this syntax is not supported. OK. > > Anyone have suggestion? > > One possibility is to list the package as Architecture: any, but construct > your debian/rules file such that the package fails to build if the > architecture is s390. That may be a good solution if I did not have package in testing including s390. But it is there. It will waste of autobuilder time and current package stays in testing and unstable for s390. Since my packages for all arches are already in testing, the newly build packages will stay in unstable and old packages stay in testing due to version difference. So no real gain just doing this. As I see now, I have few options. What is right? Option 1) * Change BTS "#397917: gsynaptics - lists s390 as supported" to "normal" * Reassign #397917 to xserver-xorg-input-synaptics * Ask xserver-xorg-input-synaptics to be rebuild as Architecture: any . I know it is unlikely to hook synaptics device to s390 but then who will ever bother to set up xserver to start with. I understand that it is likely to have s390 run X client softwares on it and some X server to be connected to it for display. I see X server on s390 so I see no reason not to build xserver-xorg-input-synaptics. There is also "Hercules" emulator. It may support funny hardware extension in future too. Option 2) * Change BTS "#397917: gsynaptics - lists s390 as supported" to "normal" * Lazily sit tight. This removes RC bug but really leaves my package uninstallable in s390. xserver-xorg-input-synaptics can do what ever he wants. Option 3) * Set "Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc" * Ask ftp-master for removal of package for s390 * Make entry in quinn-diff not to build on s390 This is a lot of CPU time and work for no real gain other than closing bug. Option 4) * Set "Architecture: any" * Have fancy script to fail in s390. * Ask ftp-master for removal of package for s390 * Make entry in quinn-diff not to build on s390 This is a lot of CPU time and work for no real gain other than closing bug. Osamu PS: Many device support packages are almost useless for non-PC/workstation like hardware. This goes with arm and mips too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397917: gsynaptics - lists s390 as supported
Hi, On Fri, Nov 10, 2006 at 05:59:07PM -0800, Steve Langasek wrote: ... > > Option 3) > > * Set "Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel > > powerpc sparc" > > * Ask ftp-master for removal of package for s390 > > * Make entry in quinn-diff not to build on s390 > > This is an acceptable solution, ... > > Option 4) > > * Set "Architecture: any" > > * Have fancy script to fail in s390. > > * Ask ftp-master for removal of package for s390 > > * Make entry in quinn-diff not to build on s390 > > This is an acceptable solution. I like the latter so I do not interfare with builoding kfreebsd-i386 etc. ... > > PS: Many device support packages are almost useless for > > non-PC/workstation like hardware. This goes with arm and mips too. > > No, you're missing the point. The S/390 port has *no hardware*; in the case > of other architectures, some user *may* hook a synaptics device up to their > computer, but on s390 this is not possible at all because of what s390 is. > Even if the S/390 VM was enhanced somehow to support hooks for this class of > physical hardware, the kernel has no support for it. Considering ease of implimentation, I will be likely to end up with Option 3. But for kfreebsd-i386 port etc., may be Option 4 is better. I did some search on how other packages which are likely to face similar issues by checking likely packages under laptop task and other random packages which seems to be hardware specific which came to my mind. (I did not check kernel support for acpi in the source for s390. cpufreq doc seems to suggest no support for s390) sourceArchitectures390-binary acpi i386 ia64 amd64 no acpi-support i386 ia64 amd64 no acpid i386 ia64 amd64 no hibernate all (no) hotkey-setup i386 amd64 no uswsusp i386 amd64 no xserver-xorg-input-synaptics itemized w/o s390 no toshset i386no toshutils i386no tpctl i386no thinkpad-base i386no thinkpad-source i386no motioneye i386no i810switchi386 kfreebsd-i386 no spicctrl i386no rsjog i386no sjog i386no But... sourceArchitectures390-binary apmd any yes cpufrequtils any yes pcmciautils any yes sensors-appletany yes tpconfig any yes wireless-toolsany yes wmbattery any yes H I have to do the same for tpconfig since it is also my package. But none of these with any packages uses Option 4 so I can not take easy example. (Maybe they deserve bug reports.) Do I use this line in buid script? if [ `dpkg-architecture -qDEB_BUILD_ARCH` = "s390" ]; then exit 1; fi Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages with problems wrt release
Hi, On Fri, Dec 15, 2006 at 11:31:03PM +0100, Lucas Nussbaum wrote: > Osamu Aoki <[EMAIL PROTECTED]> > maint-guide (U): has RC bugs (#403200) This is nanother package hit by cjk-latex change during etch testing. It is FTBFS, I agree in etch but fault is latex-cjk-* packages, I think. And issue for them is ay best "important" level issues. It is not RC. (Japanese issue is partly a problem caused by the dependency definition of cjk-latex package anyway.) I have fixed cosmetic issues of maint-guide in CVS (cvs.debian.org) but I need to wait latex to be fixed to build a package for chinese. Since current binary package is completely usable, I see no reason not to release it. Anyway, help to latex-cjk_* packages are most appreciated. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages with problems wrt release
On Sun, Dec 17, 2006 at 02:00:30AM +0900, Osamu Aoki wrote: > Hi, > > On Fri, Dec 15, 2006 at 11:31:03PM +0100, Lucas Nussbaum wrote: > > Osamu Aoki <[EMAIL PROTECTED]> > > maint-guide (U): has RC bugs (#403200) > > This is nanother package hit by cjk-latex change during etch testing. > > It is FTBFS, I agree in etch but fault is latex-cjk-* packages, I think. > And issue for them is ay best "important" level issues. It is not RC. > (Japanese issue is partly a problem caused by the dependency definition > of cjk-latex package anyway.) > > I have fixed cosmetic issues of maint-guide in CVS (cvs.debian.org) but > I need to wait latex to be fixed to build a package for chinese. > > Since current binary package is completely usable, I see no reason not > to release it. > Anyway, help to latex-cjk_* packages are most appreciated. Actually, we found a bug in debiandoc-sgml's recent change. So, we need new debiandoc-sgml and cosmetic fix update of rebuild maint-guide to close this situation. Osamu > Osamu > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use pbuilder, Luke... (extra archive source set up)
On Sun, May 14, 2006 at 11:08:09PM +1000, Hamish Moffatt wrote:
> On Sun, May 14, 2006 at 11:47:41AM +0200, Wouter Verhelst wrote:
...
> Without wishing to join the mob,
>
> e) it's difficult to install versions of packages not available from
> your regular sources.list. For example if you build a new (version of a)
> library package and then an application that uses it and want to upload
> both at the same time. You probably need to set up a local apt
> repository, which is a pain.
Once you do it, it is not too much work.
pbuilder set up for local package is easier if archive is http
accessible, then OTHERMITRRPOS in ~/.pbuilderrc can simply be set as:
# include my mirrors (No file://)
OTHERMIRROR="deb http://people.debian.org/~osamu/package/ ./"
# (Use your account name of course)
Then you upload to people.d.o with dupload with simple script. In my
case, "dupload -t osamu package.changes" with ~/.dupload.conf
# Developer account
$cfg{'osamu'} = {
fqdn => "people.debian.org",
method => "scpb",
incoming => "/home/osamu/public_html/package/",
# The dinstall on ftp-master sends emails itself
dinstall_runs => 1,
};
$cfg{'osamu'}{preupload}{'changes'} = "
echo 'mkdir -p public_html/package' | ssh people.debian.org
2>/dev/null ;
echo 'Package directory created!'";
$cfg{'osamu'}{postupload}{'changes'} = "
echo 'cd public_html/package ;
dpkg-scanpackages . /dev/null >Packages || true ;
dpkg-scansources . /dev/null >Sources || true ;
gzip -c Packages >Packages.gz ;
gzip -c Sources >Sources.gz ' | ssh people.debian.org 2>/dev/null ;
echo 'Package archive created!'";
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use pbuilder, Luke... (Was: cleaning up lib*-dev packages?)
On Sun, May 14, 2006 at 04:40:43PM +0200, Ondrej Sury wrote: ... > > e) it's difficult to install versions of packages not available from > > your regular sources.list. For example if you build a new (version of a) > > library package and then an application that uses it and want to upload > > both at the same time. You probably need to set up a local apt > > repository, which is a pain. > > Nope, it's not :-), just add: > > BINDMOUNTS="/var/cache/pbuilder/result" > > and put hook script somewhere: ... This is better than my approach. Just make sure /var/cache/pbuilder/result is writable by the user manually if you want to sign packages. (Currently root:root as installed) Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software Patents: Was: Re: Re: Is anyone packaging `lame' ?
I claim not being expert on this subject. But this argument seems rehash of ones done in debian-legal and debian-user. On Fri, Jun 02, 2006 at 05:23:51PM +0200, Cesare Leonardi wrote: ... > Remaining on the multimedia side, if mp3 is covered by numerous patents > that implementing a codec cannot be avoided > (http://www.mp3licensing.com/patents/index.html), then every free mp3 > codec has problems in country where the patents have legal value. And so > this should be a problem for the Debian project. And the same is true > for AAC, MP4 and so on. implimenting codec for "decoder" or "encoder", these are different things as I understood. Enforcement has been different. ... > Since now i haven't really understood what makes vlc, xine, gstreamer, > ffmpeg, ect. acceptable in Debian. Or, that is the same, what makes > mplayer, lame and similar, not acceptable in Debian. > For me this continue to be a mistery and an incoerency issue. > > Reading some discussion regarding the patent issue (expecially on the > multimedia side) and Debian, i have deduced that: > - if there are "doubtful" software already in Debian, they usually stay > in. Otherwise they do not enter. > - if something is covered by a patent that is not enforced by the > holder, it could enter or stay in Debian. That seems to be most important practice as I observed. Question on such patent and even obscinity issues are "Can Debian bear liabilities associated with inclusion of these packages and enjoy sufficient benefits?" Very practical rule, I think, seems to be at work. > > It is a matter destined to arise again and again until Debian will > adopt a clear and official (read written) position on that problem. > > Indeed a difficult decision because following the radical decision to > not accept software covered by patents, could render the Debian system > less pleasant and with more frustrated user (that eventually will prefer > to abandon Debian). Whereas accepting them will render Debian less free > software friendly. > > I am for the radical way, to keep Debian completely free, libre. > If necessary: www.debian-multimedia.org ;-) > And i'm writing this while listening an online radio through an mp3 > stream with vlc... *Sigh!* You can find some debian packages of such kind http://www.rarewares.org/index.html I have not tried this site much though. So YMMV. Osamu ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]> Yokohama Japan, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' "Our Priorities are Our Users and Free Software" --- Social Contract -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
Hi, On Tue, May 30, 2006 at 09:51:18PM +0200, Daniel Baumann wrote: > [ crosspost to live, -devel and -edu; replies please to -devel ] > > Hi all, > > at the moment, we have two types of Live CD images: > > * the small one which contains only packages of standard priority, > * and three larger ones, each of which contains one of the common > desktop-environments on it (gnome, kde, xfce). > > Now, we would like to create a decent package selection which reflects, > as well as possible, the users' desires. There should be one package > selection for a 700MB CD-ROM, and one for a 4.5GB DVD-ROM. With the > current squashfs compression, the actual filesystem size is about 3 > times bigger than the packed one. This means that there can be quite a > few packages on it :) I'm open for your suggestions... The practically essential packages are CJK-input method tools for people who want to use languages such as Chinese, Japanese, Korean,... (Possibly also for some people who want to switch between indic and other interesting languages) Without it, we can not type in text in our languages. "scim" tool chain or "uim" tool chain is most modern and they should work out of box, especially when used with "im-switch". gdm (maybe other dm too) has nice locale selection mechanism. I also hope you to use UTF-8 and have enough fonts to display all the weired languages like ours. Just my 2 cents. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
HI, On Sat, Jun 24, 2006 at 11:45:00AM +0200, Preben Randhol wrote: > Hi > > I have to my annoyance noticed that several of the doc packages > (especially development packages) contains files that are gzipped. That > is either example source files or pdfs etc... I understand your point and feeling. That is because of Debian policy and smart program called debhelper scripts helping packager to follow this policy. > My point is that if I choose to install a doc packages I intend to use > it frequently and would therefore like that it is user friendly rather > than that one has squeezed some few kilobytes out by gzipping files. If > I don't need the package anymore I can uninstall it to save the space. Yes. > When it comes to Changelog or other files that are included in all > packages (not only doc packages) it is fine that they are gzipped. I'm > only talking about the pure doc packages. Actually, the saving we get may be small here too. These days, harddisk is huge anyway. Waisting cpu time for gunzipping may be more waiste than harddisk space. But, we have fast CPUs so it is not too bad. Under gnome, fileroller will open it for you from filer. > Thanks in advance So it is non-issue for modern machine. We live with current rule. Real issue is saving space for compact systems. There we will have support in dpkg which can be told to drop installing in /usr/share/doc/* or something like it. Osamu -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]> Yokohama Japan, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' "Our Priorities are Our Users and Free Software" --- Social Contract -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
*-doc package should not gzip PDF file
Hi relax. As I said, I "understand ..". See below :) On Sat, Jun 24, 2006 at 06:48:26PM +0200, Preben Randhol wrote: > On Sat, 24 Jun 2006 05:52:26 +0900 > Osamu Aoki <[EMAIL PROTECTED]> wrote: > > > > But, we have fast CPUs so it is not too bad. Under gnome, fileroller > > will open it for you from filer. > > But I don't want to unzip a pdf to my home directory. This wasts space. > Last pdf I saw gzipped was only 6% smaller. If I have to gunzip it to > my local home directory I actually use 194 % more space than I needed > if the pdf wasn't gzipped. Neither do I want to unzip. > If the system has 10 people and everybody does this then please tell my > why gzipping the file saves space?!? > > > So it is non-issue for modern machine. We live with current rule. Maybe I should have said I live ... > No it is not. Because I (for one) want user friendliness. Why should I > waste my time gunzipping X files to get the info I need to do my job? > We talk about Linux being more efficient than say Windows, but if we > constantly have to jump over hurdles like this, everything slows > down > > > Real issue is saving space for compact systems. There we will have > > support in dpkg which can be told to drop installing > > in /usr/share/doc/* or something like it. > > If it is a compact system, then why on earth would you install doc > packages? It doesn't make sense. > > If one really really need to gzip, then make all applications in the > default Debian system able to handle gzipped files so there is no need > to unzip them to your local area and in fact use more space than > needed. The point is, if this mechanism is active, there is no point to gzip pdf/ps/txt file in /usr/share/doc/* in regular package either. > Best wishes > > Preben For architecture: all *-doc packages, there is no technical and practical reason to gzip *.pdf file. I agree. packages are gziped so package size d nt change. We do it just because of policy and bcause helper script is written such way as I said. If anyone wants this to be fixed following should happen. * Write a patch to the debhelper gzip text/pdf/ps file logic - do not compress if the package is *-doc and file extension is pdf. - possibly even avoid compressing if the result of compression gain less than **% (10% ?? or 1KB) of size. * propose policy update proposal. (debian-policy) Unless someone do the first work, nothing will change. It is non-issue for me now (so I will not do it) but I have no reason to object such an rational move. Please go ahead spend your good time :) Once I see technical solution, I will support policy change. Cheers, Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
On Sat, Jun 24, 2006 at 07:25:00PM -0400, James R. Van Zandt wrote: > > > > > 2. xpdf doesn't want to open gzipped pdfs by default which > > > > makes this a pain in the **tt for people who want to read the > > > > pdf. > > > > > > There's "zxpdf" in the xpdf package, analogous to zless and zcat it > > > views gzipped files. > > And some of us want to use evince or kpdf or gpdf. If you are in gnome, please install file roller. That will fix your immediate issue of opening *.pdf.gz file. > I don't think PDFs should ever be compressed with gzip. Well, aregument should be ... Gzipping PDF provides no real space saving advantage while forcing to use extra-CPU time and large temporary file space. * If space saving is the issue, just do not install -doc package. * Providing non-gzipped PDF speed-up system. As I posted elsewhere, someone has to provide debhelper patch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
Hi, On Sat, Jun 24, 2006 at 05:30:59PM +0200, Mario 'BitKoenig' Holbe wrote: > Preben Randhol <[EMAIL PROTECTED]> wrote: > > My point is that if I choose to install a doc packages I intend to use > > it frequently and would therefore like that it is user friendly rather > > than that one has squeezed some few kilobytes out by gzipping files. If > > Agreed. Particularly since the saving isn't sooo big at all. > On my - of course, not representative - workstation an uncompressed > doc/ tree takes only about a third more space (and this includes all > the ChangeLogs, READMEs etc. shipped with each package). > > [EMAIL PROTECTED]:~# du -sh /usr/share/doc > 839M/usr/share/doc > [EMAIL PROTECTED]:~# cp -ia /usr/share/doc /var/tmp > [EMAIL PROTECTED]:~# cd /var/tmp/doc > [EMAIL PROTECTED]:/var/tmp/doc# find . -type f -name \*.gz -print0 | xargs -0 > gzip -d > gzip: ./kernel-package/Rationale already exists;not overwritten > gzip: ./kernel-package/HOWTO-Linux-2.6-Woody already exists;not > overwritten > gzip: ./gcc-4.1-base/.changelog.Debian.gz has 1 other link -- unchanged > gzip: ./gcc-4.1-base/changelog.Debian.gz has 1 other link -- unchanged > [EMAIL PROTECTED]:/var/tmp/doc# du -sh . > 1,3G. > [EMAIL PROTECTED]:/var/tmp/doc# Interesting stat. Let me follow-up. On my system "du -sh ." returned: total/usr2.4G compressed /usr/share/doc 239M uncompressed /usr/share/doc 435M Although it looks like 40% saving in space, its overall impact is less than 10% shrink in size. Let me add popular big doc (tetex, gcc, harden) packages to my system and see what happens a bit more carefully. total/usr2.5G compressed /usr/share/doc 305M uncompressed pdf /usr/share/doc 322M ( 25.7% total as told by gzip -l) ( 50136586 Compressed <--- 67439000 Before) uncompressed all /usr/share/doc 515M Yes, space saving of compressing file size of PDF 25.7% only yield disk space saving of 17MB. Out of more than 2.5GB installation, this is zero gain. So PDF compress just yield no real impact to space but slow read time of doc packages. Wait, there is less than 70MB of PDF. Yes, this is true. Due to difficulties of making nice PDF out of XML/SGML without hitting FTBFS, many packages does not bother PDF creation. Most of the doc containing PDF are: Debian doc project CVS related doc packages build with debiandoc-sgml TeTex related documents (mostly in tetex-doc) Exceptions, I found, were under: shared-mime-info xen-doc dblatex hlatex fcitx tex-common texmf The thing is we do not put HTML doc files in tar.gz'ed archive to save size. That is the real space eater. Putting unreasonable restriction on PDF yield no real gain. As I see the fact above, at least PDF should not be required to be compressed externally with gzip. Since dh_compress does compression (except the copyright file, .html and .css files, and files that appear to be already compressed based on their extensions) per its manpage, why not treat PDF as "compressed" which I thought is the case. In this sense, we do not need policy change. Just minor change in code to realize what dh_compress claim to do. It is very slow to open over 1MB size PDF file even on a system with proper auto-ungzipping. So aside from pedantic policy argument, we should uncompress PDF. Osamu PS: I did not feel like using -X option now because debhelper default should be desired behaviour. But I may change my mind soon. Reference: [EMAIL PROTECTED]:/var/tmp2# find . -type f -name \*.pdf.gz -print0 | xargs -0 gzip -l compresseduncompressed ratio uncompressed_name 228023 510762 55.4% ./debian-policy/fhs/fhs-2.3.pdf 486418 682351 28.7% ./debian-policy/policy.pdf 318890 456439 30.1% ./debian/FAQ/debian-faq.en.pdf 124536 155443 19.9% ./shared-mime-info/shared-mime-info-spec.pdf 798976 1239893 35.6% ./Debian/reference/reference.en.pdf 692308 1063782 34.9% ./Debian/reference/reference.de.pdf 808949 1245798 35.1% ./Debian/reference/reference.es.pdf 781341 1202792 35.0% ./Debian/reference/reference.fr.pdf 828482 1274316 35.0% ./Debian/reference/reference.it.pdf 1784610 2567959 30.5% ./Debian/reference/reference.ja.pdf 901423 1340825 32.8% ./Debian/reference/reference.pl.pdf 833802 1273284 34.5% ./Debian/reference/reference.pt-br.pdf 2039169 2888341 29.4% ./Debian/reference/reference.zh-cn.pdf 2125677 3018941 29.6% ./Debian/reference/reference.zh-tw.pdf 224459 265209 15.4% ./texmf/tetex/TETEXDOC.pdf 150469 174936 14.0% ./tex-common/
Re: Why does doc packages need to contain gzipped files?
Hi, On Sun, Jun 25, 2006 at 11:05:54AM +0200, Martin Wuertele wrote: > * Eduard Bloch <[EMAIL PROTECTED]> [2006-06-25 10:18]: > > > * Martin Wuertele [Sun, Jun 25 2006, 08:09:57AM]: > > > > > file-roller does view pdf.gz and if e.g. firefox handels them incorrect > > > it should be fixed in there. We don't change policy when programs are > > > broken, we fix them. > > > > What shitty kind of reasoing is that? "If it does not use my extra stuff > > then it is incorrect?" "If Debian does not use RedHat Kickstart then it > > is broken?" > > Do you have some arguements beside the rant? See my other post. > firefox definitely should > handle .txt.gz and other gzipped plaintext documentation. I'm not > talking about pdfs, as in the thread back then I still prefere to use > the built-in compression available for pdfs. Agree here on "the built-in compression available for pdfs". Is there any external tool to convert PDF with better internal compression? I want to see ome PDF make file to use it to improve their PDF. Some PDF can still be compressed 50%, as I posted, which is bad. > > > > then I do not understand why it is done. > > > > > > See other mails in this thread, ther are good reasons to keep doc > > > packages compressed, e.g. half a gig of space saving. > > > > This extrapolation does hardly describe the real situation. Who install > > all -doc packages available in Debian and does not use them? > > That number was from a typical installation. I don't think pdfs should > be gzipped but the built-in compression should be used. However not > compressing anything is a real unnecessary waste of space. > > On my portable I have ~4.6K gzipped files in /usr/share/doc and only 39 > of them are pdfs, 4 are html files. > > I just copied the whole /user/share/doc (169M) to another lvm and > uncompressed everything in there - a typical installation - and > uncompressed all the gzipped files. That results in a total of 323M > nearly doubling the required space. But it is a tiny difference considering your /usr may be as big as 2GB. > I favour keepin plaintext documentation gzipped therefore. I understand your point here. We should not rush this nor unzipping should be default even in the future for changelog etc. Step should be: 1. No more *.pdf.gz file. (That is now) 2. Wait for smart dpkg which can do smart thing upon unpacking. (Such as dropping /usr/share/doc, /usr/share/info/,...) 3. Ask for unzip option by user preference for text/man/info pages in usr/share/*/ by dpkg later as wishlist. (Disk will be much cheaper then.) This will give you faster man/info/... if it is CPU bound. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *-doc package should not gzip PDF file
On Sun, Jun 25, 2006 at 08:30:34AM +0200, Preben Randhol wrote: > On Sat, 24 Jun 2006 20:35:53 +0900 > Osamu Aoki <[EMAIL PROTECTED]> wrote: ... > > * propose policy update proposal. (debian-policy) > > Ok, I'll bring it up here. > > > Unless someone do the first work, nothing will change. It is > > non-issue for me now (so I will not do it) but I have no reason to > > object such an rational move. > > I have no idea how debhelper works. Are there anybody out there that > can help with getting it to stop gzipping files in -doc? I think I gave wrong impression to you. "ANYBODY" does not work just because you said "right thing". Please do not bring up in debian-policy without cordinated fix to the issue. Policy is not tool to force people. We do not need arguments. We need facts, action and technical solution. Most of PDF.GZ are under me and tetex-doc people. Once we find good technical solution, we may do it without policy change. See internal compression discusion too. Regards, Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
On Sun, Jun 25, 2006 at 12:20:28PM +0200, Martin Wuertele wrote: > * Osamu Aoki <[EMAIL PROTECTED]> [2006-06-25 12:09]: > pdftk handels both uncompress and compress (see > http://lists.debian.org/debian-devel/2006/05/msg01440.html). I overlooked this discussion started by. http://lists.debian.org/debian-devel/2006/05/msg01434.html This had all the facts. Interesting. I must have missed nthis one. > > I understand your point here. We should not rush this nor unzipping > > should be default even in the future for changelog etc. > > > > Step should be: > > > > 1. No more *.pdf.gz file. (That is now) > > agreed Now that I know files which was compressible by gzip had good cmpression already inside PDF, I am leaning toward publishing PDF without gzipping even now. Thanks. Just to rehash facts, 228023 fhs-2.3.pdf.gz 510762 fhs-2.3.pdf 2883196 fhs-2.3.uncompr.pdf 529987 fhs-2.3.recompr.pdf 798976 reference.en.pdf.gz 1239893 reference.en.pdf 2759682 reference.uncompress.en.pdf 1261303 reference.recompress.en.pdf pdftk can not be used to further compress existing pdf files in the archive internally. They are well compressed. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
On Mon, Jun 26, 2006 at 09:59:36AM +0200, Frank Küster wrote: > There was. It ended with no conclusion. Here's my view of the outcome, > from pure recollection without looking anything up: > > - gzipping PDF files does save some space; bz2 compression would save > even more. Naturally, compressing files that are internally > uncompressed gives better results. > > - among the people that maintain packages with lots of pdf.gz files, no > one seems really opposed to shipping them uncompressed. But also > nobody seemd to be willing to do the first step, especially since > there is no consensus about not compressing them. > > > So far for the past; at the moment I think that it would be a good > compromise to not compress PDF files in dedicated -doc packages, while > keeping them compressed in mixed packages. This would mean that we > should *not* wait for debhelper to switch, but instead add -X.pdf to > dh_compress in tetex-doc. But this is just my personal opinion, and not > a very fixed one - it still has to be discussed among the Debian TeX > Task Force Seconded. signature.asc Description: Digital signature
Re: Why does doc packages need to contain gzipped files?
On Mon, Jun 26, 2006 at 10:00:57AM +0200, Frank Küster wrote: > Osamu Aoki <[EMAIL PROTECTED]> wrote: > > > Gzipping PDF provides no real space saving advantage > > What do you mean with "no real"? There is a considerable saving, as > I've shown in the previous thread a couple of weeks ago. Some has 50%, many debiandoc ones were 30%, some were 10% range. I posted list in thios thread. Afterall, I thought 50% over 1/5 is not really a lot since pdf is shrunk 1/5th with random access capability. Osamu
Re: Problems with PDF creation (was: Why does doc packages need to contain gzipped files?)
On Mon, Jun 26, 2006 at 10:17:20AM +0200, Frank Küster wrote: > Osamu Aoki <[EMAIL PROTECTED]> wrote: > > > Wait, there is less than 70MB of PDF. Yes, this is true. Due to > > difficulties of making nice PDF out of XML/SGML without hitting FTBFS, > > many packages does not bother PDF creation. Most of the doc containing > > PDF are: > > Can you please be more specific about "difficulties ... nice ... FTBFS"? > There have been some problems when teTeX 3.0 was uploaded to sid after > sarge's release, but that was a one-time problem (and the central > packages like debiandoc-smgl, linuxdoc etc. were fixed quite fast; > db2latex was harder). Do you imply that people stopped generating PDF > files last summer/autumn because of these problems? That pretty much it. > Or are there other > problems I am not aware of? doc-debian used to loop 6 times to build PDF. Many Debiandoc packages did not contain PDF for cjk. New build script is much more stable. I know some package build PDF first as upstream. I fupdown does not come with documentation. ...
Re: Problems with PDF creation
On Tue, Jun 27, 2006 at 12:28:15PM +0200, Frank Küster wrote: > Osamu Aoki <[EMAIL PROTECTED]> wrote: > > > On Mon, Jun 26, 2006 at 10:17:20AM +0200, Frank Küster wrote: > >> Osamu Aoki <[EMAIL PROTECTED]> wrote: > >> > >> > Wait, there is less than 70MB of PDF. Yes, this is true. Due to > >> > difficulties of making nice PDF out of XML/SGML without hitting FTBFS, > >> > many packages does not bother PDF creation. Most of the doc containing > >> > PDF are: > >> > >> Can you please be more specific about "difficulties ... nice ... FTBFS"? > >> There have been some problems when teTeX 3.0 was uploaded to sid after > >> sarge's release, but that was a one-time problem (and the central > >> packages like debiandoc-smgl, linuxdoc etc. were fixed quite fast; > >> db2latex was harder). Do you imply that people stopped generating PDF > >> files last summer/autumn because of these problems? > > > > That pretty much it. > > And which packages are affected? Sorry, I can not be specific. That is my old memory. Let's move on. :) > >> Or are there other > >> problems I am not aware of? > > > > doc-debian used to loop 6 times to build PDF. > > If a LaTeX document is complex, this can be in fact needed (although > I've never seen anything needing more than 4 repetitions). It could > also be a problem of the build system. In any case it has nothing to do > with the fact that the sourceis xml/sgml, except maybe that there might > be suboptimal converters involved. > > > Many Debiandoc packages > > did not contain PDF for cjk. > > cjk is still a problem, that's right. I hope I'll be able to sponsor an > upload of latex-cjk soon. Please. I did few minor NMU to get it to etch. I thought Anthony Fok is back in action. > > New build script is much more stable. > > Sorry, which build script are you talking about? doc-debian's? That what I meant. we fixed it by updating debiandoc-sgml. Anyway, that was non-trivial work for SGML DOC maintainer without LaTeX knowledge. > Then > how is this a problem for generating PDF from xml/sgml sources? That is history now. The point is if you think about building PDF from source, you are pulling huge amount of packages. That is major headache. I think people scream when GCC upgrades and cough on some programs. Similar situation is what might have happened with DOC package and TeX. I think TeX is maintained well in par with GCC. But Debian release cycle is mostly dictated by Kernel/GCC/glibc/X/gtk/gnome/Qt/... So current policy not to be FTBFS even for DOC package is tough one. (I think we need to have reasonable exceptions for DOC package. If it build with previous "stable" release, it should be allowed to be published. I know current effort of moving developer-reference to XML is only for HTML and plain text. There seem to be issues with building PDF from UTF-8. Talk to W. Borgert" <[EMAIL PROTECTED]> on this subject. > > I know some package build PDF first as upstream. > > Sorry, I don't understand what you want to say. I saw sometime ago, some package had non-PDF source, and PDF file as a part of source. Then build of the source package just moved PDF to binary package. > > I fupdown does not come with documentation. > > ? It does contain documentation in form of example text files. If > that's not enough, that's a problem of content, not of the format, isn't > it? Look into the source package and run "make ifupdown.pdf" (yep you need few more dependancy application installed like "dia". ) > Regards, Frank Osamu
How to securely read debian-private for sure
Hi,
On Tue, Jun 27, 2006 at 09:22:45PM +0100, Aigars Mahinovs wrote:
> Ian Jackson <[EMAIL PROTECTED]> said:
> > I'm one of the small minority of people who have a very negative
> > opinion about gmail. I realise I'm a bit of a kook on this subject
> > and I'd ideally I'd like to avoid having an enormous flamewar about
> > it.
I claim I was guilty too. Now I use my local ISP's mailbox. No better
though.
> > However, it has come to my attention that at least one developer
> > appears to be reading debian-private at their gmail account.
>
> I am one of those developers. I have never though that such action could
> be considered a violation of debian-private policy and some reasons for
> that have already been raised. In fact I do think that we should encrypt
> the postings to debian-private for both privacy and flamecontrol
> reasons. At this encryption stage headers of the messages should be
> stripped and only stored on the server. Only most important headers
> (like from, subject and date) would be embedded in the encrypted
> payload.
>
> Unless we go that far and realise such system, I see no reason to single
> out Google on the storage of the mail messages from debian-private.
>
> Currently GMail is the most trustable mail storage location that I have
> available. And it is also the only location I do use - all my mail from
> all other locations is redirected there. Even if I do redirect
> debian-private mail to another place, that will simply mean that I will
> stop reading it.
Let's make known technical solution more available for all of us.
I know using any external ISP mail box is no better. I do not have
fixed IP host to get mail stably.
BSMTP should work. I am talking about debian.net VHOST MX service for DD
here. This method keeps messages on the Debian machine until you pick
it to your local PC. So far, I am not successful.
I am writing HOWTO but can anyone help me really doing this.
See:
http://wiki.debian.org/DebianServiceForDD
This is based on famous old mails:
http://lists.debian.org/debian-devel/2001/02/msg00965.html
http://db.debian.org links
and poking around people.debian.org /etc/exim{4,}
I see only few DD uses this yet.
Yes, we should use this more.
Update of wiki page will be appreciated.
Osamu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
BTS tag proposal "faq"
When I encounter user configuration issues reported to BTS, I try to close it by documenting it in README.Debian. This works fine for "unstable". But when this happens on "stable", I feel not kind to mark those bug report as "wontfix". In many cases, it is FAQ and the answer is hidden under obscure location. I am not native speaker of English but the word "wontfix" certainly makes me think of ... "I do not give a d--m". Can we have tag like "faq" which we can use to indicate there is answer. Then BTS should count them as non-bug and they are best listed below normal bugs below wishlist. We should give solution to the problem when we tag them as "faq". This way, we have good record of FAQ accumulated on BTS. What do you all think? Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doc compilations: build-time or pre-built?
On Tue, Jul 04, 2006 at 09:04:48PM -0300, [EMAIL PROTECTED] wrote: > tony mancill <[EMAIL PROTECTED]> writes: > > > Steinar H. Gunderson wrote: > >> On Tue, Jul 04, 2006 at 07:25:16PM -0300, [EMAIL PROTECTED] wrote: > >>> 1) compile docs pre-build-time; or > >>> 2) compile docs in build-time > >> > >> Definitely the latter. We build stuff at build time for a reason, > >> architecture-specific or -independent alike. > > > > Is this the consensus/best-practice on this question? > > > > It seems like it would be quite taxing on the autobuilders to have to pull > > something like docbook (and its chain of dependencies) into a pbuilder just > > to recompile a manpage that doesn't change between architectures. > > > > I'm interested in this because I've typically done (2), but have recently > > started to think that (1) is more appropriate, particularly for packages > > where the documentation is a simple manpage. > > And It's exactly this the case in question, for me. The SGML template for manpage is there to help producing decent usable manpage for novice packager. I think it is useful only for intial packaging. I usually erase SGML file and update groff source of the manpage. NM guide states; 5.8 manpage.1.ex, manpage.sgml.ex Your program(s) should have a manual page. If they don't, each of these files is a template that you can fill out. Manual pages are normally written in nroff(1). The manpage.1.ex example is written in nroff, too. See the man(7) manual page for a brief description of how to edit such a file. If on the other hand you prefer writing SGML instead of nroff, you can use the manpage.sgml.ex template. If you do this, you have to: * install the docbook-to-man package * add docbook-to-man to the Build-Depends line in the control file * remove the comment from the docbook-to-man invocation in the * `build' rule of your rules file Note here of "normally written in nroff". So use of nroff source is better. Osamu PS: This section was not touched by me :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
On Tue, Jul 25, 2006 at 12:03:03PM +0100, Ian Jackson wrote:
> Henning Glawe writes ("Re: Getting rid of circular dependencies, stage 5"):
> > Well, the problem with circular deps is not caused by dpkg but by the way
> > apt calls it:
>
> Ahh. Well, perhaps apt should be fixed, as you say.
> Personally I (still!) don't use it on my own systems.
Just curious ...
dselect mounted or harddisk after rsync ?
dselect with dpkg-ftp ?
dpkg with wget
...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious problem with the tty terminal - HELP!
Hi, This should be debian-user question. On Mon, Jan 10, 2005 at 03:03:48PM +0100, Bjorn Johansson wrote: > I have a problem with the text (tty) terminals. The problem is that if I move > from the x-server to an tty text terminal I can't go back and I can't switch > to another tty terminal either. The only way to get back to X is to kill the > x-server. > > This problem has arised since I deleted all files i /lib. Then I reinstalled > the gnome and kde system with the apt tool. And I have also reinstalled > the base system, but it seems I've missed something, because this is not the > default behaviour after a fresh install. OK. Try again. :-) You still have X and xterm. > And when I mean a fresh install, I > mean installing from scratch with an empty harddisk. One idea is to use aptitude to re-install all the packages. You still have /var/cache. First, I suggest you to do back up of data. You may want to keep it. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Can you disables the "locking" of the keyboard, mouse, ...
Dear gksu maintainer Can you make gksu's default behavior to be "gksu --disable-grub" ? I think we loose nothing significant by doing this. We gain remote access and we gain stable invocation of configuration tools under CJK environment where input method (IM) support is needed as I read BTS. Since I am asking to relax so-called *security* measures, I am CCing [EMAIL PROTECTED] and DDs with affected packages to get opinion of the wider audiences. I know that some people surely think even use of gksu is bad: #211900 states "I don't want to encourage users to put in their root password in an X session, because that is not secure." This has a good point. So relaxing gksu may look even worse from this kind of view. But addressing this concern should be done differently (like sudo). == Fundamental question: What shall be the right way to allow root privilege under X for Debian? (synaptic uses gksu now) Proposal (simple one for sarge) Make gksu's default behavior to be "gksu --disable-grub" Proposal (alternative workaround, last resort for sarge) Make all the menu entries for synaptic and other programs which uses gksu to use "--disable-grub" option. Proposal (alternative, something for post-sarge) Make all the menu entries to uses sudo-type program (gksudo?) so policy based user privilege setup without root password is possible. Also "--disable-grub" needed. If user is not allowed, make nice message refusing execution. == Rationale (Summary): Although the intent of grubbing stdin and mouse by the gksu program sounds good for so-called *security* stand point, it can cause random havoc for CJK environment and seems to be unusable for remote access X environment without achieving significant security improvement. Thus I am requesting to disable this "grub" features of gksu. Although su locks stdin, it fails much less drastically. I do not think sudo locks stdin. If this is still desirable feature, this gksu program should not freeze X or segfaults when it encounters some other program try to grub mouse or stdin from gksu. Most affected softwares: scim (and possibly other CJK input method) synaptic and other system configuration tools using gksu == Rationale (iAdditional details): gksu, once started, grubs stdin and mouse to prevent security issues per its documentation. This behavior can be disabled by using "--disable-grub" option. This is causing many bug reports, I think: Related bugs I found are scim: CJK input method which redirect input through IM when invoked with CTRL-SPACE http://bugs.debian.org/283746 (Frozen X for synaptic) synaptic: started under menu with gksu http://bugs.debian.org/289994 (Frozen X) http://bugs.debian.org/211900 (No gksu+root-passwd in menu) gksu: http://bugs.debian.org/271567 (Frozen X, gnome-session) http://bugs.debian.org/280914 (Segfaults, remote X) http://bugs.debian.org/280899 (Cannot pipe stdin) http://bugs.debian.org/277723 (Lockup KDE for synaptic) IMHO, if you are working on X environment where malware exists but prevented by grubbing passwd input with gksu's grub-feature, this malware can still do bad things by changing user's synaptic menu to use "gksu --disable-grub". So you are already doomed. If we need is to set up access control to the root requiring programs, use sudo type arrangement. (gksudo?) FYI: Aptitude will prompt you for root passwd if you installed it. (Maybe it should check sudo existence and use it if available.) Osamu -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]> Brussels Belgium, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' "Our Priorities are Our Users and Free Software" --- Social Contract signature.asc Description: Digital signature
Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...
On Thu, Jan 13, 2005 at 11:26:04AM -0200, Gustavo Noronha Silva wrote: > Em Qui, 2005-01-13 às 10:42 +0100, Javier Fernández-Sanguino Peña > escreveu: > > Better solution: > > - Have gksu source a /etc/gksu.conf file directly > > I can hack gksu to read the file. I think we now have a winer idea here. I also look at code too and found: * gksu and gksudo is just a same program with different invocation name. * Parsing of GNU long-option and /etc/gksu.conf may share codes. So may I ask to implement /etc/gksu.conf. When implementing this to /etc/gksu.conf, please consider adding following features together: * All /etc/gksu.conf entries to match gnu-long-options of gksu command-line * add new long-option: --force-grab * add new long-option: --sudo-mode (Start it with gksudo mode) * add new long-option: --limit-uid=UID1:UID2:UID3:... * add new long-option: --limit-gid=GID1:GID2:GID3:... * add new long-option: --prompt (prompt before locking I/O) * add new long-option: --no-prompt (do not prompt before locking I/O: default) I think the setting in /etc/gksu.conf should have priority over command-line so super user controls this command's behavior. Gksu should check the owner and permission of /etc/gksu.conf being root:root 644 or less. Those limit-uid and limit-gid are meant to be additional safeguard for GUI-su (over PAM etc). I think if a user is not allowed to use this facility, gksu should display a short message indicating situation to X. So people will know they can not use it. Prompting is simple trick to prevent freeze for start-up situation. This is not fancy trick which works for Gnome or KDE. Just provide prompt screen before locking I/O. sudo-made will let me type only user password using gksudo mode for synaptic :-) (Or no password, if I chose to set it so.) Then you can close all the bugs I listed in the previous mail and no one will complain. We will add hints to README.Debian for SCIM. Osamu PS: I browsed your code to find gksudo binary being the same hardlink as gksu except filename. Please also link gksudo.1 to manpage :-) PS2: Interesting su-to-root story http://lists.debian.org/debian-devel/2004/11/msg00728.html http://lists.debian.org/debian-devel/2004/11/msg00735.html http://lists.debian.org/debian-devel/2004/11/msg00742.html
Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...
Hi,
(Disclaimer: I never coded C seriously for any useful commands.)
On Mon, Jan 17, 2005 at 11:24:05PM -0200, Gustavo Noronha Silva wrote:
> Em Qui, 2005-01-13 às 19:12 +0100, Osamu Aoki escreveu:
> > * Parsing of GNU long-option and /etc/gksu.conf may share codes.
>
> I don't know what you mean, maybe I'm doing some dumb thing on my patch,
> but I don't think how to completely share code here.
First add these extra long options to "struct option long_opts[] = { ..."
Then right before calling "gtk_init (&newargc, &newargv);" you source
/etc/gksu.conf and treat each line (not started with #) being part of
long option on the command line arguments by appending to this command
line option, I guess, to list started with &newargv. (I forgot how
argument is passed to getopt_long function. But as long as the logic of
parsing command line arguments is properly combined with gksu.conf
parsing, it should work.)
At last, assign short option character to each long options.
getopt_long is shared this way.
> > * All /etc/gksu.conf entries to match gnu-long-options of gksu command-line
> > * add new long-option: --force-grab
>
> Why add this? I don't see a reason.
Without this, once account is compromised, it is easy to mkodify user
menu to --allow-grab and you may unknowlingly run gksu while other
process watching the keystroke of root password. By preventing it
forcebly, it gives extra thin layer of protection.
> > * add new long-option: --sudo-mode (Start it with gksudo mode)
>
> Done.
>
> > * add new long-option: --limit-uid=UID1:UID2:UID3:...
> > * add new long-option: --limit-gid=GID1:GID2:GID3:...
>
> If we add this, then we really need to have the gksu.conf have priority
> over user-options, or this simply should not be a long option at all,
> because gksu has no suid parts, so a user can simply build a costumized
> version which will ignore this. I don't see a real point.
This is for a system user should not even try to run program with gksu.
Since menu will present these program such as synaptic, people expect
something to happen by entring password. We may give them a chance to
break it by chance (root password may be easy one to guess.). Why not
just tell "You are not allowed tun this program." This is more for
administerd host. Totally wishlist item you canm ignore this time.
> > * add new long-option: --prompt (prompt before locking I/O)
> > * add new long-option: --no-prompt (do not prompt before locking I/O:
> > default)
>
> Then we only need one of these.
* add new long-option: --prompt (prompt before locking I/O)
only is fine with me.
> > I think the setting in /etc/gksu.conf should have priority over
> > command-line so super user controls this command's behavior. Gksu
>
> As I explained above, I don't see a reason for this to be like this. I
> think it should contain defaults, not mandatory options.
If you chose not to impliment --limit-uid/gid thingy, this is true.
> > simple trick to prevent freeze for start-up situation. This is not
> > fancy trick which works for Gnome or KDE. Just provide prompt screen
> > before locking I/O.
>
> That's a solution, but I would still love to find out how to play with
> session stuff without adding a Depends on libgnomeui.
Prompting is ugly hack but certainly avoid it without Depends on
libgnomeui. If you find a good alternative, I will be happy with that too.
> > Then you can close all the bugs I listed in the previous mail and no one
> > will complain. We will add hints to README.Debian for SCIM.
>
> =D
>
> > PS: I browsed your code to find gksudo binary being the same hardlink as
> > gksu except filename. Please also link gksudo.1 to manpage :-)
>
> Yeah, have to document gksudo again =/.
>
> I've made a simple patch, a first implementation for this whole that
> still needs to be polished a lot. Would you mind to apply it, test it
> and criticize it? Here:
>
> http://people.debian.org/~kov/gksu/patches/conf-file.diff
>
> It worked alright with a simple test config file:
>
> $ cat /etc/gksu.conf
> # isso é um comentário
> disable-grab = yes # isso é outro comentário
> # mais comentário
That is pt-br. Although pt-br may be 2nd most spoken foreign language
in Japan, I do not understand :-( (I used to hear quite a bit of pt-br
in the shopping center in suburban Nagoya when I was living in Japan.)
Osamu
Re: Reboot in postinst
On Thu, Jan 20, 2005 at 07:35:42PM +0100, Wouter Verhelst wrote: > Op do, 20-01-2005 te 15:09 -0300, schreef Diogo Kollross: > > Is there a problem in using something like > > > > shutdown -r now > > > > inside a postinst script of a package? > > I was going to say something smart and funny, but it isn't coming. > > What the hell have you been smoking? Relax, he did not say "rm -rf /" in postinst. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release update: --> What is primary local type for X and console
Hi, I am happy to hear release is coming soon. Also new gnome and KDE desktop are coming to shape. At the same time, I saw many new Desktop tasks are set up to support many localized desktop and localized environment. But I am lost on where to find the policy behind setting these localized environment? I would like to know where these choices of localization tasks are coordinated and who is driving them. - Followings are background of my question: In my honest feeling, default choice by the task selection should give * Linux console should have C or one of ??_??.ISO-8859-1. * X should be started with one of the ??_??.UTF-8 or C. Other choices are possible but not so practical these days. New Desktop task choice for softwares seems to point us to set UTF-8 environment for X. (After all we use UTF-8 installer) Although language-env was great tool for woody which used non UTF-8 for X, its focus is to set X console in the traditional encoding. It is not so helpful setting up UTF-8 X system. (Correct me if I am wrong here) My m17n-env package gives easy access to UTF-8 X system. (Works with KDE, XFce, Gnome, OO, ...). KDE needs SCIM support if KDE and CJK are used which has not happened. Problem of this m17n-envpackage is that it has not been tested by many people except the user of SCIM input method packages. (CJK and Arabic, Hebrew, Iranian, Indian language speakers are the client of this SCIM suite of packages.) I know sarge was not meant to be UTF-8 desktop release but delay of release brought us almost perfect capability for UTF-8 desktop now. (Default GDM can select locale by menu. So it is trivial to set up if we only talk languages which uses simple keyboard input method only.) Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mawk is a required package but I have replaced it with gawk
On Wed, Jul 23, 2003 at 03:45:59AM +0800, Dan Jacobson wrote: > > I was thinking that to have a "valid" debian system, all "required" > > packages must be installed. > > < That's true for essential package, but required != essential. > > /usr/share/doc/debian/FAQ/debian-faq.en.txt.gz: > 6.7. What is a _Required_, _Important_, _Standard_, _Optional_, or _Extra_ > package? > > > Each Debian package is assigned a _priority_ by the distribution > maintainers, as an aid to the package management system. The > priorities are: > > * _Required_: packages that are necessary for the proper > functioning of the system. > > This includes all tools that are necessary to repair system > defects. You must not remove these packages or your system may > become totally broken and you may probably not even be able to > use dpkg to put things back. > > I will file a bug to get essential added to this file. It is mentioned > in debian-policy but not here. Please do the same to debian-reference since it shares the same contents in its Chapter 2. Patch will be nice. FYI: FAQ oe my documents, these are secondary information. So use them with care and contribute their improvement :-) THX.
Re: FTBFS: architecture all packages
On Fri, Aug 22, 2003 at 10:57:53PM +0200, Goswin von Brederlow wrote: > Colin Watson <[EMAIL PROTECTED]> writes: ... > > Have you ever built kde-i18n? When I last NMUed it it took something > > like nine hours for my laptop to build it, and my laptop isn't all > > *that* wimpy. > > Not surprising given its a ~650 MB sources. Unpacking and packaing > alone will take hours on m68k I guess. > > But an idle buildd is idel so no harm in him building it. On the other > hand you downloading 200 MB and uploading 400 MB with a 38400 modem > would realy hurt. Well not you but someone only having a 38400 > connect. Build package on debian machine with fast connection by accessing with ssh. Then copy 2 small files (dsc, changes) to the local machine and sign. Copy back them and upload. You do not need to upload rom your local machine. So your bandwidth is not key issue here. (I have ADSL connection and I admit I do things locally.) Osamu
Re: FTBFS: architecture all packages
On Sat, Aug 23, 2003 at 12:55:06PM +0200, Goswin von Brederlow wrote:
> Osamu Aoki <[EMAIL PROTECTED]> writes:
> > So your bandwidth is not key issue here.
>
> You know what online time costs for modem users? :)
Yes, I moved from US to EU. It may not be as bad as Japan though :)
If you have few iprepared script to build the package and source is synched by
CVS, it is much faster to build package this way. I am not suggesting
to do hacking while on line. ("screen" program is a ppp-user's friend to
let us log off during the long build cycle.)
(If you are a porter, that is different issue. You may have to use the
actual machine to debug it.)
Osamu
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
I think challenge response needs extra care. Anyway, current e-mail worm/virus incident is pretty bad. On Sat, Aug 30, 2003 at 07:44:56AM -0500, John Hasler wrote: > Brian May writes: > > You saying that any SMTP MTA that sends bounces to unauthenticated > > E-Mail addresses is also broken? > > Karsten M. Self writes: > > At the very least, this is a small subset of the incoming mail. > > This is about a quarter of my incoming mail. I filter e-mail worm/virus mail bounces by reading the attached original mail header. Most bounces keep the good amount of original header information. ## Worm e-mails by the header :0 * ^X-Mailer: Microsoft * ^X-MailScanner: Found to be clean Xworm/ ## Worm bounces by the header&body :0 BH * ^FROM_MAILER * ^X-Mailer: Microsoft * ^X-MailScanner: Found to be clean Xworm-bounce/ I guess our e-mail server can do the similar checks. Osamu
Debian provide un-modified source for kernel-patch
Hi, Flame aside ... let's look at technical side. On Sun, Sep 21, 2003 at 02:44:03PM +0200, martin f krafft wrote: > also sprach Herbert Xu <[EMAIL PROTECTED]> [2003.09.21.1341 +0200]: > > * The vanilla kernel source is readily available: > > I don't consider this readily available. It's faster to just > download it from kernel.org. But that requires net connection. You know we burn to CD as *stable* too. > Plus: why do you make the backport default? Shouldn't users have the > choice to apply the patch if they wish, rather than those that don't > want it having to unpatch? I am not an expert but I think you should try along what Herbert Xu suggested which seems to give you very easy path to patch files. I did not know but looks very nice. $ apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22 $ tar xjf /usr/src/kernel-source-2.4.22.tar.bz2 $ cd /usr/src/kernel-patch There is a file /usr/src/kernel-patches/all/2.4.22/debian/list whose content goes like: - # This file is sorted by patch dependency. The patch which applies to the # upstream kernel must come first. patch-2.4.22-1 2.4.22 2.4.22-1 - This seem to offer very good path to apply patch to the upstream kernel which must be applied first. Did you try using this? Osamu
Re: Debian should not modify the kernels!
HI, I have no issue how you ship debian kernel :-) On Sun, Sep 21, 2003 at 09:41:41PM +1000, Herbert Xu wrote: > I've got a few points for you: > > * The vanilla kernel source is readily available: good. > apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22 > tar xjf /usr/src/kernel-source-2.4.22.tar.bz2 > cd kernel-source-2.4.22 > /usr/src/kernel-patches/all/2.4.22/unpatch/debian > > * The IPSEC backport can be easily reversed by unapplying > the patches given in the README.Debian file. :-( Can your patch file to be more modular like X package? It is a big chunk. Osamu
Resolvconf -- suggested reading before installing this :-)
Hi, On Sun, Sep 28, 2003 at 08:20:47PM -0500, Manoj Srivastava wrote: > On Sun, 28 Sep 2003 21:49:28 +0200, Thomas Hood <[EMAIL PROTECTED]> said: > > > Manoj wrote: > >> > I would be interested in knowing how you set it up equivalent to > >> > cardctl scheme allows me to set up pcmcia networks. > > > cardmgr's system of configuring things dependently upon > > "scheme,socket,instance,hwaddr" is quite powerful but it is possible > > to configure interfaces dependently on these variables using > > ifupdown too (... though not so conveniently). See below. > > One can also modify /etc/pcmcia/network; line 109: > > < cat $RESOLV >> $RESOLV.N; mv $RESOLV.N $RESOLV > > cat $RESOLV >> $RESOLV.N; resolvconf -a $DEVICE < $RESOLV.N > > Anyway, I think I am goinf to use start_fn and stop_fn in > /etc/pcmcia/network.opts instead of using either hotplug or modifying > /etc/pcmcia/network; I am already comfortable with my network.opts, > and it is all working together very nicely now. I still use start_fn and stop_fn on my old note PC. But as I read Thomas' tutorial on dynamic "DEBIAN" network configuration, centralizing configuration around /etc/network/interfaces as he proposes seems to provide cleaner environment. AJ's ifupdown package is quite interesting and very debian specific. There were not much tutorials on this subject and many conventional configuration procedures tend to cause some trouble with ifupdown if they are not deployed very carefully. Although he provide source to make detailed source documentation, this key package practically comes in very cryptic and short user manual page only. Whomever interested on this subject, Thomas' network set up tutorial (draft) is available as "10 Network configuration": http://qref.sourceforge.net/Debian/reference/ch-gateway.en.html or http://www.debian.org/doc/manuals/reference/ch-gateway.en.html (older) (Yes, he is rewriting my old small section with whole new section with very good overview. Please tell Thomas about any problem in 10.1-10.8. Please understand this is on-going update.) Osamu
Re: Debian should not modify the kernels!
Hi, thanks the good maintenance by Herbert, On Sun, Sep 28, 2003 at 08:12:43AM +1000, Herbert Xu wrote: > Andreas Metzler <[EMAIL PROTECTED]> wrote: > > martin f krafft <[EMAIL PROTECTED]> wrote: > > What I'd really like to hear is a reaction from Herbert to: > > Osamu Aoki <[EMAIL PROTECTED]> in <[EMAIL PROTECTED]> > > | Can your patch file to be more modular like X package? It is a big > > | chunk. > > > > Which could make both sides happy. Instead of one big patch containing > > bugfixes, security fixes and feature additions to make them separately > > available in the kernel-source-package. > > Again this is something that I have already stated my position on. > This is simply unmaintainable due to the complex relationships between > patches. Interesting :-) My use of word "modular" may have mislead you as I see above. Just to avoid confusion: 1) I like default kernel get good maintenance including IPsec if the expert Herbert Xu decides to do so. (No argument here from me.) 2) I was not suggesting very fine grained "modular" patch for each issues. I was expecting something like 3-4 stage patches. * 1st big patch: cramfs etc. which are essential to be Debian kernel * 2nd big patch: basic bug fixes. (No feature change, something you may have got from upstream pre release patch.) * 3rd big patch: basic feature fix. (IPsec and all others which is generally good and nice for most users.) * 4th big patch: Whatever you did at last minutes :-) The order of above is not essential for me. It should apply clean though. > In any case, the kernel-source package's README file should contain all > the information you need to extract any particular patch that you're > interested in. If you make your patch somewhat more split into "staged" manner (yes, I am not asking "modular"), then it is easier for specialty patch maintenance become easy. After all those specialty patch user may no need features needed by most user but he certainly expects having cramfs and other standard features of Debian. If you claim making simple 3-4 stage patch maintenance "unmaintainable due to the complex relationships between patches", it is certainly unmaintainable for other "patch" package maintainer or any one try to apply patch to keep up with you. I know you maintain position that other patch maintainer can do 1st and 2nd stage patch himself using vanilla source after unpatch. But, to me, it is waisted resources. I did not understand why you want to document how you build package only in the text of documentation but not in source package itself. Cheers, Osamu PS: I once wanted to apply ACPI patch and hit similar issues as Martin. It was too much for me and I gave up :-( Now Debian version of kernel is 2.4.21 and I am happy.
Package verification ? (Best practice)
Hmmm...
On Sun, Oct 05, 2003 at 09:38:30AM +1000, Brian May wrote:
> On Sat, Oct 04, 2003 at 01:42:36PM -0400, Fabien Ninoles wrote:
> > Although your proposition seems more complete, have you try
> > debsums and checksecurity? debsums with the following
> > feature in /etc/apt/apt.conf
> >
> > DPkg::Post-Invoke {
> > "debsums --generate=nocheck -sp /var/cache/apt/archives";
> > };
> >
> > Can be very handy in creating md5sums (BTW, I think it's a bug
> > against policy to include md5sums in control files).
>
> Is there some way you can do the same thing for packages installed with
> dpkg only and without apt-get? The apt-get layer would appear to be the
> wrong layer for this task IMHO.
Very true.
By the way(thus changing title), the equivalent for above less
interesting but still very good trick, I recommended:
6.4.13 Verify installed package files
debsums enables verification of installed package files against MD5
checksums. Some packages do not have available MD5 checksums. A possible
temporary fix for sysadmins:
# cat >>/etc/apt/apt.conf.d/90debsums
DPkg::Post-Install-Pkgs {"xargs /usr/bin/debsums -sg";};
^D
per Joerg Wendland [EMAIL PROTECTED] (untested).
This one is better since it will be more compatible package upgrade by using
apt.conf.d/ . But "-p" option maybe needed. "--generate=nocheck" seems good
idea.
Post-Install-Pkgs withxargs
Post-Install without xargs
I do not know which is better.
Anyone have better suggestion?
(Maybe adding "apt-get --reinstall -d install `debsums -l`" trick is
also needed.)
Osamu
PS: Full section of above quote is available as:
http://www.debian.org/doc/manuals/reference/ch-package.en.html#s-debsums
Re: Debian Reference
Hi, On Sat, Sep 17, 2005 at 02:41:43PM +0100, Antony Gelberg wrote: > I have been taking a lot of interest in the Reference recently, as a > result of time on d-u and #debian, and seeing where we fall short from > a documentation point of view. Thank you for filing bug #325777. We appreciate this kind of feed back on a details which I overlooked. Next time, please file your bug to deabian-reference as the package name so Frans will not be bothered by your bug report. You may want to read documentation at bugs.debian.org for how our bug sustem works. As for the quality of the DR document, I am keenly aware of the issues. I just do not have time to do updates as much as I wish. Also I do not have good writing skill in English as a non-native English user. So I appreciate help in this respect. (I have been helped by others but they are also quite busy these days.) > Before I get too involved however, can somebody give me a guide as to > how the Reference is looked upon from within Debian? In my honest opinion, most of the DD are busy with thier own packages, few took time to read DR in details, or at all, to find minor issues which was caused by the migration of packages with time. Besides, they have good post-installation skill, they do not need to learn from this. If you want to get interest level on Documentation itself, you may want to read debian-doc archive. > I don't particuarly want to dive in if it's a dead duck. If we find a live duck, I think DDP will switch Debian Reference to that new duck. > It seems to me that it is the closest thing that we have to a distro > manual, and contains lots of useful pointers, but suffers from lack of > visibility and lack of structure. Your observation is somewhat correct. I think user oriented distribution manual is collection of documents now. See list on http://www.debian.org/doc . I have few suggestions and comment. * please check out archive of debian-doc mailing list. * please think ways to improve this situation as a volunteer project. (i.e., few has time to work on issues you think is the most important and they have their own priorities. You can dictate only your time and efforts.) * Please bring live duck to us. It is easy to complain but providing something positive with minimal efforts of the others requires a lot of time and efforts of yours. Here are my wishlist: - Be kind to the people who contributed their time to the project. - Report bug with a patch to SGML source. - Think translation syncing (I need patch for all languages to update) - Keeping CVS and web up in shape. - Help ensure functioning TeTeX international build environment in pbuilder - Help SGML(traditiional encodings) to XML(UTF-8) transition efforts. ... Whenever I find a person who gives us solid patch to the document, I gave CVS access to the document and worked with the person to improve DR. Complete reorganization can be done in the branch. Once it become presentable, we can switch to it. That is the beauty of using CVS-like system. But I think if we do this, we should also change file format to XML in UTF-8 encoding. I hope you will be the one of those who lead next iteration of DR. Regards, Osamu PS: I am a bit behind these days due to time constrain. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Reference
On Sun, Sep 18, 2005 at 04:20:32AM +0100, Antony Gelberg wrote: > > There's rather a lot there. Nay, that a tiny fraction of things which needs to be consideded. This is one of the key reason behind why few bothered to contribute. So changing this situation from bottom by offering better infrastructure to create such an document is way to think. > I'll start with a patch for Chapter 2 to > see if we are on the same wavelength. We need to restructure it before > we can improve the content. Chapter 2 shares a lot with FAQ in terms of contents. Javi is updating it. See mailing list for the details and be aware of it. This chapter describes a lot of old things which is useful for few extreme case. To update it, you need to be very familiar with how Debian works and worked. I think you may need a bit more time for that. So for now, I strongly limit patch to factual errors. Instead, I suggest you to do bug hunting and issue hunting on chapters and thinking how all other needs to be reorganized and how that will be achieved: 3. installation hint. - how this can be reorganized without duplicating install masnual. 5. Upgrading distribution - how can this be made distribution independent - avoid overlap with installation and release note. 6. Package management - Now that aptitude is main tool, we need to carefully update this. - Remove all woody/potato things. 7. Kernel - Rewite this focusing udev/2.6 management (But who knows best?) 8. Tips - New installation CD is not easy tool for emergency recover. Suggest bootable CD alternative - im-switch - UTF-8 Oh, please read some basics of contributing document at: http://qref.sourceforge.net/doc/ Osamu FYI: As for the spam on the list, I gave up doing spam filtering myself. I use (semi-)commercial POP account (gmail) to do the dirty work for me to save my bandwidth. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: access to debian mirror pools
On Tue, Sep 20, 2005 at 09:34:22AM -0500, Carlo Segre wrote: ... > I have investigated this by grabbing individual files with wget and I have > discovered that the same IP address is selected each time I run wget on a > specific computer. ... > Any insights? Is this a bug, if so for what package? You should check your DNS set up of each computer which you ran wget or any of the similar programs. DNS server (or its local cache value on your PC) provides IP address to programs such as wget and apt. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reviving the Debian FAQ
On Wed, Sep 14, 2005 at 02:01:48AM +0200, Javier Fernández-Sanguino Peña wrote: > > The Debian FAQ [0] has been, unfortunately, unmaintained for quite some time > and needs a thorough review. True. > I updated information in the FAQ in preparation for the sarge release when I > noticed that it was out of date and incomplete [1]. After the release > I've been fixing some other obsolete sections and fixing some of > its long-standing bugs, uploading new revisions of the doc-debian package > in the process. Thanks. > It would be really great if other DDs could review the FAQ fully and > point out: > > a- missing FAQ items, that is, things that people commonly ask about Debian >that are not there and we should write about. > > b- obsolete FAQ items, i.e., items in the FAQ that are no longe relevant and >should be removed or rewritten. > > c- incorrect FAQ items, i.e., items that should be rewritten or fixed because >they contain innacurate statements. I think key for maintainable document is limitted scope. For things like "How to become DD?", pointer to NM page will be better. In the same thought, remove overlap with Debian Reference in terms of archive structure and deprecated package management tool such as dpkg-ftp. I think pointer to Debian Reference Chapter 2 will be good on those. > several reasons why I believe this document should be kept up to date: it's > included in the official Debian CDs (it's one of the few documents provided > there), it's included in all the official Debian mirrors (under /doc/), > and many users (well, those that RTFM, that is) might go read it since > it's listed as the first "User document" currently in our web page. Yes. That is why this FAQ should limit its scope to the narrowest one and leave most of the descriptive contents to other places. Good luck. PS: Maybe we need to discuss this in debian-doc. How to recommend user which distribution to use stable/testing/unstable, is touchy issue.
Re: cannot log into debian svn server, communication via svn+ssh broken?
On Wed, Oct 12, 2005 at 01:38:47PM +0200, Frank Küster wrote: > Norbert Preining <[EMAIL PROTECTED]> wrote: > > > Hi all! > > > > ATM I cannot log into the svn server, nor use svn+ssh anymore. Are there > > any works going on? > > I have no problems here. Hmmm.. I have been unable to use CVS (SSH) tonight. They keep asking for password which I should not need. I doubts LDAP issues. I will come back later. Osamu
Re: cannot log into debian svn server, communication via svn+ssh broken?
On Wed, Oct 12, 2005 at 08:10:04PM +0200, Frank Küster wrote: > Osamu Aoki <[EMAIL PROTECTED]> wrote: > > > On Wed, Oct 12, 2005 at 01:38:47PM +0200, Frank Küster wrote: > >> Norbert Preining <[EMAIL PROTECTED]> wrote: > >> > >> > Hi all! > >> > > >> > ATM I cannot log into the svn server, nor use svn+ssh anymore. Are there > >> > any works going on? > >> > >> I have no problems here. > > > > Hmmm.. > > > > I have been unable to use CVS (SSH) tonight. They keep asking for > > password which I should not need. > > I use RSA authentication (with a password to the key, but that's usually > maintained by ssh-add, because the askpass functionality of Emacs' svn > mode seems to be broken (in sarge). There must have been some server side issue. I just used CVS (SSH2 with sshkey) without problem at alioth. Try again :-) Osamu
Re: a few tips on proper use of version tracking in the Debian BTS
On Sat, Oct 22, 2005 at 05:14:20PM -0700, Steve Langasek wrote: > On Sun, Oct 23, 2005 at 09:41:15AM +1000, Brian May wrote: > > > "Brian" == Brian May <[EMAIL PROTECTED]> writes: > > Along similar lines, if a have a "closes: #nnn" in my changelog for > > package X, but the bug is for package Y, is this going to mess things > > up? > > Well, things will be messed up, as there's no possible way for the BTS to > correctly infer your meaning. :) If the bug is closed in an upload of > package X, then either the bug belongs to package X[1], or it shouldn't have > been closed. That is what I did few days ago and BTS seems to be quite comfortable dealing with it on the BTS web. Resolved bugs ... #126438: Nested and tags produce bad pdf hyperlinks Package: debiandoc-sgml (fixed: debiandoc-sgml-doc 1.1.17); Severity: minor; Reported by: Chris Tillman <[EMAIL PROTECTED]> Am I causing problem to BTS? Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely --> Debian New Maintainers' Guide
Hmmm... On Fri, Jan 25, 2008 at 10:51:41PM +0900, Osamu Aoki wrote: > I ended up updating NM guide which only had dpatch to current one with > quilt: > > http://www.debian.org/doc/manuals/maint-guide/ch-build.en.html#s-dpatch As I read this thread back to d-project, ... interesting. It all started with: http://kitenet.net/~joey/blog/entry/a_problem_with_tools/ http://kitenet.net/~joey/blog/entry/an_evolutionary_change_to_the_Debian_source_package_format/ This seems to be much cleaner than dpatch or quilt. Also with the help of gitk, history is much more visible. I look forward to see it matured and accepted. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely --> Debian New Maintainers' Guide
Hi, On Fri, Jan 25, 2008 at 10:51:05AM +0100, Lucas Nussbaum wrote: > On 25/01/08 at 08:01 +, Steve Langasek wrote: > > As a second runner up, quilt is ok by me. :) > > I made some stats (see [1]). 7.8% of our packages use quilt, while 14.4% > use dpatch. This was discussed in debian-doc and ... > It would be great to document in some place (devref?) why > quilt should be used instead of dpatch, because I don't think it's > obvious for everybody :) > > [1] http://www.lucas-nussbaum.net/blog/?p=275 I ended up updating NM guide which only had dpatch to current one with quilt: http://www.debian.org/doc/manuals/maint-guide/ch-build.en.html#s-dpatch Osamu PS: I only used dpatch in my packages and quilt description came from official doccumentation and ML discussion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dpatch and "diff -u"
This is a bit going out of original post but... On Sat, Feb 02, 2008 at 05:14:25PM +0900, Charles Plessy wrote: > http://wiki.debian.org/debian/patches You have column for "accepts diff -u output" and "No" for dpatch. I am not quite sure what is the criteria for you but to me dpatch accepts "diff -u" output for "patch -p1". At least that is what I did as lazy person. All I had to do was add some header text copied at the start of patch file. So at least: Yes (by adding header text) Osamu PS: It looks better to use quilt over dpatch although I never did. But using DVCS seems more elegant. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#475361: ITP: chkconfig -- system tool to enable or disable system services
Hi, I can mention old bug... On Thu, Apr 10, 2008 at 02:25:14PM +0200, Michael Biebl wrote: > Peter Eisentraut wrote: > > Am Donnerstag, 10. April 2008 schrieb Michael Biebl: > >> What's the advantage over exisiting tools like sysv-rc-conf? > > > > 1. chkconfig works solely on the command line. > > sysv-rc-conf has both a command line interface and a ncurses based > interface. > I don't see, why command-line only should be an advantage. > > > > > 2. sysv-rc-conf is mostly unmaintained and broken for some (of my) > > practical > > uses. > > Do you have any references (e.g. bug numbers). sysv-rc-conf seems to > work fine for me. > #285850 and all bugs realted to floating service. Most of these bugs are around 2-3 years old. > > > > 3. chkconfig is simpler and more convenient. > > Could you elaborate on that. > > sysv-rc-conf $service on|off > > is very convenient and I'm not sure if it can be made any simpler. > > > 4. chkconfig is well known for users coming from Red Hat and SUSE. > > ok. > > > > > 5. chkconfig works well with the new insserv. > > Could you elaborate on that? What's the problem with sysv-rc-conf and > insserv? Really, I do not use neither but when I was updating Debian Reference for newbie, I thought such tool should help. There were more oroblem using it for me. I use mc for such task when I feel lazy on typing. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#475361: ITP: chkconfig -- system tool to enable or disable system services
On Fri, Apr 11, 2008 at 04:53:52PM +0200, Michael Biebl wrote: > Osamu Aoki wrote: > > >> > >>> 5. chkconfig works well with the new insserv. > >> Could you elaborate on that? What's the problem with sysv-rc-conf and > >> insserv? > > > > Really, I do not use neither but when I was updating Debian Reference > > for newbie, I thought such tool should help. There were more oroblem > > using it for me. I use mc for such task when I feel lazy on typing. > > > > Osamu > > > > I don't have any objections against chkconfig being packaged for Debian. > I simply wanted to know, why Peter considers it superiour to other > alternatives and if I should reconsider using sysv-rc-conf (which I have > used and recommended to others up until now). > > If insserv is really enabled by default for lenny, and chkconfig is the > only tool working properly with insserv, then we should recommend > chkconfig over other tools. > > Cheers, > Michael Me either. My comment location was a bit confusing. As long as new tool is better maintained and have less problem (floating servce handling, protection from system shutdown with multiple key inputs, ) I would love to get new tool. I am curious too. When packaging this new tool, please check if this new tool suffer proplem reported to sysv-rc-conf. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA
Hi, Recent openssl issue lead me to http://db.debian.org/password.html and made me wonder why script example uses DSA key while main text only talks about RSA key. | Alternatively, you can do without a password and use PGP to manipulate your | LDAP information through the mail gateway and use SSH RSA Authentication to | access the servers. To setup OpenSSH for RSA you need to first generate a | private RSA key using ssh-keygen and select a good passphrase for it. Then send | the public portion of the key to the LDAP directory: | | gpg --clearsign < ~/.ssh/id_dsa.pub | mail [EMAIL PROTECTED] | | NB: Only version 2 RSA keys are accepted. Version 1 RSA keys (i.e. identity.pub | files) will not work. If main text is s/RSA/RSA\/DSA/g , I understand script example but ... Is there any reason to use DSA key insted of RSA key(~/.ssh/id_rsa.pub) ? Just curious, Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA
Hi, Considering recent issues, http://db.debian.org/password.html requires updated as "s/id_dsa.pub/id_rsa.pub/". Discussion as below. Do I need to make rt thingy? I am not yet familiar with it. On Wed, May 14, 2008 at 07:50:29PM +0200, Luk Claes wrote: > Osamu Aoki wrote: > > Hi, > > > > Recent openssl issue lead me to http://db.debian.org/password.html and > > made me wonder why script example uses DSA key while main text only > > talks about RSA key. > > The text talks about RSA keys as they are preferred over DSA keys. > > > | Alternatively, you can do without a password and use PGP to manipulate > > your > > | LDAP information through the mail gateway and use SSH RSA Authentication > > to > > | access the servers. To setup OpenSSH for RSA you need to first generate a > > | private RSA key using ssh-keygen and select a good passphrase for it. > > Then send > > | the public portion of the key to the LDAP directory: > > | > > | gpg --clearsign < ~/.ssh/id_dsa.pub | mail [EMAIL PROTECTED] > > | > > | NB: Only version 2 RSA keys are accepted. Version 1 RSA keys (i.e. > > identity.pub > > | files) will not work. > > > > > > If main text is s/RSA/RSA\/DSA/g , I understand script example but ... > > > > Is there any reason to use DSA key insted of RSA key(~/.ssh/id_rsa.pub) ? > > On the contrary, it's better to use RSA keys as they can be bigger and > are faster. Ok, With today's announcement on Alioth and SSH by Roland Mas made me to use RSA anyway. FYI: | From: [EMAIL PROTECTED] | Subject: Mail Gateway failed: Message is not PGP signed: | To: [EMAIL PROTECTED] | Date: Thu, 15 May 2008 12:29:33 + | | Hello! | | Your request to the mail gateway is malformed, or an internal processing | error occured. The information below may help you, or the gateway | administrator to identify the problem. | | Error: Message is not PGP signed: | ==> Message Error: No PGP signature | | | Please email [EMAIL PROTECTED] if you have any questions. This is what I got for me sending DSA key. After sending RSA key, I got: | From: [EMAIL PROTECTED] | Subject: DB Change Request | To: Osamu Aoki <[EMAIL PROTECTED]> | Date: Thu, 15 May 2008 12:29:49 + | | Hello Osamu Aoki <[EMAIL PROTECTED]>! | | Your request to change your directory information has been processed. | Note that there is a propagation time for many of the entries so please | be patient. Here are the results: | | > ssh-rsa | ... So this page needs to be updated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA
On Thu, May 15, 2008 at 03:03:55PM +0200, Peter Palfrader wrote: > On Thu, 15 May 2008, Osamu Aoki wrote: > > > Considering recent issues, http://db.debian.org/password.html requires > > updated as "s/id_dsa.pub/id_rsa.pub/". > > My mail to d-i-a said that you need to use RSA keys. You have read > that, right? Yes. > The page on db.d.o will get updated eventually, for now think of it as > "You need to be at least this smart to get your key into LDAP". Good. I tried DSA key before you send the mail though :-) Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FYI: VCS choice these days
Hi, (Composed as UTF-8 mail with graphic characters) I have been trying to update debian reference. As a part of this effort, I made snapshot of popularity of packages. One of the most interesting thing I noticed by doing this was change in popularity of VCS. (Just 1/2 year r so). When I started to track popcon data, CVS was used more than SVN. GIT was just had very minor portion of VCS user. Here are a summary of the version control system (VCS) on the Debian system now: Table 11.10. List of version control system tools. ┌──┬┬─┬──┬───┬─┐ │ package │ popcon │size │ tool │ VCS type │ comment │ ├──┼┼─┼──┼───┼─┤ │cssc │V:0.01, │2168 │CSSC │local │Clone of the Unix SCCS │ │ │I:0.06 │ │ │ │(deprecated) │ ├──┼┼─┼──┼───┼─┤ │rcs │V:1.9, │756 │RCS │local │"Unix SCCS done right" │ │ │I:10│ │ │ │ │ ├──┼┼─┼──┼───┼─┤ │cvs │V:5,│3624 │CVS │remote │The previous standard remote VCS │ │ │I:30│ │ │ │ │ ├──┼┼─┼──┼───┼─┤ │subversion│V:9,│3456 │Subversion│remote │"CVS done right", the new de │ │ │I:26│ │ │ │facto standard remote VCS │ ├──┼┼─┼──┼───┼─┤ │git-core │V:3, I:5│6712 │Git │distributed│fast DVCS in C (used by the Linux│ │ ││ │ │ │kernel and others) │ ├──┼┼─┼──┼───┼─┤ │mercurial │V:0.6, │372 │Mercurial │distributed│DVCS with python and some C. │ │ │I:2 │ │ │ │ │ ├──┼┼─┼──┼───┼─┤ │darcs │V:0.3, │6168 │Darcs │distributed│DVCS with smart algebra of │ │ │I:1.8 │ │ │ │patches (slow). │ ├──┼┼─┼──┼───┼─┤ │bzr │V:0.3, │15012│Bazaar│distributed│DVCS with python (used by the │ │ │I:1.8 │ │ │ │Ubuntu) │ └──┴┴─┴──┴───┴─┘ V sands for vote (i.e. use) and I stands for install. Numbers are % of popcon votes. CVS is not as used as SVN these days. Within DVCS, GIT is 5-10 folds popular than other ones. So I can safely say that SVN is now the default VCS and GIT is getting very popular in use and have 1/3 of top SVN. (popcon data is diluted by old machines so I think GIT use is a lot.) See more on http://people.debian.org/~osamu/pub/getwiki/html/ch11.en.html#listofversioncontrolsystemtools Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FYI: VCS choice these days
Hi, I did not mean to say that VCS in low numbers are unpopular. Instead, my message should be understood as there are many popular VCSs and popularity of use is moving. On Wed, May 21, 2008 at 10:27:40PM +0200, Michal Čihař wrote: > Dne Wed, 21 May 2008 15:10:14 -0500 > Steve Greenland <[EMAIL PROTECTED]> napsal(a): > > > FWIW, and I'm not sure it actually conflicts or invalidates or even > > causes questions of the popcon data, but installs, at least, may not > > mean that much. On my main home box, several years old now, I've got all > > of cvs, svn, rcs[1], mercurial, git, and bzr installed, because at one > > point or another I've need to grab source from a repository that used > > that particular tool. Currently I only *use* mercurial. Then you are voting for mercurial if you participated in popcon. vote: number of people who use this package regularly; This "vote" is more important for executable packages here. The large "installed" with low "vote" may be indication that people has found some new good alternative for a popular tool of yesterday. (RCS -> DVCS such as git, mercurial, ...) 1/3 of people installed mercurial actually uses it while 1/5 people installed RCS actually uses it. That is interesting to me. > Well, popcon is not probably best source of such information, but there > is hard to find better one. For me, I have installed cvs, svn, bzr, > git and darcs (at least, I did not really check, but these I use > regularly), most of them just because I have to use them in some > projects... Then you are voting for all :-) Shorter summary of vote data goes as: cvs 5% subversion9% git-core 3% mercurial 0.6% darcs 0.3% bzr 0.3% You can say mercurial and bzr has significant user base. There are many useful packages in 0.1% vote range. 6 month ago, cvs was at around 10% and subversion was about 5% and git was about 1% as I vaguely remember. (Debian web and DDP have switched from cvs to subversion during this time.) At the same time, most machine (>80%) does not use any VCS recently. Nothing to be excited. Just facts. I use git locally these days and use subversion, cvs, git, and bzr as I need to access upstream. Mercurial and darcs seem interesting but did not have time to learn yet. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FYI: VCS choice these days
Hi, On Fri, May 23, 2008 at 02:05:14PM +1000, Brian May wrote: > Osamu Aoki wrote: >> Shorter summary of vote data goes as: >> >> cvs 5% >> subversion9% >> git-core 3% >> mercurial 0.6% >> darcs 0.3% >> bzr 0.3% >> > Does monotone not get a mention? or was monotone missed? "missed" yes. I think it was because 0.01% which is 1/10th of mercurial. I will add it now to web page. Good old "arch" and "baz" missed intentinally. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FYI: VCS choice these days
On Thu, May 22, 2008 at 12:31:09PM -0400, Felipe Sateler wrote: > Osamu Aoki wrote: > > > Then you are voting for mercurial if you participated in popcon. > > > > vote: number of people who use this package regularly; > > Note that the vote is not that reliable either: it needs atime, which is > getting > less and less used. Thanks for your comment. I knew noatime mount option but this lead me to do some googling: http://lwn.net/Articles/244829/ http://kerneltrap.org/node/14148 Interesting. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages in section python/perl simply because implemented in python/perl
On Sat, May 24, 2008 at 10:54:52AM -0500, Steve Greenland wrote: > > (NOTE: Am I the only one who thinks descriptions, especially short > > descriptions as in phenny, usually shouldn't tell what language was > > used to implement the program? It's just not relevant to the user.) > > I mostly agree with this. The exception would be development tools and > libraries, where the implementation language can be relevant. OTOH, > those kind of tools probably should be in the relevant section. > > (I sometimes look at implementation language for user apps *if* I > expect it's something I'm going to want to hack, but at that level I can > just look at the dependencies.) True. And there is debtags which classify by implimentation language: $ aptitude search ~Gimplemented-in::perl > For your main point, that user apps belong in a section relevant to > their function, not their implementation, agree 100%. Yes. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VLC 0.8.6a - Why hasn't the package been upgraded?
Hi, But here is your answer. On Sat, Jun 14, 2008 at 08:35:36PM +0200, Björn Johansson wrote: > > Greetings! > > I have a working install of Debian Etch over here and it's installed on > an Powerbook G3 "Lombard" and the version of VLC which is part of Debian > Etch is still version 0.8.6a and I'm wondering why you people haven't > done a package of version 0.8.6e yet? Because Etch is stable release, I guess. We keep old one intentinally for the sake of stability. http://packages.debian.org/search?keywords=vlc&searchon=names&suite=all§ion=all Package vlc * sarge (oldstable) (graphics): multimedia player for all audio and video formats 0.8.1.svn20050314-1sarge3: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc * etch (stable) (graphics): multimedia player and streamer 0.8.6-svn20061012.debian-5.1+etch2 [security]: alpha amd64 arm hppa i386 ia64 mips mipsel powerpc s390 sparc * etch-m68k (graphics): multimedia player and streamer 0.8.6-svn20061012.debian-5: m68k * lenny (testing) (graphics): multimedia player and streamer 0.8.6.c-6+lenny5 [security]: alpha amd64 arm hppa i386 ia64 mips mipsel powerpc s390 sparc 0.8.6.c-6: armel * sid (unstable) (graphics): multimedia player and streamer 0.8.6.e-2.3+b1: amd64 i386 mips mipsel 0.8.6.e-2.3: alpha arm armel hppa ia64 m68k powerpc s390 sparc 0.8.6.e-2.1 [debports]: kfreebsd-amd64 kfreebsd-i386 So Debian is quite up-to-date :) > I'm thinking of maybe trying to compile the source on my own, but I > don't want to break the current installation of VLC, so, so far I > haven't tried it. If you want to use very latest softwares (even with some trouble), use * testing (now lenny) or * unstable (sid) > Björn Johansson I sense that you need to get to know How Debian operates a bit more. Good luck. Osamu http://www.debian.org/doc/manuals/reference/ (old) http://people.debian.org/~osamu/pub/getwiki/html/index.en.html (new) http://people.debian.org/ is down for last some hours, though.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reporting bug on documentation
On Mon, Jul 06, 2009 at 12:32:30PM +0200, mathieu.malate...@gmail.com wrote: > 'lo > > Where should I report broken links from: > > http://www.debian.org/doc/developers-reference/new-maintainer > > There is a link to : > http://www.debian.org/doc/developers-reference/new-maintainer.html#mentors > > which does not exist. It works for me. If you are sure about problem, please file BTS report to "developers-reference" packagedevelopers-reference (with patch if developers-referencepossible.). We will see copy at debian-...@lists.debian.org :) Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
Hi, (I want to see as much UTF-8 support. These days, it is not bad. Try using "sed" with UTF-8. It works! Of course with some understandable gliches.) On Mon, Aug 10, 2009 at 08:55:27PM +0200, Norbert Preining wrote: > On Mo, 10 Aug 2009, Roger Leigh wrote: > > Of course there's a penalty for certain operations. But UTF-8 is about > > as compact as an extended encoding is going to get. > > Rubbish. You know why in Japan and other Asian countries UTF8 is not > so common? Because many of their glyphs need 4 (four!) bytes, while > for example jis-2022 (AFAIR) is much more compact. Hmmm... not the best example here, ... technically if you are talking size. We got too many encodings for Japanese. You see too many ESC code for jis-2022. > We are not living in an ASCII world anymore. True. Our choice of encoding is not much to do with size. It is inertia and backward compatibility. FACTS: Many Japanese e-mail uses jis-2022 for compatibility. (E-mail was safe only for 7 bit data in old days). As far as data size goes, compact popular ones are EUC(Unix) or S-JIS(MS system). These are used in web pages etc. still. These are as small as UTF-16/UCS-2 used for many Unicode data internally. But please note new MAC and XP/Vista/... use Unicode and I see many files can be in UTF-8. So things are changing. Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
