[gentoo-dev] Leaving Gentoo
Hi all, I'm leaving Gentoo. This isn't due to ill feelings or anything like that; I just have no time to work on Gentoo anymore, and have been 'dormant' for many months now. This isn't going to change anytime soon, and so there's no point in my keeping the account. I've enjoyed working on Gentoo over the years, and have learned a lot and met many interesting people... Take care everyone, and take care of Gentoo for me :-) Infra: please remove my accounts and cvs/ssh access, kde herd membership, and homedir. I'll unsubscribe myself from the lists as needed, but please unsubscribe me from the [EMAIL PROTECTED] and from -core, since I'm not sure how to do that myself. I'll be reachable by email at [EMAIL PROTECTED] I'd appreciate it if [EMAIL PROTECTED] email continues to be redirected for a little while, either to [EMAIL PROTECTED] or to where it currently goes via my ~/.forward. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpGzYT5s5Pa6.pgp Description: PGP signature
[gentoo-dev] UTF-8 encoding and file format of manuals
Respectful Gentoo developers, I would like to ask what do you think about UTF-8 encoded manual pages? I mean, the files like ls.1.gz, which are used by honorable man program. Recently I attacked the problem a little and before submitting any patches/proposals to Gentoo bugzilla I'd like to know your opinions first. Disclaimer: for daily use I have LANG=pl_PL.UTF-8 and LC_ALL=pl_PL.UTF-8, but the original issue is of a more universal nature. Back on subject. ISO-8859-* 8-bit encodings are fine and most localized manuals use them. However, there are some examples where UTF-8 manuals are installed as well. Namely, newest portage uses linguas_pl by this means: $ emerge -pv portage [ebuild R ] sys-apps/portage-2.1_rc3-r3 USE=-build -doc LINGUAS=pl In effect, a translated manual pages are added to the system. The problem is that they use UTF-8 encoding. Having both man-pages-pl and this version of portage installed gives unexpected results. This way man ls prints all the letters with correct encoding, but man emerge does not. On the other hand, if man is configured to display UTF-8 encoded manuals correctly, all the other manuals print funny characters instead of desired output. I wrote a simple script [1] which checks all installed Polish manuals by using file program. For pl locale it produces currently about ~70kB of text, and for default locale it's about 458kB. After grepping for all occurences of UTF I've found out that only the newest portage's manuals are in UTF-8 (pl), plus: flow.1, gnome-keyring-manager.1, ImageMagick.1, Encode::Unicode::UTF7.3pm (but I think they are false positives, anyway). While it's easy to contact Polish translators of the portage's manuals so they could correct them, the problem will have to be solved sooner or later. UTF-8 encoded manuals will probably occur with higher frequency, and some general resolution should be made. After some discussion on the Polish forum [2] I've learnt about groff deficiencies with UTF-8 handling. However, a wrapper exists [3] that helps somewhat in that matter. But it also requires that all manuals be unified wrt. encoding: *all* ISO-8859-* or *all* UTF-8, no compromise. So I don't know what course to take. Summing up: * UTF-8 manuals: good or bad? * how to handle mixed encodings of manuals? * should man and/or groff handle UTF-8 better? * should an eclass function be created to aid in correcting the encoding of manual pages while installing them? Any constructive comments are more than welcome! Best regards, Wiktor Wandachowicz (SirYes) [1] http://ics.p.lodz.pl/~wiktorw/gentoo/checkman [2] http://forums.gentoo.org/viewtopic-p-3352287.html [3] http://hoth.amu.edu.pl/~d_szeluga/groff-utf8.tar.bz2 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Monthly Gentoo Council Reminder for June
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday once a month), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] UTF-8 encoding and file format of manuals
Wiktor Wandachowicz wrote: Summing up: * UTF-8 manuals: good or bad? The Only Way To Go (tm), IMHO. Let's let the legacy encodings die in piece. Any constructive comments are more than welcome! The very same problem exists with man-pages-cs (which are outdated as a bonus). Blésmrt, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UTF-8 encoding and file format of manuals
On Thursday 01 June 2006 20:19, Jan Kundrát wrote: Wiktor Wandachowicz wrote: Summing up: * UTF-8 manuals: good or bad? The Only Way To Go (tm), IMHO. Let's let the legacy encodings die in piece. Would it be possible to do automatic detection and unicode conversion in the portage install stage? I think that would probably be the best option. At a later stage a simple detection and warning might be sufficient. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpvYNvUxbnsw.pgp Description: PGP signature
Re: [gentoo-dev] UTF-8 encoding and file format of manuals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul de Vrieze wrote: On Thursday 01 June 2006 20:19, Jan Kundrát wrote: Wiktor Wandachowicz wrote: Summing up: * UTF-8 manuals: good or bad? The Only Way To Go (tm), IMHO. Let's let the legacy encodings die in piece. Would it be possible to do automatic detection and unicode conversion in the portage install stage? I think that would probably be the best option. At a later stage a simple detection and warning might be sufficient. Paul I'd agree. Forcing UTF-8/unicode on those of us who don't want the extra bloat is a bad thing -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEfzzQ0K3RJaeXx6cRAkvSAKDiWDgXOa6dhure8BtZhcTqBBZe8wCg0QDe LPmaxvgfz3uchjwjtRRb9uw= =gH7U -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
Paul de Vrieze wrote: [Thu Jun 01 2006, 02:44:39PM CDT] I would like the council to discuss GLEP 49 as has been discussed on the list some weeks ago. It is about the package manager requirements. Incidentally, I drafted a competing GLEP that I posted to -dev ([EMAIL PROTECTED]) that was either overlooked in the rest of that thread or ignored because people considered it to be useless; I'm not sure which. In any event, I just want to bring it to the council's attention as an alternative approach. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 GLEP: xx Title: Supporting alternative package managers Version: $Revision: 1.3 $ Last-Modified: $Date: 2005/11/13 17:16:50 $ Author: Grant Goodyear [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 22-May-2006 Abstract To support alternatives to the official package manager (portage, at the time of this writing), some sane ground rules need to be set. Specifically, no alternative ebuild-based package manager may be added to the tree unless it successfully works with all ebuilds supported by the official package manager. Moreover, no ebuilds may be added to the tree unless they are supported (without change) by the official package manager. Specification = * No alternative ebuild-based package manager may be added to the tree unless it successfully works with all ebuilds supported by the official package manager. If an alternative package manager is runtime incompatible with the official package manager, then it must be masked and provide appropriate warnings. * No ebuilds may be added to the tree unless they are supported (without change) by the official package manager. Rationale = The first rule sets a reasonable bar for adding an alternative package manager to the tree. Note that if an ebuild currently in the tree doesn't work with the official package manager, it isn't expected to work with an alternative package manager either. The second rule ensures that an alternative package manager cannot become a de-facto requirement by supporting packages that the official package manager cannot handle. In order to keep this proposal as simple and focused as possible, it has nothing to say about the process by which an alternative package manager might one day become the official package manager. It is assumed that sanity will reign, and no package manager will become official without being able to build installation media, providing a transition path from or to the existing official package manager, etcetera. Backwards Compatibility === Pretty much the whole point, and it's explicit here. Copyright = This document has been placed in the public domain. pgpZbopQvTPXT.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
On Thu, Jun 01, 2006 at 03:00:13PM -0500, Grant Goodyear wrote: Paul de Vrieze wrote: [Thu Jun 01 2006, 02:44:39PM CDT] I would like the council to discuss GLEP 49 as has been discussed on the list some weeks ago. It is about the package manager requirements. Incidentally, I drafted a competing GLEP that I posted to -dev ([EMAIL PROTECTED]) that was either overlooked in the rest of that thread or ignored because people considered it to be useless; I'm not sure which. In any event, I just want to bring it to the council's attention as an alternative approach. Realize you'ure after keeping it open, but there is more to the tree then just ebuilds- 1) what sparked it all: profiles 2) metadata/glsa, 3) version ordering between ebuilds (is 1.06 greater then 1.051? Answer might surprise you ;) Etc- potential food for thought... ~harring pgpZE7KJRkhwA.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
On Thu, 1 Jun 2006 14:10:04 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, Jun 01, 2006 at 03:00:13PM -0500, Grant Goodyear wrote: Paul de Vrieze wrote: [Thu Jun 01 2006, 02:44:39PM CDT] I would like the council to discuss GLEP 49 Incidentally, I drafted a competing GLEP Realize you'ure after keeping it open, but there is more to the tree I would like the council to nail down the details of what package manager specific data can and cannot be put in gentoo-x86 as well as what the requirements and process of replacing or providing an alternative to portage will be. Getting the specifics down in writing will avoid a lot of headaches down the road as non-portage package managers mature. There are a lot of sides to this discussion, almost all of the possible view points were expressed on [EMAIL PROTECTED] All of it is available in the mailing list archives for review, so I'm also asking that the subscribers to [EMAIL PROTECTED] please refrain from starting another flamewar. -tcort pgpInSj1J2hlr.pgp Description: PGP signature
Re: [gentoo-portage-dev] portage-2.1 and gentoolkit-0.2.2
On Wed, 2006-05-31 at 18:20 -0400, Ned Ludd wrote: Things can be fast tracked if it's better for the overall health of the tree. The 30 thing is just a general guideline and more so before we had any arch teams/ATs/etc... Now that we have arch teams the QA/stable process has been highly improved. On Wed, 2006-05-31 at 14:49 -0500, Paul Varner wrote: If portage-2.1 is requested to be marked stable before then, we need to also make the same request for gentoolkit, so that we don't break it. I don't think that we need to fast track marking gentoolkit-0.2.2 stable at this point. However, as my last paragraph states, if portage-2.1 is going to go stable before then, we should then fast track gentoolkit. Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list