Re: [gentoo-dev] Maintainer wanted for app-text/wv2
Sune Kloppenborg Jeppesen wrote: app-text/wv2 is without an active maintainer and has an open security bug #136759 https://bugs.gentoo.org/show_bug.cgi?id=136759 Anyone willing to take care of this package in the future, please update metadata/herd info and CC yourself on the bug. This seems like a package that is easy to maintain, and since the security bug is easily dealt with by a version bump and stabilization, I guess text-markup absorbs it. Martin Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Future of tetex
Gabriel Lavoie wrote: Is app-text/texlive usable for now? I only have a basic tetex installation that I will need for my master grade at university and I would want to make the switch to texlive really fast! Maybe I can help? No it is not usable right now, hence the mask :-) The biggest problem (aside from some minor problems with the ebuild) is figuring out how to provide a texmf tree. The texmf tree that ships with the current ebuild is several 100 MB, which I think is too much. I like some way to provide a light, medium and heavy texmf tree. The problem is not making an ebuild but making the tree it self. So if you feel like figuring out which tex packages should go into which of the three trees then I would appreciate it very much! (remember that there are also deps between the packages). Martin Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Future of tetex
Gabriel Lavoie wrote: I suppose for now that the best way to check the texmf tree dependencies is to install TeX Live using the .iso file? I'm not sure I understand your question... The tex packages that should go into the three trees is not necessarily the packages that ships with texlive (the texmf tree that is downloaded with the current texlive ebuild is the same as the one shipped in the .iso file), they could just as well come from ctan (or any other place for that matter, as long as the licenses are clear). So what one should do is go to ctan and figure out the interdeps between packages that goes into the texmf trees. And some of the bigger packages (beamer,...) should _not_ be in the texmf trees, since we want to be able to upgrade those without making a new release of the temxf trees (which forces users to download a large file again). Martin Ehmsen -- gentoo-dev@gentoo.org mailing list
[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] Discussion
Diego 'Flameeyes' Pettenò wrote: On Thursday 11 May 2006 06:44, Mike Frysinger wrote: or because reading GLEP 42 is boooring s/42 /s/ Syntax error! s/ 42/s/ instead. /Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
Diego 'Flameeyes' Pettenò wrote: On Thursday 11 May 2006 14:01, Martin Ehmsen wrote: Syntax error! More than syntax is me who was sleeping. I just meant that it gave a syntax error (after applying your sed) Although I suppose this means we all agree ;) Definitely! Maybe we should propose a new GLEP which requires GLEPs to be fun? :) /Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Maintainer wanted for app-text/pstotext
Sune Kloppenborg Jeppesen wrote: Anyone willing to take care of this package in the future, please update metadata/herd info and CC yourself on the bug. I seems that the text-markup team could absorb this package (seems very related). If no one objects to this, I'll add it to the text-markup herd? (and look at/fix the bug). /Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Improving Gentoo User Relations
Christel Dahlskjaer wrote: On Fri, 2006-04-07 at 10:07 +0100, Ciaran McCreesh wrote: So, from a developer pov Ciaran; if we could come up with some way of keeping up to date with what you guys do (without eating up any of your time or getting in your way) and then keep the masses informed, would that be more attractive? Obviously making sure that information is kept to a not exactly bare minimum, but presented in such a way that it doesn't in any way halt progress or potential change of direction? I would use such a service if one is provided and it is very easy to use (don't take a lot of time). How about a website/blog hosted on www.gentoo.org pr. project and a little tool for posting on such a website (ala echangelog). I don't have the time to set something like that up on my own, but I would use it if it was given to me. I work in text-markup and we don't do much high profile development, but I would like a way to tell users about what we are doing even though it would only mean a post pr. month or so. But if I need to spend time and energy on setting such a thing up, then it will never happen. Just my two cents, Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
Chris Bainbridge wrote: Another thing that some people may not have considered - with many developers using various permutations of overlays, how can you guarantee that what is being checked into the main tree will build for a normal user? In order to test that, a developer would have to disable all overlays, unemerge everything provided by the overlays, and then build and test with a plain non-overlay gentoo. That's a lot of work; I doubt most developers are doing it. You are wrong in my case. I have a vanilla root, which used to be just a chroot, but now i'm trying out vmware, where I test all the changes I make. I think many other devs test in a similar manner (on another box, chroot, ...). /Ehmsen -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] License advice
I'm not sure how to correctly handle bug #87542. It is about a dev-tex package that doesn't have a license (ctan doesn't state one, and no license can be found anywhere else). By definition I have to assume that it is proprietary. But an eager bug reporter has gotten a statement from the two authors, that the package is meant to be public-domain. Should I require a public statement from the authors, like an update version on ctan that states the license, or is it enough to refer to the bug report? (ie., is it enough that the reporter says that the author said the package is public-domain?) -- Martin Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] package.mask cleanups
Alec Warner wrote: Please have a look and see if any of the packages are yours. It would probably be easier if you added the maintainer of each package to the list (it shouldn't be that difficult, but I'm not volunteering :-P). /Martin -- gentoo-dev@gentoo.org mailing list
