Re: [gentoo-dev] What's the use of mozilla-launcher?
Alexander Skwar [EMAIL PROTECTED] writes: [...] loaded. Instead of http://www.spiegel.de/wirtschaft/0,1518,447923,00.html it would load http://www.spiegel.de/wirtschaft/0,1518,447923. Reason is, that firefox executes mozilla-launcher which will eventually run mozilla-xremote-client openURL($u). The problem with that is, that openURL accepts two parameters and they are seperated with a ,. So it sees two parameters: http://www.spiegel.de/wirtschaft/0,1518,447923 and That would be very hackish if that's what the intention there really is. There's now a patch added to this bug, but I actually object this patch. This patch replaces , in the parameters with %2c (%2c = ,). At a first glance, this patch seemed somewhat fine. URLs with ')' in them are also problems for mozilla-launcher. I'd like to suggest, that mozilla-launcher is no longer a dependency of firefox and is no longer used, as I fail to see, what advantages m-l brings. I'd be interested to hear what its purpose is exactly. -- Matthew Kennedy Gentoo Linux Developer (Public Key 0x401903E0) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Scheme herd team needs some love
No one is working on the Scheme herd in Gentoo. [EMAIL PROTECTED] includes only me, but I'm not doing anything with Scheme and don't really care to either. Several of our Scheme implementations in Portage are out of date, (chicken, gambit, drscheme, bigloo and, dare I mention, guile). There are new ebuilds languishing in bugzilla which have yet to be added to Portage (scheme48, elk, tinyscheme. There are several bugs for build failures and dependency problems. If you have an interest in Scheme and the Gentoo project, I encourage you to go through the new developer process and start maintaining these Scheme ebuilds. Matt -- Matthew Kennedy Gentoo Linux Developer (Public Key 0x401903E0) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] RFC: replacing the common-lisp-controller
I'm considering replacing the common-lisp-controller system in Portage with and opt-in, asdf-binary-locations approach. The main purpose of the c-l-c is to provide a way to compile the source in /usr/share/common-lisp to a user read/writable location (currently the c-l-c uses /var/cache/common-lisp-controller/...). The c-l-c also provides a way to register and unregister Common Lisp implementations provided that each implementation comes with the c-l-c support (usually a install-clc.lisp and a driver script for installation under /usr/share/common-lisp/bin). It also provide a way to register user sources (by creating a symlink from the user's source into ~/.clc). The perceived[1] problems with the c-l-c are that it is too intrusive, makes debugging hard for upstream authors when problems arise and it is not well understood. I'm proposing that we replace the c-l-c with a light weight system based on asdf-binary-locations[2]. Each Common Lisp implementation we support would be essentially a vanilla build of upstream -- nothing saved into the Lisp image. Common Lisp library ebuilds (those that start with cl- in the dev-lisp category) would record the pathname where the Common Lisp system definition is installed. eg. /usr/share/common-lisp/source/cl-ppcre/ The list of pathnames would be saved in, say, /etc/asdf-source.list (one per line perhaps) and be CONFIG_PROTECT'd as usual. If the user intends to make use of the dev-lisp/cl-* ebuilds in Portage, they would include a short stub of Gentoo-provided code in thier implementation initialization file (eg. ~/.sbclrc, ~/.clisprc etc.) to add each of those recorded paths to ASDF:*CENTRAL-REGISTRY*. They would then configure and load asdf-binary-locations from their initialization file in order to direct compilation output to their user read/writable location (eg. ~/.fasls/). Natually there will be a Gentoo Guide XML document for these details. I think this scheme is more in line with our Emacs approach in portage. This has been a popular system for those who want a distro-maintained Emacs build but want to use their own configuration. We install Emacs libraries to /usr/share/emacs/site-lisp and maintain a /usr/share/site-lisp/site-gentoo.el with the Gentoo provided initialization code. This way users are not forced to use the Gentoo configuration -- in fact, you have to opt-in in Emacs' case by loading /usr/share/emacs/site-lisp/site-gentoo.el from your ~/.emacs. Footnotes: [1] from comp.lang.lisp and freenode.net #lisp [2] http://common-lisp.net/project/cl-containers/asdf-binary-locations/ -- Matthew Kennedy Gentoo Linux Developer (Public Key 0x401903E0) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Announcing The Gentoo Common Lisp Project
See: http://www.gentoo.org/proj/en/common-lisp/index.xml A new project has been created to coordinate users and developers in the development of Common Lisp related software in Portage. Currently there is a * Project Page * Portage Overlay (Darcs) * Mailing List We hope users will contribute to our Darcs overlay instead of simply filing bugs. -- Matthew Kennedy Gentoo Linux Developer (Public Key 0x401903E0) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a new TLP to unify programming langiages?
George Shapovalov [EMAIL PROTECTED] writes: [...] What I propose is to create a TLP page for Gentoo Programming Resources (or pick your name) and move all the individual languages into the subdirs of it. Any opinions? If I get any yay's or no nays I'll create a bug about it and then we can finalize the layout there.. I think this proposal is OK even it is just to organize the top level listing a bit better. It seems like a real mix right now -- Council next to Common Lisp, PR next to Python and so on etc. (I just like to keep the trace of what is being done and the related discussions). The principal list of individual TLPs (as they stand now) is below: Common Lisp eselect java perl php python Ada -- to be added I'm surprised to see you've listed eselect in there. Isn't that more of a system tool? PPS We could add principal divisions there, like Languages Tools whatever_else I think this would be too deep a hierarchy. -- Matthew Kennedy Gentoo Linux Developer (Public Key 0x401903E0) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Proposal for a global xinetd USE flag
Currently we have the following local xinetd USE flags. The semantics of xinetd in each case are roughly the same: dev-db/firebird:xinetd - If you want inetd version instead of a superserver (daemon) net-ftp/proftpd:xinetd - Enable support for starting from xinetd net-ftp/vsftpd:xinetd - Add support for running under xinetd net-im/bitlbee:xinetd - Install an xinetd.d file for bitlbee net-mail/qpopper:xinetd - If you want inetd version instead of standalone net-misc/linux-identd:xinetd - Use xinetd instead of the initscript net-misc/rsync:xinetd - Install an xinetd.d file for rsyncd net-proxy/ziproxy:xinetd - If you want inetd version instead of a superserver (daemon) The following ebuilds installed xinetd configuration on my machine even though I don't have xinetd installed. [EMAIL PROTECTED]:~$ equery belongs /etc/xinetd.d [ Searching for file(s) /etc/xinetd.d in *... ] dev-util/subversion-1.3.2-r1 (/etc/xinetd.d) dev-util/cvs-1.12.12-r3 (/etc/xinetd.d) net-misc/netkit-fingerd-0.17-r2 (/etc/xinetd.d) net-print/cups-1.2.1-r2 (/etc/xinetd.d) RFC. Matt -- Matthew Kennedy Gentoo Linux Developer (Public Key 0x401903E0) -- gentoo-dev@gentoo.org mailing list
