Gnome's control-center now requires NetworkManager-wifi. But it's only a
soft requirement, no shared libs involved.
To keep your workstation NM-free, you want to install a dummy package
that provides NetworkManager-wifi but actually contains nothing, ideally
before updating to 7.5. Here's a
Dave Johansen wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1086971
I have been able to reproduce the above issue on my home network and at
work, but RedHat is claiming it is not a bug, so can some people on this
list give it a try and see if they can reproduce it?
If you connect with
Latest really rude show stoppers were/are:
el6:
- librsvg2: your private fork bomb for gnome
- kernel: scheduler completely broken on numa systems
- qt: kde unusable when going up from -26 to -28
el5:
- firefox hangs on quit after latest ESR update
- (totem plugins no longer work too)
What I
Christo Larsen wrote:
Running Centos 6.4
6.5 is current, nobody cares for 6.4 anymore.
Any Idea´s?
Put it into a Windows machine to switch it once. Then send it something
like
AT^U2DIAG=0
over the serial line to switch it permanently.
-Michael
Eliezer wrote:
What would be a clean buildroot for?
Well, only God himself did the initial creative work just once -- after
that, He let things go, because it was already to complicated even for
Him -- or perfect. Anyway, because He had not planned doing it again and
reiterate, we now have
Camron W. Fox wrote:
After upgrading from 6.4 to 6.5, our serial console configuration non
longer work. We have the following upstart file: ...
According to the comments in /etc/init/serial.conf you shouldn't have a
/etc/init/ttyS0.conf or do anything to /etc/securetty. This is all
handled
This package has a build requirement 'gecko-devel' which is fulfilled by
'xulrunner-devel'. But in the process of building the browser plugins
two tools named 'xpidl' and 'xpt_link' are necessary. They werde once
part of 'gecko-devel' but are now replaced by other tools. I haven't
found any
Fred Smith wrote:
Apparently I'm the only Centos user who is unable to view the quicktime
trailers,... or maybe nobody but me is interested.
Assuming you have the necessary codecs installed, it still doesn't work,
because Apple checks your QuickTime-Version with some piece of
Javascript. It
Yves Bellefeuille wrote:
This point has already been answered on this mailing list (and
elsewhere). A bit of search in the archives and elsewhere would
quickly bring you this:
http://wiki.centos.org/HowTos/Skype
I'm very familiar with that document. :-) And many users, including
myself,
Namely:
* hivex
* hivex-devel
* librdmac
* librdmac-devel
* sanlock-libs
* sanlock-devel
and maybe others.
Is this on purpose (I don't know if upstream has removed or updated the
32-bit rpms, but the old ones are still in C6.3/x86_64), or is it just
the usual sloppyness (I've been told here
m.roth at 5-cent.us wrote:
erm... that is going to mean that everytime there is an update for
either QT or anything that it links into or anything that is in a lib
associated down that chain - the entire stack needs to be rebuilt. Are
you sure this is a good idea ?
I'm not sure, but the guy
Marc Deop wrote:
On Sunday 26 February 2012 20:39:03 Michael Lampe wrote:
So I can build, but the resulting RPM cannot be installed -- if not
forced. (No problems then as everything is there.)
Why don't you add the files needed as dependencies to the spec file? (it's
one of the beautis
I'm building my own openmpi packages derived from upstream SRPMs.
Problem: The ones built with Intel's compiler can only be installed by
force, because Intel doesn't register their provided libs with rpm.
Any idea how this can be done?
(Alternative ideas are appreciated as well -- as long as
Frank Cox wrote:
A dependency is supposed to be something that's required for a program to
work.
Removing the dependency from the rpm won't magically make a program work if it
really does require the functionality provided by that dependency.
It's there.
Just not registered with rpm. --
Frank Cox wrote:
Edit the dependency list to suit.
Maybe I was too dumb to properly explain it:
The Intel stuff is there implicitly. And it _is_ needed. Both for
building and then running.
But it's not registered with rpm by Intel!
So I _can_ build, but the resulting RPM cannot be installed
Ljubomir Ljubojevic wrote:
I totally lost you.
No problem. Play the game of chess like your namesake did so well. :)
Please provide specifics, what package, is it in rpm
or not, details please, so we do not chase out own tails.
Gimme a trick: How to unregister an implicit but formally
Frank Cox wrote:
Gimme a trick: How to unregister an implicit but formally unavailable
runtime dependency in a spec file?
I've given you the solution twice. Here is a more detailed description of the
exact lines that you need to edit in the spec file:
Antonio da Silva Martins Junior wrote:
Have you tried to make a fake src.rpm package that provides this
'libfoo' and
install it ? It didn't need to install anything just tell to the rpm library
that it
provides 'libfoo'.
Normally, I leave the building straightforward.
Of course, I
John Stanley wrote:
AutoProvReq: no
Seemed like a good hint, but doesn't do the trick on 5.7. The RPMs still
require the Intel libs.
Hmmm ...
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Les Mikesell wrote:
Have you tried to make a fake src.rpm package that provides this
'libfoo' and
install it ? It didn't need to install anything just tell to the rpm
library that it
provides 'libfoo'.
Normally, I leave the building straightforward.
Of course, I can also climb to
Michael Lampe wrote:
In other words: my BIOS is broken. But it's broken for all Lenovo
Notebooks. So ...
It seems mine is particularly broken: The BIOS isn't even lying, it
realy disables ASPM!
That at least is my conclusion after looking at this
https://wiki.edubuntu.org/Kernel
After going from CentOS 5.7 to 6.2, a lot of things turned out to be
much better, but there are also quite some regressions. The most obvious
one is power consumption on my notebook. It was notably lower before.
The ASPM issue introduced in 2.6.38 was widely reported and discussed,
and the
Patrick Lists wrote:
Iirc to enable ASPM on Fedora the kernel must be booted with
pcie_aspm=force. Maybe you need to use that option too? For more info
see:
http://www.phoronix.com/scan.php?page=articleitem=linux_aspm_solutionnum=1
That's no general solution. It may work, but (e.g.) it
Rob Kampen wrote:
So for those of us that do not understand the intricacies of ASPM / BIOS
/ ACPI, how do we ensure we are getting the best (least) power consumption?
Hey! I was asking for people who can help me backport the upstream fix!
I have a new ASUS G73S with i7 8 core processor -
Michael Lampe wrote:
Iirc to enable ASPM on Fedora the kernel must be booted with
pcie_aspm=force. Maybe you need to use that option too? For more info
see:
http://www.phoronix.com/scan.php?page=articleitem=linux_aspm_solutionnum=1
That's no general solution. It may work, but (e.g
Ljubomir Ljubojevic wrote:
Biarch is actually only needed for libraries and support packages.
Running native i386 application on x86_64 does not make much sense
(third-party apps are another thing).
I also like the option to compile, run, test, debug, etc. my own
programs as 32 bit. That's
Les Mikesell wrote:
Why not use a virtual machine for that and have a cleaner separation
of the architectures?
Biarch runs natively and therfore faster, it can use
hardware-accelerated OpenGL, it is easier to setup and use, and it is
fully supported by TUV. To me the separation of
Reindl Harald wrote:
compilers and devel-packages should usually be seperated from
working-computers and the compiled software packed as RPM
in a dedicated vritual machine
I'm using CentOS not only as a mail/web/etc. server, but also on my
development workstation, on a compute server and on
Reindl Harald wrote:
compiling is not the problem
Indeed. And thanks to biarch, this works ootb.
there is ONE virtual machine neough for all users
Biarch reduces this even to one less: none. It's obvioulsy the simpler
solution.
however i can not imagine a usecase for 32bit software these
Johnny Hughes wrote:
There is a variable in yum.conf called multilib_policy ...
The default in CentOS 5 is all ... the default in CentOS 6 is best.
Ah, ok. Part of my playing around with 6.2 ist finding all the
differences with respect to 5.x. ;)
I can tell you that I would personally use
Maybe we're talking about different things here. I'm definitely not
talking about how to build a distribution. That's why I'm using your's
on not running my own.
I'm talking about the usefulness of biarch. Not in the sense of building
packages for redistribution, especially not as RPMs. It's
Reindl Harald wrote:
you need not to build a distribution to build clean packages
in a clean build-envirnonment - this is simply in your own
interest over the long and any quick dirty solution
will eat your time later
Please tell me in detail what ends up quick and dirty, when doing what
(Sorry to be a little talkative today, but I will easily refute everything.)
Les Mikesell wrote:
If you are moving binaries to any other machine, you are likely to
have odd failures if you don't carefully control the libraries in the
build environment.
The linker doesn't and cannot link
Reindl Harald wrote:
it IS DIRTY because it does NOT remove obsoleted files
and yes i have seen environemnets where as example mysql did not
compile any longer as long all pieces of the old version were not
deleted manually
Hardly ever do I type 'make install'. I stick to
Reindl Harald wrote:
on a clean environment $HOME does not contain software
this is the apple-way having binaries running where your user
have write-access and from the viewpoints of security and
modern system-managment worst practice
The three Federal Computing Centers in Germany (Juelich,
Les Mikesell wrote:
You _can_ cross-compile code for a whole bunch of different
environments. That doesn't make it a particularly good idea, even if
it does happen to be fairly easy in this one particular case. How
many cases do you want to support?
Exactly this one. The only relevant
John R Pierce wrote:
who says he's building system packages?I got the impression he's
building his own applications, stuff that typically runs in $HOME rather
than /usr or whatever.
Exactly. Wasn't that clear from the very beginning?
-Michael
I'm experimenting with 6.2 now. Things seem to be really great so far!
Distribution closure is one of my favourite pets. So I tried to install
everything.
I found only one problem, but that's another (minor) thing.
But I found almost nothing under /usr/lib.
So, Biarch is really dead?
Funny!
nope. its actually quite a major pain to manage..
you forgot to mention what you installed, how you did it and what you
expected V/s achieved
I have installed all the packages from the two x86_64 DVDs with
(eventually):
yum install --exclude=ovirt\* \*
I'm not using any
... I understand now ...
No, you don't.
is it required to upgrade to each point release in order to continue
receiving security updates?
It's strictly linear and one-dimensional.
Point releases only mark a specific point in time, where you get a
little bit more, e.g. additional drivers, an
Tommy Zong wrote:
My centos is 4.8 while I need gtk 2.8 or later. How to upgrade GTK?
You can't without breaking everything. But you can install an
alternative version alongside and make sure that only the programs that
need it are using it (that means you _can't_ just install to /usr/local).
41 matches
Mail list logo
