NO CD/DVD's detected
by Mike Chambers
I don't know about after an initial f8t2 install, but at least since the
updates, k3b nor xcdroast can detect a cdrom nor dvd drive. It wasn't
detected on my last updated system before I did a reinstall yesterday.
I can see the devices in the kernel messages. Would this have to do
with cdrecord or something about that, as I thought there were license
problems with that program and therefore is maybe screwing things up?
--
Mike Chambers
Madisonville, KY
"Best lil town on Earth!"
16 years, 6 months
When should sysctl be run during boot?
by Jonathan Underwood
Hi,
Currently, values set in /etc/sysctl.conf are set on boot when sysctl
-p -e is called. This happens in /etc/network. Of course, setting
values for kernel modules not loaded at that point has no effect.
This caught me out recently, as I tried to set a value for one of the
conntrack modules. Because the relevant module wasn't loaded until
shorewall started on my system, and because shorewall is started after
the network, the setting didn't do anything. The way I fixed it is by
adding sysctl -e -p to rc.local, so that it is ran after all the other
init scripts. However, I could see that this approach might be unwise
since the nfs script uses sysctl to change some values, and
potentially that could be undone by bad settings in sysctl.conf.
My question then is: should there not be a service that runs sysctl on
boot, as the last thing before rc.local? I have seen this on other
distributions. This would make the following statement true: If you
want to make a change to /proc/sys persistent across reboots, then add
it to /etc/sysctl.conf. It currently isn't always true due to the
timing of systl being run, but that statement is, for many, expected
behaviour.
Thoughts?
Jonathan.
16 years, 6 months
rawhide report: 20071002 changes
by Build System
Updated Packages:
(none)
Broken deps for i386
----------------------------------------------------------
kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8
kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE
kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
osgal - 20060903-3.fc7.i386 requires libosgDB.so.1
osgal - 20060903-3.fc7.i386 requires libosgFX.so.1
osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1
osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1
osgal - 20060903-3.fc7.i386 requires libosgSim.so.1
osgal - 20060903-3.fc7.i386 requires libosgGA.so.1
osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1
osgal - 20060903-3.fc7.i386 requires libosgText.so.1
osgal - 20060903-3.fc7.i386 requires libosg.so.1
osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1
osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1
polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
Broken deps for x86_64
----------------------------------------------------------
kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.202.rc8.fc8
kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit)
osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit)
osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit)
osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit)
osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit)
osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit)
osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit)
osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit)
osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit)
osgal - 20060903-3.fc7.i386 requires libosgDB.so.1
osgal - 20060903-3.fc7.i386 requires libosgFX.so.1
osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1
osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1
osgal - 20060903-3.fc7.i386 requires libosgSim.so.1
osgal - 20060903-3.fc7.i386 requires libosgGA.so.1
osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1
osgal - 20060903-3.fc7.i386 requires libosgText.so.1
osgal - 20060903-3.fc7.i386 requires libosg.so.1
osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1
osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1
osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1
osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit)
osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit)
osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit)
osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit)
osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit)
osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit)
osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit)
osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit)
osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit)
polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
Broken deps for ppc
----------------------------------------------------------
kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8
kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp
moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1
osgal - 20060903-3.fc7.ppc requires libosgDB.so.1
osgal - 20060903-3.fc7.ppc requires libosgFX.so.1
osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1
osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1
osgal - 20060903-3.fc7.ppc requires libosgSim.so.1
osgal - 20060903-3.fc7.ppc requires libosgGA.so.1
osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1
osgal - 20060903-3.fc7.ppc requires libosgText.so.1
osgal - 20060903-3.fc7.ppc requires libosg.so.1
osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1
osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1
osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1
osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1
osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1
osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1
osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1
osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1
osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1
osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1
osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1
polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
python-vcpx - 0.9.28-4.fc8.noarch requires monotone
Broken deps for ppc64
----------------------------------------------------------
kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8
kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump
moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display
xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics
16 years, 6 months
Fedora -> Fedora cross binutils/gcc/gdb packages
by Lennert Buytenhek
Hi,
I've uploaded a set of prebuilt Fedora -> Fedora cross
binutils/gcc/gdb packages (and their corresponding spec diffs[*]) to:
http://ftp.linux.org.uk/pub/linux/arm/fedora/cross/latest/
Currently, only i386 -> arm and x86_64 -> arm binary RPMS are
provided. Non-arm target architectures aren't tested, but should
be possible to make work without too much effort.
These RPMS can be used to cross-compile kernels, and to
cross-compile binaries that are to be run on Fedora systems -- i.e.,
built binaries are built against glibc (so, you can't use these RPMS
to build uClibc binaries, for example) and against other libraries as
included in Fedora.
These RPMS expect a couple of target libraries such as glibc to be
installed in the standard sysroot location, /usr/$target/sys-root/.
There is a script called repack_cross.pl which can convert a target
binary RPM to a noarch RPM with all files moved to
/usr/$target/sys-root/, and a set of such pre-generated noarch RPMS
is included in the abovementioned repository (and pulled in when
you install the cross-compiler.)
There is no support for building the required target libraries without
building the compiler first. In other words, since the build process
for the cross-compiler depends on there being a suitable target glibc
already, these RPMS and spec diffs can not be used to bootstrap a new
Fedora architecture port from scratch.
Feedback appreciated.
cheers,
Lennert
[*] The included cross-binutils patch is based on an earlier
cross-binutils patch by David Woodhouse.
16 years, 6 months
bluetooth not working automatically
by Thomas J. Baker
Does bluetooth automatically work for anyone? I'm seeing the following
problems:
bluetooth service always fails to start at boot - address in use
- can be started by hand after
bluetooth-applet doesn't seem to get run at login
- works fine if started by hand
It seems like stuff is working, just not automatically.
tjb
--
=======================================================================
| Thomas Baker email: tjb(a)unh.edu |
| Systems Programmer |
| Research Computing Center voice: (603) 862-4490 |
| University of New Hampshire fax: (603) 862-1761 |
| 332 Morse Hall |
| Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb |
=======================================================================
16 years, 6 months
EPEL report week 39 2007
by Thorsten Leemhuis
http://fedoraproject.org/wiki/EPEL/Reports/Week39
= Weekly EPEL Summary =
Week 39/2007
== Most important happenings ==
* Nothing major
== EPEL SIG Meeting ==
=== Attending ===
* [:DennisGilmore:dgilmore]
* [:JesseKeating:f13]
* [:ThorstenLeemhuis:knurd]
* [:MarekMahut:marek]
* [:MikeMcGrath:mmcgrath]
* [:KevinFenzi:nirik]
* [:KarstenWade:quaid]
* [:WarrenTogami:warren]
=== Summary ===
* http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription and http://fedoraproject.org/wiki/EPEL/CommunicationPlan -- quaid
* both were approved -- nobody complained on the list last time it was discussed (that was some weeks ago) and we can easily updated when people want to see something changed
* task--quaid: put it properly in the wiki (link on the frontpage, everywhere else where needed? and similar stuff)
* http://fedoraproject.org/wiki/EPEL/Tasks/Rhel51 -- unassigned
* new ask page created by knurd to track preparations we likely should do for 5.1
* when to remove yum-utils and other packages that are not part of RHEL?
* leave the package in the repo until at least CentOS catches up, then drop them?
* nirik> | I'm happy to work on bugging people about broken deps and trying to work on the repo for the next testing/final move.
* http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData -- stahnma
* skipped
* http://fedoraproject.org/wiki/EPEL/Tasks/KojiAndBodhiForEpel -- unassigned
* moving to bodhi requires that we switch to koji, which first needs the ability to hide RHEL binaries from the world
* http://fedoraproject.org/wiki/EPEL/Tasks/Misc
* yum-cron
* things are in the works to get this issue fixed; see https://www.redhat.com/archives/epel-devel-list/2007-September/msg00087.html
* do more on the list and less in the meetings; "Power to the people with no delay." aka "make Steering Committee nearly unimportant" and "new schedule page"
* some discussions around this to improve workflow and do stuff like "if nobody complains on the list (or in the IRC meetings) its simply considered accepted"
* knurd> | it's just a general idea IMHO; we just need to find way to realize that idea; the new stuff in the wiki is a first step for I hope we do more, but I don't know yet exactly what to do; suggestions welcomed
* Free discussion around EPEL
* nirik> | I have almost caught up on security checking for epel...
* nirik> | there are some packages that were never built, but have branches. Might be good if we could gather a list of those and ping maintainers to build or work on deps to build
* nirik> | finally, did we ever determine about pushing from testing->stable more often? Or should I bring that up on the list again?
* we prepare one; will decide if we just do it or if we do it together with 5.1
* dep scripts running for testing these days? mmcgrath> | knurd: I don't think they are, I'll do that now.
* task--mmcgrath -- dep scripts running for testing
=== Full Log ===
https://www.redhat.com/archives/epel-devel-list/2007-September/msg00110.html
== Stats ==
=== General ===
Number of EPEL Contributors 1
We welcome 1 new contributors: till
=== EPEL 5 ===
Number of source packages: 670
Number of binary packages: 1299
There are 9 new Packages:
* amavisd-new | Email filter with virus scanner and spamassassin support
* fedora-package-config-smart | Fedora EPEL configuration files for the Smart package manager
* jack-audio-connection-kit | The Jack Audio Connection Kit
* libid3tag | ID3 tag manipulation library
* mathml-fonts | Mathematical symbol fonts
* optipng | A PNG optimizer and converter
* python-fedora | Python modules for talking to Fedora Infrastructure Services
* smart | Next generation package handling tool
* wavpack | A completely open audiocodec
=== EPEL 4 ===
Number of source packages: 421
Number of binary packages: 859
There are 1 new Packages:
* wavpack | A completely open audiocodec
----
["CategoryEPELReports"]
16 years, 6 months
Experiences with F8T2 on Thinkpad T61
by Matthew Saltzman
My T61 has the Nvidia Quadro NV140M video card. I tested the x86_64
live dvd and installed the x86_64 DVD. This message covers
platform-specific issues that I encountered.
Live DVD:
- The DVD won't boot into X. If I boot to runlevel 3 and attempt to
system-config-display, there are two problems.
(1) The Monitor section of xorg.conf is missing.
(2) The nv driver hangs with a black screen. The keyboard is still
functional and I can reboot with <CTRL>-<ALT>-<F1> <CTRL>-<ALT>-<DEL>.
Hand-editing xorg.conf to create a Monitor section and using the vesa
driver restores X functionality.
- I used gparted to resize NTFS partitions and partition the drive. It
hung at the end of the resize operation without confirming it is
finished (although the operation appears to have completed). Also,
gparted quits after the rescan step after each operation set.
Installation:
- Have to install with "vesa" kernel option. The nv driver boots to a
black screen.
- On the Disk Druid screen, the screen is not repainted after opening
and closing popups.
- The display is only configured for 800x600.
Post-Installation:
- Display issues (as above--nv driver and Monitor detection don't work).
The new nv drivers don't help.
- Screen brightness is erratic. The screen brightness applet appears,
but whatever controls I hit, brightness changes randomly up or down and
does not get fully bright or dim. If I switch to a VC, I can control
the brightness, but ^@ characters appear on the display.
- X server doesn't terminate on logout--I have to <CTRL>-<ALT>-<BKSP> to
kill it.
- Suspend doesn't work at all. Select Suspend from the power applet and
the machine starts to suspend, the light comes on, then the light goes
off and the machine is live, except that the display is black. I can
reboot as above.
- Hibernate appears to work, but on resume I get a message that
hibernate failed.
- Stopping the bluetooth service on reboot or shutdown fails, although
starting on bootup succeeds. Have not tested bluetooth functionality
otherwise.
Can anyone confirm these behaviors and that they are bugs? I'll file
them, if so. Workarounds welcome too.
There are some other issues I'll post later, but they don't seem
hardware related.
16 years, 6 months
i810switch -> xrandr for F8
by Matt Domsch
The i810switch program has been around for a while, and it forces the
Intel i810 - i945 series video chips to enable or disable the external
VGA or LCD panel video output devices on a laptop. i810switch has not
had an update since June 2005.
In Fedora 8, the xrandr application provides this same functionality,
natively in the Xorg subsystem.
In my limited testing, xrandr works on the i810 class hardware I have
access to.
I'd like to drop i810switch from the distribution for Fedora 8, and
add a release note suggesting users of i810switch use xrandr instead.
Thoughts?
Thanks,
Matt
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
16 years, 6 months
Can we please stop with the stupid add you Xorg.log canned response to X and OpenGL bugs?
by Hans de Goede
Hi all,
A couple of days ago I filed this (fairly detailed bug):
https://bugzilla.redhat.com/show_bug.cgi?id=304551
About opengl rendering problems with a certain app on an other wise perfectly
fine working opengl setup, and explaining that downgrading mesa-libGL and not
making any other changes fixes this. Notice the and not making any other
changes. Iow this is in no way a configuration problem.
So I got his canned response:
"Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this
information.
Thanks in advance."
Which is not the first time, and which just plain sucks! This looks as if it
was added without even taken a look at the bug, as the requested info ranges
from little relevant to compeltely unrelevant. This does not motivate me (at
all) to take the time to fill proper detailed bug reports!
So can we please stop with this kind of canned responses, I understand they can
be usefull but before adding them atleast read the bug and consider if they are
relevant.
Thanks & Regards,
Hans
16 years, 6 months