Re: [arch-general] [signoff] lvm2/device-mapper 2.02.82-1
Excerpts from Thomas Bächler's message of So Jan 30 21:45:28 +0100 2011: > Am 27.01.2011 14:30, schrieb Thomas Bächler: > > Am 27.01.2011 11:35, schrieb Jan Spakula: > >>> This is weird. I think lvm2 is supposed to wait for udev to finish > >>> creating all links before returning. Inserting a 'sleep 1' or > >>> '/sbin/udevadm settle' in rc.sysinit after the vgchange call should fix > >>> this, but it shouldn't be necessary. > >> > >> Inserting 'sleep 1' after 'activate_vgs' (new initscripts) does indeed save > >> the day. I don't know how to figure out why in my case lvm2 doesn't wait > >> for > >> udev... Any suggestions for further testing welcome. > > > > I thought so. (I guess this issue stays the same in the new initscripts.) > > > > I suppose this must be a bug in the device-mapper - the udev integration > > is supposed to wait for symlink creation before returning. > > Could you try with the device-mapper and lvm2 packages from here? This > should fix your problem. Thanks. > https://dev.archlinux.org/~thomas/lvm_fix/ I booted a couple of times with your packages and the problem didn't show up yet (without 'sleep 1' of course). Btw I do have udisks installed. Thanks!
Re: [arch-general] [RFT] initscripts 2011.01-1
Excerpts from Heiko Baums's message of Do Jan 27 14:23:25 +0100 2011: > Am Thu, 27 Jan 2011 11:50:31 +0100 > schrieb Jan Spakula : > > > Another slight annoyance comes from the lines (from rc.sysinit) > > > > # isLuks only gives an exit code but no output to > > # stdout or stderr. > > if $CS isLuks "$2"; then > > open=luksOpen > > a="$2" > > b="$1" > > fi > > > > It's not true that there's no output; I get the message > > "Device /dev/vg/swap is not a valid LUKS device." > > every time I boot :) > > But this is the output on the console. For those if clauses you need a > boolean (true or false resp. 0 or 1) and this is not given by > cryptsetup isLuks. This value is only given as an exit code. So this > part of the script is absolutely correct and the only way to handle > this. I like clause with exit codes much better that any funky checking for a message ;) I was addressing the comment in the script that it "..gives no output"; silently suggesting to explicitly silence the cryptsetup call, so that no unnecessary messages are displayed during booting. Jan
Re: [arch-general] [RFT] initscripts 2011.01-1
Excerpts from Thomas Bächler's message of Do Jan 27 14:04:12 +0100 2011: > Am 27.01.2011 11:50, schrieb Jan Spakula: > > Excerpts from Thomas Bächler's message of Mi Jan 26 18:34:22 +0100 2011: > > https://projects.archlinux.org/initscripts.git/commit/?id=c1f38e1186a60a2d63947881d2879c22fc375da4 > > https://projects.archlinux.org/initscripts.git/commit/?id=f4703f832e6d8578c52dd8a71b9bf34894fe3d34 > > Please try these two trivial patches. They should fix your issues > (revert your crypttab back to the previous format). Yep, these solve the issues. Thanks and sorry the hassle. Jan
Re: [arch-general] [RFT] initscripts 2011.01-1
Excerpts from Thomas Bächler's message of Mi Jan 26 18:34:22 +0100 2011: > Okay, this has been sitting in git for a lng time, and I am throwing > it out there. This should receive lots of testing, as there has been > major rewriting done. We need to make sure there are no regressions. It > should also fix a small number of bugs. > Rewrite /etc/crypttab processing. I've found a small issue coming from this: the "fourth column" (options) in /etc/crypttab used to mean "everything beginning with the 4th column to the end of the line", apparently now it is required to put the whole expression within "..". For instance I have some parameters in the SWAP line, I had to change the line swap /dev/vg/swap SWAP -c aes-xts-plain -h sha256 -s 256 to swap /dev/vg/swap SWAP "-c aes-xts-plain -h sha256 -s 256" In the first case, the cryptsetup call during sysinit fails, since only '-c' was used as a parameter and the call 'cryptsetup -d /dev/urandom -c create ...' didn't make sense to cryptsetup. Another slight annoyance comes from the lines (from rc.sysinit) # isLuks only gives an exit code but no output to # stdout or stderr. if $CS isLuks "$2"; then open=luksOpen a="$2" b="$1" fi It's not true that there's no output; I get the message "Device /dev/vg/swap is not a valid LUKS device." every time I boot :) Do you want me to file a bug?
Re: [arch-general] [signoff] lvm2/device-mapper 2.02.82-1
Excerpts from Thomas Bächler's message of Mi Jan 26 16:29:43 +0100 2011: > Am 26.01.2011 11:38, schrieb Eric Bélanger: > > On Wed, Jan 26, 2011 at 3:33 AM, Jan Spakula wrote: > >> Excerpts from Eric Bélanger's message of Mi Jan 26 05:16:44 +0100 2011: > >>> lvm2/device-mapper 2.02.82-1 are in testing for minor upstream update. > >>> Please test and signoff. Users signoffs are welcome. > >> > >> Hi, I have problems with both 2.02.81 and 2.02.82: > >> I have encrypted root (normal partition) + some extra encrypted partitions > >> on > >> lvm via crypttab. The ones in crypttab don't unlock, the error message is > >> something along the lines of "... /dev/vg/swap doesn't exist or access > >> denied" (it gets overwritten immediately, so I don't see the beginning of > >> the > >> message). This is right after lvm2 hook is run. > >> Then a bit later in the emergency shell, the /dev/vg/* links are already > >> there; so perhaps there's some extra delay until the symlinks are created > >> in > >> /dev/ with the newer lvm2? > > This is weird. I think lvm2 is supposed to wait for udev to finish > creating all links before returning. Inserting a 'sleep 1' or > '/sbin/udevadm settle' in rc.sysinit after the vgchange call should fix > this, but it shouldn't be necessary. Inserting 'sleep 1' after 'activate_vgs' (new initscripts) does indeed save the day. I don't know how to figure out why in my case lvm2 doesn't wait for udev... Any suggestions for further testing welcome.
Re: [arch-general] X fails to start with intel card after latest kernel update
Excerpts from David C. Rankin's message of So Okt 11 10:16:57 +0200 2009: > On Sunday 11 October 2009 03:10:15 am David C. Rankin wrote: > I'm back already. The wiki page must be out of date. It says to put the > following in modprobe.conf (which is deprecated): > > options i915 modeset=1 > > Now what?? Put it in /etc/modprobe.d/modprobe.conf (that's where I have it).
Re: [arch-general] outdated packages
Excerpts from Juan Diego's message of Do Okt 08 07:12:55 +0200 2009: > is it possible to have something similar for core, extra and community repos? There is a 'flag package out of date' link to click for core, extra and community repo packages when you view the package on the main website.
Re: [arch-general] LaTeX problems ?
Excerpts from Christian Himpel's message of Mo Aug 31 15:32:48 +0200 2009: > On Mon, Aug 31, 2009 at 15:22, Jan Spakula wrote: > > Excerpts from Piyush P Kurur's message of Mo Aug 31 14:48:03 +0200 2009: > > It's possibly the issue that's come up on the forums: > > if you get something like: > > --- > > This is TeX, Version > > Fatal format file error; I'm stymied > > --- > > then you need to run 'updmap --all' (as the user you get this error with). > > Alternatively, you can delete the user's local texlive generated formats 'rm > > ~/.texlive/texmf-var/web2c/*.fmt' (then the system-wide generated formats > > will be used, and they do get regenerated automatically on upgrade). > > i think it's 'fmtutil --all' instead of 'updmap --all'. > you could also run 'fmtutil-sys --all' as root to recreate the > system-wide format files. Eh, of course it's fmtutil. Sorry. However the point is that 'fmtutil-sys --all' *does* get run automatically on texlive upgrade, but if the user has generated the formats themselves at some point, these formats are preferred by texlive regardless of system changes. So the user need to regenerate or delete the local format files. ~
Re: [arch-general] LaTeX problems ?
Excerpts from Christian Himpel's message of Mo Aug 31 15:32:48 +0200 2009: > On Mon, Aug 31, 2009 at 15:22, Jan Spakula wrote: > > Excerpts from Piyush P Kurur's message of Mo Aug 31 14:48:03 +0200 2009: > > It's possibly the issue that's come up on the forums: > > if you get something like: > > --- > > This is TeX, Version > > Fatal format file error; I'm stymied > > --- > > then you need to run 'updmap --all' (as the user you get this error with). > > Alternatively, you can delete the user's local texlive generated formats 'rm > > ~/.texlive/texmf-var/web2c/*.fmt' (then the system-wide generated formats > > will be used, and they do get regenerated automatically on upgrade). > > i think it's 'fmtutil --all' instead of 'updmap --all'. > you could also run 'fmtutil-sys --all' as root to recreate the > system-wide format files. Eh, of course it's fmtutil. Sorry. However the point is that 'fmtutil-sys --all' *does* get run automatically on texlive upgrade, but if the user has generated the formats themselves at some point, these formats are preferred by texlive regardless of system changes. So the user need to regenerate or delete the local format files.
Re: [arch-general] LaTeX problems ?
Excerpts from Piyush P Kurur's message of Mo Aug 31 14:48:03 +0200 2009: > complaint was that they are not in the correct format. So I guess > the following needs to be done. > > 1) Add libpoppler as a dependency to latex you are right about this. > 2) recompile libpoppler with latest gcc which ever it is. this is what I don't understand: you write "they are not in the correct format" - who is they? which program complains? It's possibly the issue that's come up on the forums: if you get something like: --- This is TeX, Version Fatal format file error; I'm stymied --- then you need to run 'updmap --all' (as the user you get this error with). Alternatively, you can delete the user's local texlive generated formats 'rm ~/.texlive/texmf-var/web2c/*.fmt' (then the system-wide generated formats will be used, and they do get regenerated automatically on upgrade).
Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings
Excerpts from Loui Chang's message of Mo Jun 22 16:41:41 +0200 2009: > > Is there a way for him to try the new 'dmraid' without going the whole > > way and migrating to [testing]. This would also be useful for him > > (and me) to know. > > Pretty simple. Enable testing, install dmraid, disable testing. > Then your testing is limited to those packages only. While this works fine most of the time, when you run into problems and ask about it here or on the forums, the first thing that people tell you is: "you should either use [testing] all the way or not at all, since any particular package in [testing] might crucially depend in some other packages in [testing], and they don't get updated when you only update one particular package." Anyway, I still think it's a good idea to search the MLs and forums before asking for help here. Big chances are someone has already noticed/the change was announced in the dev ML.
Re: [arch-general] [arch-dev-public] Kill old gcc versions
Excerpts from Baho Utot's message of Mo Jun 15 03:14:10 +0200 2009: > I can do thatif you can stand all the bug reports :) I hope you understand that the problem is with upstream (if the package won't compile because the source is not standards compliant), so it should be reported there and not on arch's bugtracker.
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
Excerpts from Andrei Thorp's message of Mi Jun 10 23:02:39 +0200 2009: > - Xmonad and Awesome are both initally based on DWM, though both of > them now have almost none of that original code left due to it being > not actually that great (plus the wms changed a lot) Just to crush the urban myth that gets mentioned more than it should be recently: xmonad is not based on dwm. Yes, the idea of what should it do came from dwm, but it was written from scratch (in haskell, no C code ever).
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
Excerpts from Attila's message of Fr Mai 29 17:42:23 +0200 2009: > And still again i suggest to take a look at other distros where daemons get > restarted without a problem during a upgrade procedure. Sorry, but i find > this rule of "don't restart during the upgrade" a little bit academically.-) For me it's about 'expectations'. I expect a package manager to manage packages (unpack a new one over the old one in a sensible manner) and don't expect it to decide what's best for me in terms of what's running or not. I still find it 100% better to *let me know* that config might have changed (pacman does this automatically) and that something might need to be done if, say, I run this and that daemon. Don't run it for me. And if you absolutely have to, *let me know*. -- Jan
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
Excerpts from ludovic coues's message of Do Mai 28 17:09:52 +0200 2009: > A solution in pacman, getting rid of user adding in .install script, > can allow security like asking user to confirm creation of group and > user. > > This would be a secure way of doing thing, and users/admin would be > aware of new user/group. I don't get how is adding/removing users/groups from pacman directly safer then doing the same from the install script. How about just *informing* the user what's happening in the install script? Then there would be no 'unexpected behavior'.
Re: [arch-general] Laptop Install - 2 questions remain, WPA and Compiz with Radeon Driver
Excerpts from David Rosenstrauch's message of Mo Mai 04 19:05:09 +0200 2009: > David C. Rankin, J.D.,P.E. wrote: > > While I'm at it, where can I turn the default attempt to start 'eth0' > > off. > > # Interfaces to start at boot-up (in this order) > # Declare each interface then list in INTERFACES > # - prefix an entry in INTERFACES with a ! to disable it > > INTERFACES=(lo !eth0 eth1) Actually, in the majority of cases you don't need 'lo' interface in INTERFACES, since it's brought up during the boot process (in rc.sysinit), so unless you want to have a possibility of disabling it by bringing down the network daemon (which is rarely desired), you don't need it there. Likewise, the interfaces managed by the netcfg2's net-profiles don't need to be in INTERFACES, otherwise you might get some undesired behavior (like taking the wireless interface down when shutting down the network daemon). In fact, the network daemon and the net-profiles daemon are independent. So if you only use your wireless interface and use net-profiles for it, you can disable the 'network' daemon altogether. Best, Jan
Re: [arch-general] Laptop Install - 2 questions remain, WPA and Compiz with Radeon Driver
Excerpts from David C. Rankin, J.D.,P.E.'s message of So Mai 03 12:11:04 +0200
2009:
> (1) My laptop has an Atheros card and is happily using the madwifi driver.
> The
> only problem is that I'm starting it manually and need to know where to put
> the pieces to have it start automatically. Basically, it takes 3 commands to
> get my wifi going:
>
> ESSID=${1:-skyline}
> IFACE=${2:-wlan0}
>
> iwconfig ${IFACE} essid "${ESSID}"
>
> wpa_supplicant -i${IFACE} -Dwext -c/etc/wpa_supplicant.conf -d -B
> >> /var/log/wpa_start.log 2>&1
>
> sleep 2 # This doesn't count as a command
>
> dhcpcd wlan0
>
> My question is "Where do I put this stuff to make it happen when I start
> Arch??
Install the netcfg package, create a profile under /etc/network.d (there are
some examples, so you shouldn't have any problem), and edit /etc/rc.conf: add
the name of your profile into "NETWORKS=(...)" and add 'net-profiles' to your
DAEMONS.
-- Jan
Re: [arch-general] Bug reports for out of date packages?
Excerpts from hollunder's message of Di Apr 07 13:35:20 +0200 2009: > On Tue, 7 Apr 2009 10:41:00 +0200 > ludovic coues wrote: > > > I suppose that some maintainer are not looking as often as some > > people from the arch's > > community want to there package. > > > > Couldn't be multiple maintainer for package ? > > Some of us (archaudio people) wished that was possible in AUR as well, > simple because it happens that some maintainer is not available for some > time. > This is one reason for our upcoming binary repo, but I'd personally > rather stick with AUR. > > So yeah, is something like this possible for any of the repos? You can do what the arch-haskell group has done: create a new user: archaudio, adopt all the packages that you want to be shared, and share the password :)
[arch-general] fortune-mod packages
I've noticed that all fortune-mod packages (except fortune-mod itself) have been removed from extra (by Eric). Do you plan on uploading them to AUR, or should I just grab PKGBUILDs from svn and upload them myself if I'm interested on maintaining some of them? Thanks, Jan
Re: [arch-general] udev-139 and file permissions of /dev/net/tun
Excerpts from Attila's message of Di Mär 10 18:51:15 +0100 2009: > Hi, > > i use a script to prepare a bridged network for a kvm session and therefore i > have this line in /etc/udev/rules.d/01-attila.rules: > > KERNEL=="tun", NAME="net/%k", MODE="0660", GROUP="network" > > After upgrading udev my file permissions of the new persistent /dev/net/tun > looks so after booting up: > > crw-rw-rw- 1 root root 10, 200 8. Mär 00:43 /dev/net/tun > > I play with this lines in /etc/udev/permissions.d/00-my.permissions: > > a) tun:root:network:0660 > b) net/tun:root:network:0660 > > I reboot even after changing the line but there is no change. If i do > a "modprobe tun" there be the right permissions: > > crw-rw 1 root network 10, 200 8. Mär 00:43 /dev/net/tun > > So my questions is how and/or where can i control the file permissions of the > persistent devices from the new udev? > > This is definitly not bad, i want more to know what i have overseen.-) > > See you, Attila This reminds of a problem Dusty had and discussed on forums: http://bbs.archlinux.org/viewtopic.php?id=60060 Result: the device node was created before the rule was applied. So maybe ... ? Good luck, Jan
Re: [arch-general] [PATCHES] About /var/run/ and /var/lock/ checks in daemons
Excerpts from Jan Spakula's message of Thu Feb 12 09:22:00 +0100 2009: > Excerpts from Jan de Groot's message of Thu Feb 12 08:59:41 +0100 2009: > > On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote: > > > I interested to make Arch Linux suitable for use with a /var/run and > > > /var/lock that are mounted as tmpfs. But this also helps, in the case > > > that not mounted as tmpfs, to make more simple "purge function" for > > > these directories at rc.sysinit step. > > > > > > In my case this is "just for fun!", but other users can be benefited by > > > this, for example "netbook users". > > If this requires patching so many packages, and given the fact > > that /var/run on tmpfs is not default in archlinux, maybe you should try > > building /var/run from an initial directory or something like that. This > > is also what I use for my OpenBSD router which runs from compactflash > > and has /var mounted on ramdisk. > > I have a setup on my netbook where the whole /var is mounted as tmpfs and > rsynced from and to real directory (/var-sync in my case) on boot/shutdown. > Patches to rc.sysinit and rc.shutdown follow. [Note that whenever you update > initscripts, you need to patch at least rc.shutdown before rebooting :)] Well apparently attachments are scrubbed, so here you go http://rafb.net/p/ePKlct55.html http://rafb.net/p/yDQSPc95.html Advantages are mainly on netbooks, which have limited number of writes to their ssd drives, this eliminated a big source of uncontrolled writes.
Re: [arch-general] [PATCHES] About /var/run/ and /var/lock/ checks in daemons
Excerpts from Jan de Groot's message of Thu Feb 12 08:59:41 +0100 2009: > On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote: > > I interested to make Arch Linux suitable for use with a /var/run and > > /var/lock that are mounted as tmpfs. But this also helps, in the case > > that not mounted as tmpfs, to make more simple "purge function" for > > these directories at rc.sysinit step. > > > > In my case this is "just for fun!", but other users can be benefited by > > this, for example "netbook users". > If this requires patching so many packages, and given the fact > that /var/run on tmpfs is not default in archlinux, maybe you should try > building /var/run from an initial directory or something like that. This > is also what I use for my OpenBSD router which runs from compactflash > and has /var mounted on ramdisk. I have a setup on my netbook where the whole /var is mounted as tmpfs and rsynced from and to real directory (/var-sync in my case) on boot/shutdown. Patches to rc.sysinit and rc.shutdown follow. [Note that whenever you update initscripts, you need to patch at least rc.shutdown before rebooting :)]
Re: [arch-general] New 2008.10 archboot test iso/img files
Excerpts from Dominik Schips's message of So lis 01 16:48:15 +0100 2008: > > I tried to setup a archlinux (32bit) with the ISO. > At the step to set a root password the installation always make some > problem. > > I get an error: "chroot: cannot run commant 'passwd' : Exec format > error" Same problem here. The reason is that 'x86_64' is hardcoded into the mirrorlist, so actually everything that gets installed is with wrong architecture. Fixable by editing /etc/pacman.d/mirrorlist. Best, Jan -- Jan
Re: [arch-general] Tool to stop and start services? (Don't Panic)
Excerpts from cave.dnb2m97pp's message of Thu May 22 12:21:16 -0500 2008: > Johannes also suggests this way, and I have no problems with it, but > sometimes > it's just nice to have a list of running services, maybe just to see if there > is some service you don't need, and to be able to stop it. "ls /var/run/daemons" will do. -- Jan
Re: [arch-general] Tool to stop and start services? (Don't Panic)
Excerpts from ert256's message of Thu May 22 10:18:48 -0500 2008: > I found that some time ago, but i don't use this. > http://aur.archlinux.org/packages.php?ID=16966 This is not quite compatible with arch's initscripts. You'd need to rewrite (or at least rearrange) pretty much all the initscripts supplied with arch's packages, if you'd want to use this for the usual services. -- Jan
Re: [arch-general] rdup: orphan request
Excerpts from bash.lnx's message of Mon May 05 18:52:29 -0500 2008:
> 2008/5/6 Jan Spakula <[EMAIL PROTECTED]>:
> > Hello,
> >
> > I would like to ask for rdup in AUR to be orphaned, so that I can
> > maintain it:
> Done
Thanks!
While I see you here, about something I've seen you post a comment
about:
Is it advisable to use "arch=('any')" for packages that are architecure
independent, or was that just a momentary hype some time ago?
--
Jan
[arch-general] rdup: orphan request
Hello, I would like to ask for rdup in AUR to be orphaned, so that I can maintain it: 1) it's out-of-date (version 0.5.2, current 0.5.7; considerable (for me) improvements) 2) the maintainer (dice) has the last appearance in AUR on 1/14/2008 3) he does not respond to comments in AUR and his e-mail address does not work (tried couple of days ago, mail returned as undeliverable). 4) there's a perl dep of this package that needs to be taken care of. Thank you, -- Jan
Re: [arch-general] texlive (again?)
Excerpts from Ján Špakula's message of Tue Apr 22 10:35:22 -0500 2008: > I'll contact the tetex dev (Jason Chu) with a request to add a texlive > info/warning to tetex install script. This change is hopefully small > enough and sensible that it would go through. Filed: http://bugs.archlinux.org/task/10256 If you think that it would help, feel free to vote for it :) -- Jan
Re: [arch-general] texlive (again?)
Excerpts from Thomas Bächler's message of Mon Apr 21 04:45:06 -0500 2008:
> Thomas Bächler schrieb:
> > We could make sure that either these packages depend on a virtual "tex"
> > package that is provided by texlive or make texlive provide tetex.
>
> Ha! texlive-core already provides tetex. Therefore, you can use all
> applications that depend on tetex with texlive instead. This situation
> is good enough for me.
I'm relatively content with the situation as well (with using texlive
and all). [I'm fed up with people bitching about this on the forum, so I
decided to try to bring it up.] The thing is that now people need to
know in the first place that they should/could want to use texlive,
since if they just install something that needs tex, it pulls
automatically tetex. That's essentially the "issue" I'm trying to
address.
I guess a cheap way out which would make me happy would be to at least
add a line saying
"This tex distribution is currently unmaintaned upstream,
there is an alternative (texlive) in the community repo."
in tetex's install script.
Jan
--
Jan Spakula
[arch-general] texlive (again?)
Hello Archers, I want to bring up the TeX distributions issue. Current status: - tetex in extra: unmaintained (upstream) though still usable, some parts are already getting outdated (pdftex, some latex packages); - texlive in community: firmicus keeps it pretty up to date, the dist itself is actively developed. Proposal: Switch to texlive eventually officially (for now keeping tex-related pkgs in community). How it can be done: - from the dev side: 1) "officially" announce that the switch *is* going to happen. 2) move tetex and all packages depending on it from extra to community (that's only: kile, latex2html, lyx, texmacs) (the trouble is that these makedep on tetex: evince, kdegraphics, yodl; but maybe just keep tetex on the build machine for a time being?) - from TUs: 3) gradually replace tetex deps by texlive deps in community packages - from users: 4) gradually replace tetex deps in AUR by texlive Comments: - 3) and 4) don't need to happen instantly - we'll just have 2 tex dists at the same "level" in community for a while - note that none of the above programs link anything against tetex, they just need working tex compiler (which texlive definitely provides), so they don't even need to be recompiled - the official statement is important, so that we can nag maintainers to change dependencies ;) - there's been on/off-going discussion about this on the forums (http://bbs.archlinux.org/viewtopic.php?pid=358172 - tomk has said "Regarding the possibility of bringing texlive into the official repos, there are currently two missing ingredients among the existing dev team: interest and time. AFAIK none of us is a habitual tex user, and that would be the first requirement." - so this proposal asks for the opposite: bring the so far official tetex down to community, to level it out with texlive and make the switch powered by the users possible.) What do *you* think? PS. Sorry for the long e-mail (about 15-times longer than I usually write). -- Jan Spakula
