Mesa 7.6.0 bugs
by Bojan Smojver
New mesa (7.6.0) is causing trouble for people using F-11/12 code (see
bugs #524338 and #509528 for instance).
Are there fixes available for these problems? Last time 7.6.0 packages
were built was Sept 21, which is a month and a half ago and it seems
that concerns from the above bugs are not being addressed.
Is it too late to revert to 7.5.x, which used to work fine?
--
Bojan
14 years, 5 months
texlive-2009 man & info
by Neal Becker
I'm trying texlive-2009 packages for f11. I see man and info pages get
installed (not in standard system locations, but into texlive tree), but man
and info search paths don't seem to be setup to find them.
14 years, 5 months
texlive-2009 tlmgr
by Neal Becker
tlmgr
Can't locate TeXLive/TLPOBJ.pm in @INC (@INC contains:
/usr/share/texlive/tlpkg /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-
linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0
/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl
/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0
/usr/lib/perl5/site_perl .) at /usr/bin/tlmgr line 36.
BEGIN failed--compilation aborted at /usr/bin/tlmgr line 36.
sure enough, /usr/share/texlive/tlpkg dir exists, but is empty.
14 years, 5 months
Re: Wodim trouble
by Joerg Schilling
>I've filed a bug[1] against wodim not burning dvds correctly. While
>browsing through another bug[2] on wodim, I came across this comment[3].
>"wodim is completely unmaintained since May 6th 2007, don't
>expect to see any fixes anytime soon as long as Redhat
>continues to distribute wodim instead of the original software."
>Can someone please clear this up?
Wodim is a creation of a hostile packaging person from Debian.
See: http://cdrecord.berlios.de/private/linux-dist.html
for more information.
Let me give you some facts:
The fork did have less changes in the time between May 6th 2007 and today
than the original source had in a lazy week.
In the same time, the original software had a sustained average putback rate
of 3 changes per day. Since May 2006 50% of the code was replaced or added.
There is more than 30% new code since then and many many new features and bug
fixes. In contrary to the fork, the orogonal project carefully listenes to the
bug reports from the users and and reported bugs are typically fixed within a
few hours. This is why there are no known bugs in the original software and why
there are more than 100 bugs (well known since January 2007) in the fork that
are not fixed.
All known bugs in the fork will disappear if you just upgrade to recent original
software.
Roman Rakus and others did verify many times that he is not interested in the
problems of the users. Please ignore comments from people like Roman Rakus as
he is involved in the attacks against the OpenSource Project cdrtools
and thus not interested in a discussion about the backgrounds on why
Redhat started to distribute the proken fork instead of the original software.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js(a)cs.tu-berlin.de (uni)
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
14 years, 5 months
Re: Wodim trouble
by Joerg Schilling
>That may be true, but since cdrecord is not shippable, it's a pretty
>vacuous truth. The solution is obviously to fix the bug and help revive
>upstream, or else host a development tree on fh if upstream stays idle.
Note that is is just the other way:
It is cdrkit that is undistributable as it is cdrkit that in conflict with
the Copyright law and the GPL.
Cdrtools has been checked for legal problems by several lawyers including
the Sun legal department and none could find any legal problem.
Cdrkit was created by a hostile downstream, see:
http://cdrecord.berlios.de/private/linux-dist.html
and nobody so far was able to prove the claims about so called license
problems spread by Eduard Bloch by using quotes from the GPL text.
The problem with the existence is a social problem and we, the people
in the OSS community need to fid a way to deal with this social problem.
P.S.:
Libburn is no alternative too: it misses most important features it is
non-prtable and we recently learned that the Authors of libburn do not
care much about where they take the software from. Note that they claimed not
to use any bit from the original cdrtools project's source but they really did
use code from cdrtools. I would call this a social problem....
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js(a)cs.tu-berlin.de (uni)
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
14 years, 5 months
KDE-SIG weekly report (45/2009)
by Jaroslav Reznik
This is a report of the weekly KDE-SIG-Meeting with a summary of the
topics that were discussed. If you want to add a comment please reply
to this email or add it to the related meeting page.
----------------------------------------------------------------------------------
= Weekly KDE Summary =
Week: 45/2009
Time: 2009-11-03 14:00 UTC
Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-03
Meeting minutes: http://meetbot.fedoraproject.org/fedora-
meeting/2009-11-03/fedora-meeting.2009-11-03-14.08.txt
Meeting log: http://meetbot.fedoraproject.org/fedora-
meeting/2009-11-03/fedora-meeting.2009-11-03-14.08.log.html
----------------------------------------------------------------------------------
= Participants =
BenBoeckel
JaroslavReznik
KevinKofler
RexDieter
StevenParrish
ThanNgo
ThomasJanssen
Ryan Rix
----------------------------------------------------------------------------------
= Agenda =
* topics to discuss:
o KDE-4.3.3 state
o Fedora 12 looming soon, remaining issues/blockers?
o constantine-kde-theme-extras, aka packaging Mosaico kdm/ksplash theme?
o VOIP meetings
= Summary =
o KDE-4.3.3 state
* 4.3.3 is imported into devel/ branch
* some remaining issues - kdebindings & kde-l10n doesn't build
** Kevin_Kofler suggest mathstuff hint how to fix kdebindings
** rdieter will fix kde-l10n issues
o Fedora 12 looming soon, remaining issues/blockers?
* a lot of KDE SIG members are using Fedora 12 already
* beta still had the "install to hd link on desktop lacking execute
permission" problem
* "SELinux is preventing the /bin/loadkeys from using potentially mislabeled
files (Documents)." bug [1] added to Fedora 12 blockers tracker
o constantine-kde-theme-extras, aka packaging Mosaico kdm/ksplash theme?
* we agreed we don't want it, if someone is willing to fix issues, we're not
blocking it
* issues:
** KDM colors do not match latest wallpaper
** KSplash rectangles have bad looking shaddows
* jreznik will import old Constantine to SVN
o VOIP meetings
* not for regular meetings (at least for now)
* we try to set conference call from FUDCon
----------------------------------------------------------------------------------
= Next Meeting =
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-10
----------------------------------------------------------------------------------
= Links =
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=529951
14 years, 5 months
Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen
by Steve Dickson
[With the next nfs-utils rawhide build, I will be flipping the ]
[switch that will cause all NFS client mounts to try NFS v4 first ]
[At the bottom of this email has the workarounds if this change does ]
[indeed cause pain ]
As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature
I am one commit away from changing the default protocol version NFS will
be using (or at least trying to use).
What does this means to you? Hopefully nothing! In theory this should
be a very seamless transition but with all new technology there
will be (and are) some rough spots.
Why are make the change? See the NFSv4Default wiki for details,
but in a nutshell:
* Better performance - V4 is now a stateful protocol. Meaning the server keeps
state on all the clients access a particular file or directory. This
allows the server to give out delegations (or leases) which in turn
allows the client to aggressive cache both data and meta data locally
* Firewall Friendly- With v4 only one port is used 2049 for all traffic
including mounting and file locking.
* Finally it enables us use upcoming minor releases of the the protocol.
NFS version 4.1 and pNFS are two example of upcoming minor releases.
FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I
personally have been using it for my home directory for a couple years now..
For more of the nitty gritty details see
http://www.iaps.com/NFSv4-new-features.html
That's the good news... Here is the bad....
Because the mount command will try NFS v4 first, mounts to older Linux servers
will start failing like:
# mount linux-server:/export /mnt
mount.nfs: mounting linux-server:/export failed, reason given by server:
No such file or directory
This is due to a defect in the Linux server exporting code, which is fixed
in F-12, *but* there are a number of workarounds
On the server (Which is suggested):
* Add the following entry to the /etc/exports file:
/ *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages.
On the client, go back to v3 mounts by doing one of the following:
* Add -o v3 to command line, similar to:
mount linux-server:/export /mnt
* Change the default mount version in the new /etc/nfsmount.conf file by
uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options' section.
See nfsmount.conf(5) man page for details. The diff would look like:
--- /etc/nfsmount.conf.orig 2009-10-26 09:30:21.000000000 -0400
+++ /etc/nfsmount.conf 2009-10-26 10:31:30.227443686 -0400
@@ -31,7 +31,7 @@
# Protocol Version [2,3,4]
# This defines the default protocol version which will
# be used to start the negotiation with the server.
-# Defaultvers=4
+Defaultvers=3
#
# Setting this option makes it mandatory the server supports the
# given version. The mount will fail if the given version is
steved.
14 years, 5 months