Re: LCD via VGA port
by Paulo Cavalcanti
> I just upgraded my main system from fc5 to fc6. I have an nvidia BFG
> something or other, with one vga and one dvi port. I was connected to
> two monitors, one big CRT via VGA and one small LCD via VGA. One of
> the VGAs via an adapter to the DVI port.
> So I clearly have an fc6 system, an nvidia card, and an LCD with only a
> VGA interface. Thus my reply.
> I'm actually in flux, and am giving away the CRT. I had been in fc5
> with the nvidia drivers and using RandR for multihead, which I got to
> work after some pains. Now, I am just using the LCD-VGA, and haven't
> yet installed the nvidia driver (using nv). I did notice, that my CRT
> which is still connected displays text garbage. And I think I did have
> to manually add a monitor section to my xorg.conf.
> Anyway, if there is a specific question or experiment you would like me
> to try, let me know.
could you try to connect your LCD using the VGA port without the adapter?
This is what I am not being able to accomplish. It is like the modelines
were wrong.
Thank you for the reply.
/Paulo Roma.
17 years, 3 months
LCD via VGA port
by Paulo Cavalcanti
Hi,
I have already posted this message at the user list and received no answer.
If someone could say if he (or she) is using an LCD via a vga port,
it would be a beginning.
-------------------------------------------------------------------------------------------------------------
I am having problems connecting an LCD to a nvidia card
using a VGA port in FC6. I only succeeded using
either a DVI port or a DVI-VGA adaptor. With a real CRT
everything works fine.
I tried the VGA port approach in two different computers with two different
graphics cards
(GeForce 4 and FX-5200), two different Samsung LCDs (510N and 710N), and got
the same
result. With the nv driver, generally, the screen becomes black after a
logout
and X does not return. The nvidia driver is even worse. If I manage to
login,
the system hangs during a video intensive application, and opengl does not
work.
I have never had any problem using FC5, what makes me believe that
the problem stems from xorg 7.1
Any suggestion will be really appreciated.
Thanks,
/Paulo Roma.
17 years, 3 months
ESR "fedora-submit"
by Warren Togami
http://www.catb.org/~esr/fedora-submit/
"fedora-submit will be a command-line tool that ships RPMs to the Fedora
project for inclusion in their repository. It will ship with a future
release of Fedora Core."
No it will not.
"Warren Togami
Fedora project honcho. Has backed this concept."
I am not the "honcho", and I have never supported your crack-filled ideas.
Dear ESR,
Nobody in the Fedora Project has endorsed your fedora-submit tool. We
have stated on multiple occasions that your reasons for fedora-submit
*COMPLETELY MISS THE POINT*. By the existence of this page with its
stated falsehoods you potentially confuse the community into thinking
that we support your idea.
Please delete this page, or at least remove the false statements.
Warren Togami
wtogami(a)redhat.com
17 years, 3 months
Fwd: 2.6.19-1.2891.fc7 -- INFO: soft-safe -> soft-unsafe lock order detected
by Miles Lane
Since I have received no reply on the development testers list, I'll try here.
---------- Forwarded message ----------
From: Miles Lane <miles.lane(a)gmail.com>
Date: Dec 29, 2006 1:17 AM
Subject: 2.6.19-1.2891.fc7 -- INFO: soft-safe -> soft-unsafe lock order detected
To: For testers of Fedora Core development releases
<fedora-test-list(a)redhat.com>
[ INFO: soft-safe -> soft-unsafe lock order detected ]
2.6.19-1.2891.fc7 #1
------------------------------------------------------
cupsd/1884 [HC0[0]:SC0[1]:HE1:SE0] is trying to acquire:
(&ssec->nlbl_lock){--..}, at: [<c04cec37>]
selinux_netlbl_socket_setsid+0xbb/0x123
and this task is already holding:
(af_callback_keys + sk->sk_family#3){-.-+}, at: [<c05daa1c>]
inet_accept+0x70/0xb5
which would create a new lock dependency:
(af_callback_keys + sk->sk_family#3){-.-+} -> (&ssec->nlbl_lock){--..}
but this new dependency connects a soft-irq-safe lock:
(af_callback_keys + sk->sk_family#3){-.-+}
... which became soft-irq-safe at:
[<c043fff1>] __lock_acquire+0x37d/0x9f8
[<c044094d>] lock_acquire+0x56/0x6f
[<c05fbdb6>] _read_lock_bh+0x30/0x3d
[<c04c687e>] selinux_socket_sock_rcv_skb+0xbd/0x252
[<c05d0645>] tcp_v4_rcv+0x37a/0x909
[<c05b7593>] ip_local_deliver+0x185/0x22e
[<c05b73d6>] ip_rcv+0x418/0x450
[<c059ae9c>] netif_receive_skb+0x2db/0x35a
[<c059c85f>] process_backlog+0x95/0xf6
[<c059ca46>] net_rx_action+0xa1/0x1a8
[<c042bf5a>] __do_softirq+0x6f/0xe2
[<c04063a1>] do_softirq+0x61/0xc7
[<ffffffff>] 0xffffffff
to a soft-irq-unsafe lock:
(&ssec->nlbl_lock){--..}
... which became soft-irq-unsafe at:
... [<c044007d>] __lock_acquire+0x409/0x9f8
[<c044094d>] lock_acquire+0x56/0x6f
[<c05fbc89>] _spin_lock+0x2b/0x38
[<c04cec37>] selinux_netlbl_socket_setsid+0xbb/0x123
[<c04d0c92>] selinux_netlbl_socket_post_create+0x2d/0x2f
[<c04c807b>] selinux_socket_post_create+0x156/0x15c
[<c059213c>] __sock_create+0x179/0x1b2
[<c05921ae>] sock_create+0x1a/0x1f
[<c0592435>] sys_socket+0x1b/0x3c
[<c0592cba>] sys_socketcall+0x77/0x241
[<c0404050>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
other info that might help us debug this:
3 locks held by cupsd/1884:
#0: (sk_lock-AF_INET){--..}, at: [<c05da9dd>] inet_accept+0x31/0xb5
#1: (af_callback_keys + sk->sk_family#3){-.-+}, at: [<c05daa1c>]
inet_accept+0x70/0xb5
#2: (policy_rwlock){..-?}, at: [<c04cebd0>]
selinux_netlbl_socket_setsid+0x54/0x123
the soft-irq-safe lock's dependencies:
-> (af_callback_keys + sk->sk_family#3){-.-+} ops: 0 {
initial-use at:
[<c0440098>] __lock_acquire+0x424/0x9f8
[<c044094d>] lock_acquire+0x56/0x6f
[<c05fbd3b>] _write_lock_bh+0x30/0x3d
[<c05c1871>] tcp_close+0x24b/0x52b
[<c05da570>] inet_release+0x43/0x49
[<c0591f72>] sock_release+0x17/0x68
[<c05921e0>] sock_close+0x2d/0x33
[<c047959b>] __fput+0xbe/0x168
[<c047965c>] fput+0x17/0x19
[<c0476f5d>] filp_close+0x54/0x5c
[<c0477ee1>] sys_close+0x78/0xb0
[<c0404050>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
hardirq-on-W at:
[<c0440056>] __lock_acquire+0x3e2/0x9f8
[<c044094d>] lock_acquire+0x56/0x6f
[<c05fbd3b>] _write_lock_bh+0x30/0x3d
[<c05c1871>] tcp_close+0x24b/0x52b
[<c05da570>] inet_release+0x43/0x49
[<c0591f72>] sock_release+0x17/0x68
[<c05921e0>] sock_close+0x2d/0x33
[<c047959b>] __fput+0xbe/0x168
[<c047965c>] fput+0x17/0x19
[<c0476f5d>] filp_close+0x54/0x5c
[<c0477ee1>] sys_close+0x78/0xb0
[<c0404050>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
in-softirq-R at:
[<c043fff1>] __lock_acquire+0x37d/0x9f8
[<c044094d>] lock_acquire+0x56/0x6f
[<c05fbdb6>] _read_lock_bh+0x30/0x3d
[<c04c687e>] selinux_socket_sock_rcv_skb+0xbd/0x252
[<c05d0645>] tcp_v4_rcv+0x37a/0x909
[<c05b7593>] ip_local_deliver+0x185/0x22e
[<c05b73d6>] ip_rcv+0x418/0x450
[<c059ae9c>] netif_receive_skb+0x2db/0x35a
[<c059c85f>] process_backlog+0x95/0xf6
[<c059ca46>] net_rx_action+0xa1/0x1a8
[<c042bf5a>] __do_softirq+0x6f/0xe2
[<c04063a1>] do_softirq+0x61/0xc7
[<ffffffff>] 0xffffffff
hardirq-on-R at:
[<c044001f>] __lock_acquire+0x3ab/0x9f8
[<c044094d>] lock_acquire+0x56/0x6f
[<c05fbdb6>] _read_lock_bh+0x30/0x3d
[<c04c687e>] selinux_socket_sock_rcv_skb+0xbd/0x252
[<c05d0645>] tcp_v4_rcv+0x37a/0x909
[<c05b7593>] ip_local_deliver+0x185/0x22e
[<c05b73d6>] ip_rcv+0x418/0x450
[<c059ae9c>] netif_receive_skb+0x2db/0x35a
[<c059c85f>] process_backlog+0x95/0xf6
[<c059ca46>] net_rx_action+0xa1/0x1a8
[<c042bf5a>] __do_softirq+0x6f/0xe2
[<c04063a1>] do_softirq+0x61/0xc7
[<ffffffff>] 0xffffffff
}
... key at: [<c09f6770>] af_callback_keys+0x10/0x100
the soft-irq-unsafe lock's dependencies:
-> (&ssec->nlbl_lock){--..} ops: 0 {
initial-use at:
[<c0440098>] __lock_acquire+0x424/0x9f8
[<c044094d>] lock_acquire+0x56/0x6f
[<c05fbc89>] _spin_lock+0x2b/0x38
[<c04cec37>] selinux_netlbl_socket_setsid+0xbb/0x123
[<c04d0c92>] selinux_netlbl_socket_post_create+0x2d/0x2f
[<c04c807b>] selinux_socket_post_create+0x156/0x15c
[<c059213c>] __sock_create+0x179/0x1b2
[<c05921ae>] sock_create+0x1a/0x1f
[<c0592435>] sys_socket+0x1b/0x3c
[<c0592cba>] sys_socketcall+0x77/0x241
[<c0404050>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
softirq-on-W at:
[<c044007d>] __lock_acquire+0x409/0x9f8
[<c044094d>] lock_acquire+0x56/0x6f
[<c05fbc89>] _spin_lock+0x2b/0x38
[<c04cec37>] selinux_netlbl_socket_setsid+0xbb/0x123
[<c04d0c92>] selinux_netlbl_socket_post_create+0x2d/0x2f
[<c04c807b>] selinux_socket_post_create+0x156/0x15c
[<c059213c>] __sock_create+0x179/0x1b2
[<c05921ae>] sock_create+0x1a/0x1f
[<c0592435>] sys_socket+0x1b/0x3c
[<c0592cba>] sys_socketcall+0x77/0x241
[<c0404050>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
hardirq-on-W at:
[<c0440056>] __lock_acquire+0x3e2/0x9f8
[<c044094d>] lock_acquire+0x56/0x6f
[<c05fbc89>] _spin_lock+0x2b/0x38
[<c04cec37>] selinux_netlbl_socket_setsid+0xbb/0x123
[<c04d0c92>] selinux_netlbl_socket_post_create+0x2d/0x2f
[<c04c807b>] selinux_socket_post_create+0x156/0x15c
[<c059213c>] __sock_create+0x179/0x1b2
[<c05921ae>] sock_create+0x1a/0x1f
[<c0592435>] sys_socket+0x1b/0x3c
[<c0592cba>] sys_socketcall+0x77/0x241
[<c0404050>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
}
... key at: [<c09ebb20>] __key.27522+0x0/0x8
stack backtrace:
[<c04051c1>] show_trace_log_lvl+0x1a/0x2f
[<c0405766>] show_trace+0x12/0x14
[<c04057ea>] dump_stack+0x16/0x18
[<c043fbe0>] check_usage+0x242/0x24c
[<c04404f3>] __lock_acquire+0x87f/0x9f8
[<c044094d>] lock_acquire+0x56/0x6f
[<c05fbc89>] _spin_lock+0x2b/0x38
[<c04cec37>] selinux_netlbl_socket_setsid+0xbb/0x123
[<c04d0f40>] selinux_netlbl_sock_graft+0xc7/0xcf
[<c04c4b74>] selinux_sock_graft+0x32/0x36
[<c05daa3b>] inet_accept+0x8f/0xb5
[<c0592b93>] sys_accept+0xd0/0x180
[<c0592d13>] sys_socketcall+0xd0/0x241
[<c0404050>] syscall_call+0x7/0xb
17 years, 3 months
Xawtv: some questions
by Dmitry Butskoy
Since FC-2, "xawtv" package was replaced by "tvtime".
Whereas it gives some improvements in GUI, there is a regression too --
an absence of some useful command-line tools and console radio.
I'm still using "radio" (console/cmdline radio application) and "v4lctl"
(for example, to set the TV channel when an application is not capable
for this).
Anyway, such tools could be useful for scripting and network streaming
(i.e. start to record radio from the crond, etc.)
Project page is http://linux.bytesex.org/xawtv/
I'm thinking about xawtv for Extras, but there are a couple of questions:
1) What reasons have led to decision-making on change of TV viewer? Are
there some technical or legal issues?
2) Xawtv includes code for "avi" file format, for "mjpeg" and for
"quicktime" (by an external library). Are this things allowed, or we
must strip the tarball properly (on the same manner as "xine-lib" is
done now)?
3) Is it applicable to provide the needed tools only, without TV viewer
at all?
4) Should the package be splitted to subpackages (as some distros use
it) or one big package is better (Fedora way)?
5) What about "tv-fonts", accompanied with xawtv? Whether it is
required or not? How it should be named ("xawtv-tv-fonts" or just
"tv-fonts")?
...
Note, that one of the problem for the "radio" was unicode console
support, which I've added recently. :)
Regards,
Dmitry Butskoy,
http://www.fedoraproject.org/wiki/DmitryButskoy
17 years, 3 months
Sharing devices "out of the box"
by Paul Michael Reilly
I've made my FC6 laptop available to family members (including grandma)
as a shared machine. I've taught them to log into their own session
using "switch user" so that they are on their own vt session. Works
nice until they want to share devices, like audio and the CD burner.
For FC6 I have to take pains to set up permissions appropriately but it
does occur to me to ask how Rawhide should deal with this. There seem
to be two schools of thought:
1) Sharing devices automagically is a no-brainer; it must be turned on
by default.
2) Sharing devices is a security weakness and no self respecting distro
would enable such a thing by default.
It's all well and good when the PC is set up by a someone reading any of
the Redhat lists but should there come a day when Dell (or some such)
ships RHEL this issue and lots more like it will be on the table.
It does occur to me that maybe the current user (the one who currently
owns X, the "selected" user for lack of a better description) should
dynamically own devices but this is not very satisfying: perhaps the
various users set their own special IM sounds in which case the distro
is setting policy rather than mechanism. So the issue does get
complicated quickly. Left to my own devices, I'd share the devices by
default and build in the ability to graphically configure device sharing
which smacks of a desktop (Gnome/KDE/Xfce/?) solution which might just
already exist and I haven't come across such a beast.
-pmr
17 years, 3 months
Dependancies crack me up.
by Naoki
Was trying to fix this ( because I have both i386 & x86_64 versions
installed ):
Transaction Check Error:
file /usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi from install of gphoto2-2.3.1-1.fc7 conflicts with file from package gphoto2-2.2.0-2.1
file /usr/share/man/man1/gphoto2.1.gz from install of
gphoto2-2.3.1-1.fc7 conflicts with file from package gphoto2-2.2.0-2.1
And found this :
# rpm -e gphoto2-2.2.0-2.1.x86_64
error: Failed dependencies:
libgphoto2.so.2()(64bit) is needed by (installed)
gthumb-2.7.8-3.fc6.x86_64
libgphoto2_port.so.0()(64bit) is needed by (installed)
gthumb-2.7.8-3.fc6.x86_64
# rpm -e gphoto2-2.2.0-2.1.x86_64 gthumb-2.7.8-3.fc6.x86_64
error: Failed dependencies:
gthumb is needed by (installed)
gnome-volume-manager-2.15.0-4.fc6.x86_64
# rpm -e gphoto2-2.2.0-2.1.x86_64 gthumb-2.7.8-3.fc6.x86_64
gnome-volume-manager-2.15.0-4.fc6.x86_64
error: Failed dependencies:
gnome-volume-manager is needed by (installed)
gnome-session-2.16.0-7.fc6.x86_64
I can't see gnome-session really needing volume manager, or why volume
manager needs gthumb?
Anybody ever make a big tree diagram out of FC dependencies? I recall
the source code image and I think this would be just as cool.
17 years, 3 months
java-1.4.2-gcj-compat postinstall (in mock) fault - [WAS]Re: rawhide report: 20060802 changes
by Deji Akingunola
On 8/2/06, Erwin Rol <mailinglists(a)erwinrol.com> wrote:
> This update also caused the following errors on x86_&4;
>
> Running Transaction
> Updating : java-1.4.2-gcj-compat ####################### [ 1/66]
> dirname: missing operand
> Try `dirname --help' for more information.
> mkdir: missing operand
> Try `mkdir --help' for more information.
> /usr/bin/rebuild-gcj-db: line 17: 20713 Segmentation fault /usr/bin/gcj-dbtool -n $dbLocation 64
> xargs: /usr/bin/gcj-dbtool: terminated by signal 11
> dirname: missing operand
> Try `dirname --help' for more information.
> mkdir: missing operand
> Try `mkdir --help' for more information.
> /usr/bin/rebuild-gcj-db: line 17: 20722 Segmentation fault /usr/bin/gcj-dbtool -n $dbLocation 64
> xargs: /usr/bin/gcj-dbtool: terminated by signal 11
I'm getting this same segmentation fault in the root log of a mock
build that needs java-1.4.2-gcj-compat. Which package should I filled
this against, glibc or libgcj or java-1.4.2-gcj-compat.
Deji
17 years, 3 months
Does Core have an accurate count of packages which are built against libraries from firefox?
by Jef Spaleta
Since the last firefox update I have been trying to trackdown ALL the
packages which are affected by the change in location of libraries
that come in the versioned firefox. The problem here is, is that the
autogenerated requires on libraries doesn't catch the fact that the
library has moved, so you won't actually get any depchain errors from
rpm. This makes its pretty tough to track all the affected packages
down as an end-user without installing the world.
Does anyone anywhere have a complete list of affected packages, or is
clever enough to generate such a list programmatically that doesn't
involved installing all of fedora space?
In Core I already know about gnome-python2-extras because it affected
applications that I use.
But I just ran into the fact that esc was also affect by the firefox
update by accident.
/usr/lib/esc-1.0.0/xulrunner/xulrunner-bin links against
libmozjs.so
libxpcom.so
which can't be found by the linker since these are both packages in
the versioned firefox directory tree. My god damn home workstation
died yesterday(merry christmas to me!) so if someone else can bugzilla
this before I get a chance...go right ahead.
The main point of this post however is that I don't think we are doing
a good job of coordinating maintainers so they can respond as quickly
as possible when a firefox update is pushed so they can rebuild their
packages. We've had a lovely little chat in #fedora-extras with the
firefox maintainer, and he's absolutely right there needs to be a
toolized way for each maintainer with a package who builds against
firefox to set a sort of watch in the build or update system against
firefox looking for new builds.
So what exactly can we do, in the form of policy and in the form
toolized automation which can help prevent or mitigate an unreasonable
amount of lag between when a firefox package is built and when
maintainers finally notice that other packages need to be rebuilt?
Are there additional review steps we can do to check for this
condition at the time of package review? The Core packages have to be
reviewed before the merger right? I'd like to see if we can bury this
issue as part of those reviews. Should everyone building against
firefox libraries be using versioned firefox requires? Can we add an
rpmlint check for this?
-jef"word to the wise, do not eat expresso chocolate mousse cake at 9
PM if you want to go to sleep before 2 AM"spaleta
17 years, 3 months
