TeX Live 2008 available for testing
by Jindrich Novy
Good news everyone!
I've invented a device that installs TeX Live 2008 on your Fedora!
</futurama>
TeX Live 2008 is now packaged and available for testing. It is not in
Fedora yet because it requires reviews of couple of packages. But you
can test it before it happens.
If you want to give it a try, install this package:
# rpm -i http://jnovy.fedorapeople.org/texlive/texlive-release-2008-1.fc11.noarch.rpm
then you can do:
# yum install texlive
if you don't have texlive already installed. While upgrading from
older texlive release please remove all the texlive packages before the
upgrade, especially be sure that the /usr/share/texmf directory is
removed. This is because the famous directory -> symlink upgrade RPM
bug.
The packaging follows upstream packaging metadata so basically you
have the same package naming in upstream TeX Live. The fedora one is
prefixed with the "texlive-*" prefix.
Currently you can use metapackages to install TeX Live:
texlive-scheme-basic
texlive-scheme-context
texlive-scheme-full
texlive-scheme-gust
texlive-scheme-gutenberg
texlive-scheme-medium
texlive-scheme-minimal
texlive-scheme-omega
texlive-scheme-tetex
texlive-scheme-xml
By default when you install TeX Live by "yum install texlive" the
scheme-basic is pulled in.
You can install collections as well, there are 84 of them, list is here:
http://jnovy.fedorapeople.org/texlive/collections
You can install the individual packages as well, complete list is here:
http://jnovy.fedorapeople.org/texlive/pkgs
For more information you can see the Feature page here:
http://fedoraproject.org/wiki/Features/TeXLive
I've put a lot of effort to reduce the total amount from ~4000 to the
current ~1600 source RPMs that need to be reviewed and imported into
Fedora. This is not an easy task but considering that all (except
the main one) of them are automatically generated it could be
possible.
Note that it is in testing state so (many) bugs could occur. There are
possible clashes with applications packaged separately (such as
dvipdfmx, etc.) so we may want to discuss these conflicts with
respective fedora package maintainers to fix them. In case you are a
maintainer of such package please send me an email to jnovy(a)redhat.com
so that we can sort it out on the TeX Live side (packages maintained
separately are preferred).
Thanks,
Jindrich
--
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
14 years, 9 months
(A)synchronous file operations & xdg-open
by Jerry James
This came up in https://bugzilla.redhat.com/show_bug.cgi?id=472402 but
is worth a more general discussion amongst the developer community, I
think.
The xdg-open tool is generally a good thing for the users, but at
least a couple of cases have arisen where it is not doing the right
thing. The problem seems to be that there are two modes of operation
that are wanted.
(1) Launch a tool that can display a persistent URL. This can be
asynchronous, since the object identified by the URL isn't going away.
(2) Launch a tool that can display or edit a temporary file. This
must be synchronous, since the entity that created the temporary file
needs to read it after it is edited, and remove it in either case.
xdg-open is being used for both cases. Some of the tools it invokes,
such as gnome-open, operate in mode 1 and some (kfmclient?) in mode 2.
When a mode 1 tool is used in a situation that demands a mode 2 tool,
bad things happen (see also
https://bugzilla.redhat.com/show_bug.cgi?id=435107).
It appears to me that we either need to split xdg-open into two tools,
representing the two modes of operation, or else give xdg-open a
command-line switch to demand synchronous operation. We also need to
figure out which tools it invokes that operate in mode 1 and find mode
2 equivalents for them. What do you think?
--
Jerry James
http://www.jamezone.org/
14 years, 9 months
Raising the bar
by Matthias Clasen
Hey all,
we'd like to announce the 'Fit and Finish' initiative for Fedora,
http://fedoraproject.org/wiki/Fit_and_Finish
with the goal to improve the user experience of the Fedora desktop. We
want to identify the small (and sometimes large) roadblocks that make
everyday computer use harder than it needs to be, and try to fix them.
'Fit and Finish' is meant to be complementary to the work of the Fedora
QA team. They do a great job of ensuring the quality of all the new
features that land in Fedora each cycle. But when features are developed
and tested on their own, the overall experience of the system as a whole
can sometimes end up a bit uneven and rough. 'Fit and Finish' will focus
on improving the way our users experience Fedora.
To achieve this, we will hold regular test days, each of which will
focus on use cases in a certain area. A few ideas for test day topics
can be found on the 'Fit and Finish' page already. If you have ideas for
other areas that could benefit from this kind of attention, please let
us know.
Our first test day will focus on display configuration, and will be held
on Tuesday, July 7, from 12:00 to 21:00 UTC (8am -> 5pm EDT), in the
fedora-fit-and-finish irc channel on FreeNode. Please come and join us
there !
Matthias Clasen for the Desktop team
14 years, 9 months
KSplice in Fedora?
by Neal Gompa
I was reading an article today in ComputerWorld about something called
KSplice, which allows Linux users to install critical updates and patch in
without rebooting the computer. I tried it and while it was a bit odd for
installing (not auto-disabling the Ubuntu update system), it worked very
well. I think something like this would be great for Fedora as well,
possibly something for Fedora 12.
Would it be possible to implement this or something similar for Fedora?
Note: Article:
http://blogs.computerworld.com/never_reboot_again_with_linux_and_ksplice
14 years, 9 months
Last call for F9 updates
by Josh Boyer
F9 will be EOL'd very very soon. This is probably the last call for updates
to F9.
I wouldn't bother with updates-testing, as the time required to properly get
those pushed out and have feedback from them is longer than the EOL date. That
does not mean to push untested stuff straight to stable.
josh
14 years, 9 months
RFC: Kernel changes that may affect desktops
by Matthew Garrett
ACPI docking stations are mildly complicated creatures that require the
OS to handle part of the undocking process. We're currently doing this
entirely within the kernel, but this has the significant downside that
there's no way to handle cleanly unmounting any block devices that are
contained within the dock - they'll simply vanish.
I've been working with David Zeuthen to flesh out proper desktop support
for this, and we're now at the point where there's not a great deal of
code to write to get this working cleanly. Unfortunately this requires a
certain level of integration between the kernel and the desktop -
something has to prompt the user about unmounting the device and then
trigger the completion of the undock. The kernel still handles the
actual ACPI execution, but policy now lives in the desktop.
Once this code is ready I'd like to change the kernel defaults to allow
this. The problem is that this will cause a reduction in functionality
for desktops that don't have this integration. How should this kind of
situation be handled?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
14 years, 9 months
Suggestion re FESCO Ticket #170
by David
Re the discussion at
https://www.redhat.com/archives/fedora-devel-list/2009-June/msg01991.html
The below suggestion tries to satisfy all parties:
- it presents a neutral default
- it presents a simple choice for newbie who doesnt know what a desktop is
- it shows the range of what is available
- it allows a specific choice
Design suggestion for the Fedora download page
(http://fedoraproject.org/en/get-fedora):
FEDORA LIVE CD
Do you require a specific desktop ?
[ * ] I don't care
[ ] Fedora Live with GNOME
[ ] Fedora Live with KDE
[ ] Fedora Live with LXDE
[ ] Fedora Live with XFCE
etc
The "I don't care" just links to whichever desktop is currently the "default".
Implementation of this logic doesn't require radio buttons. Just 2 links:
1) "click here for default"
2) or "click here to choose (go to a selection menu)"
Clicking link #1 gets you the default. Or clicking link #2 takes you
to a menu of links, one for each available choice.
Fedora policy specifies which desktop the user gets if they click the default.
But the above user interface design is independent of whichever one is
the default.
14 years, 9 months
Heads Up: e2fsprogs library split-out
by Eric Sandeen
There have been a few requests to split out the various libraries in
e2fsprogs into subpackages:
libcom_err(-devel)
libss(-devel)
libuuid(-devel)
Note that libblkid(-devel) has already been split out as it is now part
of util-linux-ng (thanks to kzak!) - an email was sent previously about
that.
The following packages have BuildRequires: on e2fsprogs-devel, so
depending on what libs they required from the package, they may need to
shift to one of these new subpackages when they go in (hopefully today
or tomorrow). I'll send another follow-up mail when it's done.
Thanks,
-Eric
aconway: qpidc
aconway: rhm
anaconda-maint: anaconda
atkac: dump
ausil: silo
bpepple: evolution-brutus
bpepple: libepc
cmadams: ufiformat
danms: libvirt-cim
dcbw: NetworkManager
deji: gparted
deji: mpich2
deji: nautilus-actions
denis: k3d
drago01: fsarchiver
dwmw2: yaboot
ensc: util-vserver
gavin: squeak-vm
green: lash
grenier: testdisk
harald: readahead
ianweller: lordsawar
itamarjp: reiserfs-utils
ivazquez: mod_dnssd
ixs: e2tools
jgranado: parted
jnovy: mc
jorton: apr
jorton: apr-util
josef: btrfs-progs
jwboyer: jfsutils
karlik: gmediaserver
kasal: pmount
kraxel: xenner
kwizart: libewf
kzak: util-linux-ng
laxathom: gnubversion
lvm-team: cryptsetup-luks
mbarnes: samba4
mfasheh: ocfs2-tools
mitr: usermode
mjakubicek: ext3grep
nalin: krb5
nhorman: coda
nhorman: pam_kcoda
oget: muse
orphan: luks-tools
ovasik: inn
ovasik: quota
ovasik: star
pbrobinson: gupnp
pbrobinson: gupnp-tools
pbrobinson: rygel
rcritten: ipa
rishi: anjuta
rjones: zerofree
rstrode: gnome-utils
ruben: gearmand
salimma: Io-language
sandeen: e2fsprogs
sandeen: xfsdump
sandeen: xfsprogs
sindrepb: gtranslator
spot: ntfsprogs
ssp: libSM
steved: nfs-utils
steve: qtparted
sundaram: gnote
tbzatek: libarchive
tgl: postgresql
xris: dar
14 years, 9 months
