Re: [gentoo-dev] et_EE locale and language of error messages
On Wednesday 24 May 2006 07:42, Jakub Moc wrote: Please, make portage spit out the errors in English by *default* to not waste people's time. If someone insists on overriding it, then let them do it in make.conf and where do you propose we document said override ? in the locale guide ? then the only we've accomplished is making users set the samething in two different places or perhaps we obscure it in a manpage (or even better, dont document it at all) ? then we field bugs/forums/mailing lists with confused users who cant get portage output in their native language just get Chris White to update his little bugzilla document with some steps on how to get english output and we close bugs as NEEDINFO telling them to review the document and open with the proper information -mike pgp4t9lLI3ejE.pgp Description: PGP signature
[gentoo-dev] Future of tetex
This is status report from the TeX department of text-markup, which I find necessary due to partly sad, partly exiting news :) So if you don't care about TeX you may skip this post. The sad news first: A couple of days ago Thomas Esser (the te in teTeX) announced[1] that he wont make another release of teTeX, ever. The reason behind this is that the the source part of teTeX (the source for the binaries) is included in the TexLive[2] and is maintained there. A second reason is that it takes to much of his time to prepare a release. This is sad because teTeX always has been a very stable (if you consider the mess a TeX distribution normally is). There is a reason why teTeX has been the default TeX distribution on almost every flavor of Linux. But it also means that we (Gentoo) should make the transition to TeXLive (Debian is doing the same thing, and possible many other distributions). But that leaves us with several problems/questions which needs to be solved/answered (see below). Now for the exiting (but time consuming) news: The road to a stable TeXLive in Gentoo: 1. Stabilize tetex-3.0_p1[3]. We are almost done, there are very few real bugs left, and tetex-3.0_p1 is already much more stable than tetex-2 ever was. I hope this will happen in the next month. 2. Transform _all_ the dev-tex packages which currently installs into /usr/share/texmf to install into the newly introduced /usr/share/texmf-site. This solves a lot of problems for users which currently are stuck with old versions of e.g. latex-beamer (due to file collisions if installed in /usr/share/texmf[4]). But this requires figuring out how to resolve deps, since many tex packages is included in the texmf-tree installed with tetex and also has its own package in dev-tex. We are currently considering using the same approach as with the perl packages (using new-style virtuals), but I guess thats on hold until it is okay to introduce additional new-style virtuals? 3. Create a TeXLive ebuild and put it onto ~arch and have ~arch user switch over. This requires us to figure out how to create a texmf-tree. In the past Thomas Esser created a very solid (although containing rather old versions) texmf-tree with packages taken from ctan[5]. There are several possibilities: 3.1 Create our own texmf-tree (can largely be automated by scripting). 3.2 Use MikTeX package manager[6] which was ported to Linux. 3.3 Use something similar to the g-cpan.pl script used by perl, to install packages from ctan[7]. I haven't evaluated the possibilities yet, but comments are more than welcome! 4. Mark TeXLive stable and kick teTeX from the tree. Here we are talking at least a year into the future (unless text-markup suddenly gets flooded by new devs). In the process of creating a TeXLive ebuild I am thinking about making it much more modular (which seems to be _the_ buzz word at the moment :) At least I would like to split the TeX source and texmf-tree into separate ebuilds (no matter what the texmf-tree might look like, see above). Other possibilities are creating separate ebuilds for most of the TeXLive distribution, like pdftex, kpathsea, dvipdf*, ... This would make it much easier for us to locate bugs and fix them, but requires much more initial work (this actual resembles the creation of our own TeX distribution). Comments, suggestions, offers of help, anything would be useful :) Martin Ehmsen 1: http://article.gmane.org/gmane.comp.tex.tetex.general/1226 2: http://www.tug.org/texlive 3: https://bugs.gentoo.org/show_bug.cgi?id=124511 4. https://bugs.gentoo.org/show_bug.cgi?id=94815 5: http://www.ctan.org 6: https://bugs.gentoo.org/show_bug.cgi?id=110494 7: https://bugs.gentoo.org/show_bug.cgi?id=85411 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Future of tetex
On Friday 26 May 2006 13:02, Martin Ehmsen wrote: We are currently considering using the same approach as with the perl packages (using new-style virtuals), but I guess thats on hold until it is okay to introduce additional new-style virtuals? As long as the name does not clash with the name of the package (perl prefixes the names with perl-) you are fine, so if you have virtual/tex-latex-beamer you should be fine :) I would support this approach btw, especially if you're going with a split way to add TeX sources, as seems more finegrained :) Comments, suggestions, offers of help, anything would be useful :) Count on me for testing, and for ~amd64 and ~x86-fbsd marking when needed ;) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp9Wj0DJFpid.pgp Description: PGP signature
Re: [gentoo-dev] [ANNOUNCE] New eselect modules for blas, cblas, lapack
Hi Donnie, Am Freitag, 26. Mai 2006 05:20 schrieb Donnie Berkholz: With great pleasure, I announce the testing release of new eselect modules for BLAS, CBLAS and LAPACK implementations. You may say, But we already have 'eselect blas' and 'eselect lapack,' Donnie! What are you thinking? In reply, I would say, The current eselect modules have many limitations. And rightfully so! :-) Thanks for all your efforts here, it is really appreciated. One of the main problems with the existing setup is that available implementations are hardcoded into the modules rather than being autodetected from the system. This just doesn't scale well, and it ties upgrades and changes to BLAS/LAPACK/whatever into a required update of eselect. A point of disagreement between Danny van Dyk (Kugelfang) and myself is handling systems with multiple libdirs (e.g., AMD64). To understand our quandary, you'll first need to understand how the new modules work. My opinion is that if you want to switch implementations, you should be warned if any available libdir failed to switch to the implementation you selected. The tradition of Unix tools says they should be silent when everything works as expected and be loud on errors. Right, emphasis on error here. Not switching for all libdirs when you explicitly said you wanted to switch your whole system is an error, even if the implementation isn't currently available for all your libdirs. Anything else will require adding hackish special cases to the code and doesn't fit with my model of how the modules should work. See, i don't see the explicity of 'all libdirs' when not specifying any libdirs at all. In my eyes, 'eselect blas set acml' doesn't mean: 'switch to acml in _all libdirs_', but 'switch to acml in _all libdirs it is installed to_. Danny thinks instead that the modules should list all libdirs for which the implementation was changed rather than warn about libdirs for which it wasn't. This opposes the Unix philosophy. Danny also thinks that the modules should silently fail when no implementations are available for a certain libdir when the user wants to switch the whole system. I disagree and think the modules should warn the user. In addition, Danny brings up a specific subprofile on amd64 called no-symlink, in which lib32, lib, and lib64 are all directories rather than symlinks. He says the 'lib' directory is only for arch-independent (ABI-independent) files, so we should also add a special case for that. Knowing my hatred of special casing, you may guess I disagree. Motivation for this special casing is, that this warning would appear any time the user doesn't specify the libdirs, and there is nothing the user can do against it. There just is no way to install any blas/cblas/lapack implementation to /usr/lib on no-symlink profile. I'm strongly against warnings that can't be turned off. Futher, this would be no additional special case, it can easily be merged with the previous special casing: only swithch on libdir that the package is installed to. The main issue needing resolution is whether to warn on failures to switch given libdirs when trying to switch the whole system, or whether to say which successfully switched. One way is the Unix philosophy, and the other way is ... something else. :-) Without further ado, you may get all the ported BLAS/CBLAS/LAPACK implementations as well as the new eselect modules from my overlay [1]. They will remain there until more widespread testing is completed. Donnie: RFC: should ACML be modified to install both ABIs? (i.e. x86 and amd64). I'd say no, as no packages but glibc/gcc/binutils currently do that. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] tiny manpage fix
On Thu, 25 May 2006 21:57:30 -0400 Alec Warner [EMAIL PROTECTED] wrote: Attached is a tiny diff for make.conf, can someone with l337 skills in manpages look it over before it gets commited. Easiest way to check how a man page looks is to do: nroff -man raw man page | less -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] tiny manpage fix
On Fri, 26 May 2006 02:28:44 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 26 May 2006 02:27, Kevin F. Quinn wrote: On Thu, 25 May 2006 21:57:30 -0400 Alec Warner [EMAIL PROTECTED] wrote: Attached is a tiny diff for make.conf, can someone with l337 skills in manpages look it over before it gets commited. Easiest way to check how a man page looks is to do: nroff -man raw man page | less huh ? how is that easier than `man ./make.conf.5` :} that's what I get for growing up on SunOS (where that doesn't work) -- Kevin F. Quinn signature.asc Description: PGP signature
