I'm submitting now to Base:System a glibc with a glibc-devel-static
subpackage, so for static linking you need to add to your spec files:
BuildRequire: glibc-devel-static
this was suggested at bnc#655261. if you see serious problems, please speak
up,
Andreas
--
Andreas Jaeger, Program Manager openSUSE
aj(a){novell.com,suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi all,
While we have quite a number of submissions for the openSUSE conference now,
there is lots of room for more. We would like to actively ask for ideas on
sessions and based on that approach people if they want to do it.
So the question is - what would you like to talk about and do at the openSUSE
conference?
- What talks could be given to give an overview of the status of things
- What BoF's do we need where things can be discussed
- What workshops are needed to teach each other the skills we have to offer
- What hack sessions are needed to get certain work done
If you can and want to lead any of those sessions, you can just submit a
proposal on the website: http://bitly.com/j9TtUe
Let us know,
The oSC CfP team
Greetings all:
I had been stymied in upgrading my 11.4 system to 12.1 M1. The upgrade would
proceed as normal, but the Nvidia drivers versions 270.xx.xx and 275.xx xx
(all the proprietary xxxx.run file downloaded from Nvidia) would be
required for use. The kernel module would not build for 260.19.44 under 12.1
M1.
The 260.19.44 driver is the last one for which desktop effects worked
correctly for me. With the 270.xx.xx and 275.xx.xx I had to disable desktop
effects due to various problems. Even then, there was still a problem with
the titlebar blacking out in the middle when hovered over in some window
decorations. So I wanted to figure out how to get the 260.19.44 driver to
build the kernel module under 12.1 M1.
Turns out it was simple. Extract the NVIDIA-Linux-x86_64-260.19.44.run with
the -x switch. Change into the NVIDIA-Linux-x86_64-260.19.44/kernel
directory and open file nv-linux.h and change line 90 from #include
<linux/smp_lock.h> to #include <linux/smp.h>. Logout from KDE, login to
console as root, init 3, cd to wherever the above directory was extracted
and run the nvidia-installer as you normally would. Driver installs, reboot,
and now you can turn the KDE/KWin Desktop Effects on again and everything is
running the way it did under my old 11.4.
As far as any deeper stuff is concerned, such as the classic NVIDIA vs KWin
devs back and forth I can't address (way out of my league). I believe this
problem is triggered with the move to the 2.6.39-2-desktop kernel. Unclear
as to very specific details, but I seem to recall some mention of kernel
locks removal. All I can say is I am happily running the 260.19.44 driver
under 12.1 M1 and Kwin Desktop Effects are once again running fine.
As to why others have not seen this I do not know. I do hope this may help
anyone who may encounter what I did. This is not the correct approach for a
long term fix, but it is maybe a good interim solution for now. My hardware
is nothing special - it's only a Nvidia GTS 450. It would really be nice if
NVIDIA would fix their drivers, which is what I was initially waiting for -
but when 275.09.07 dropped and they had not I went looking for this work
around.
-Mike
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi mates,
I will Cc this post to -factory and -ja lists in hopes of getting more
feedback.
@users who need to input multi-byte characters
We are now discussing about replacing SCIM with iBus as our default
input method for multi-byte characters.
If you are interested in this topic, please try ibus related packages in
M17N repo and if you find some problems, join the discussion on -m17n
list or comment the feature #308892.
https://features.opensuse.org/308892
Takashi Iwai wrote:
> At Tue, 14 Jun 2011 16:31:53 +0000,
> Ray Chen wrote:
>>
>> I've download 12.1 m1 DVD
>> Found that default input method is still scim
>> Scim seems out of maintenance
>> I hope 12.1 can use ibus as default input method
>> but keep scim in dvd as an optional choise
>> and add gcin and fcitx (available in M17N) to dvd as an alternative choice
>
> I'm basically for it.
> Does anyone have objection against it?
As I commented in the feature #308892, current iBus has much more
advantages than disadvantages compared with SCIM. So I'm also basically
for it.
However, if we set iBus as a default input method, I hope some issues
will be solved until the release of openSUSE 12.1.
- Input problem on Flash site
Please go to
http://bugzilla-attachments.mozilla.gr.jp/attachment.cgi?id=2275
and try whether you can input characters there.
# related bug report:
# http://code.google.com/p/ibus/issues/detail?id=1113
One of the Japanese users tweeted that he could input characters with
openSUSE 12.1 M1 + M17N/iBus 1.3.9 + (anthy or mozc) + Firefox 5.0 beta,
but I myself haven't tested it yet.
At least, we need a workaround for this problem.
- Input-pad
Currently we don't have a good input-pad for inputting special
characters or marks which can be integrated to iBus (SCIM has
scim-input-pad for this purpose).
I've found Input Pad project
http://code.google.com/p/input-pad/
and tried to build packages for openSUSE on OBS, but I haven't succeeded
building them yet after openSUSE 11.4 (yep, I could use them at least on
my openSUSE 11.3) and can't figure out the cause of the failure.
I know who need it should work on it, but your help will be so much
appreciated. ;-)
> Basically we'd need two things:
>
> - Enable locale supplements in ibus.spec and IM packages
> - Adjust the priority in xim.d in ibus.spec
Reading the changelog of ibus package which is recently submitted to
M17N repo by Ray, the priority is now set to 40. I think the score is
reasonable and once we find a problem with this priority in the future,
we will be able to change it anytime, won't we?
Best,
--
_/_/ Satoru Matsumoto - openSUSE Member - Japan _/_/
_/_/ Marketing/Weekly News/openFATE Screening Team _/_/
_/_/ mail: helios_reds_at_gmx.net / irc: HeliosReds _/_/
_/_/ http://blog.zaq.ne.jp/opensuse/ _/_/
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi all,
A couple of days ago I wrote an article for news.o.o about BoF sessions for
the openSUSE conference.
As you know we're looking for more 'read-write' sessions, as opposed to the
traditional one-way-talk style. A BoF is one of such a session, others would
be workshops (to teach some skill) and hack sessions (get coding or packaging
or other work done).
If you want to know what we mean by BoF and what we are looking for in that
area, read http://bit.ly/lIzf5E
A short synopsis follows.
A BoF (Birds of a Feather) meeting is an informal, open session which brings
together people with a comon interest. An example topic would be "improve the
package submission process for Factory" or "discuss what software to include
in the GNOME liveCD".
Organizing a BoF is VERY easy: a good title (problem description) will make
sure the right people turn up and then the work is half done. You don't need
more than pen and paper to ensure an effective meeting: make sure the
discussion doesn't wander off in all directions, but results in written-down
decisions with actions and names attached if possible. Afterwards, send a
report to the mailinglist to inform those not at the meeting!
Note that you do NOT have to be a core developer of a team to organize a BoF!
Anyone can do it. If you're not entirely sure you'll make it to the
conference, just talk to the team about it. In case you can't be there,
someone can take over!
You don't have to be an openSUSE community member to organize a BoF at the
openSUSE conference either. We are more than happy if a Fedora member wants to
talk about the Fedora support in OBS or if the KDE team wants to discuss the
educational applications with the EDU team.
Planning a BoF is similarly easy. Send a proposal with the title and rough
outline via the conference website: http://bit.ly/j9TtUe
It does not need a nailed down agenda, not even a super concrete topic - for
example, if you feel the Medical team needs to get together to talk about
what's part of the DVD and what not, that's concrete enough.
Planning a BoF now is important: we (the conference team) can ensure there is
no overlap between BoF's and talks. While we will leave room to schedule BoF's
at the conference, there's a good chance the only spots left will be early in
the morning and nobody likes those :D
So, go to http://bit.ly/j9TtUe and shoot in a proposal!
I just filled a (minor) bug and notice that the bug number is just
above 700000
bugs 700000 and 700001 are not accessible (internals?), but my 700002
is :-))
I think all the people that filled this hudge amount of bugs have to
be congratulated (and also all the ones that help solve them).
jdd
NB: it can be surprising to appreciate to have a hudge number of bugs,
but here we all know that any programm have bugs and if few are
reported that only means that nobody care. Only reported bugs can be
fixed :-) (added for google readers :-)
--
http://www.dodin.nethttp://pizzanetti.fr
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hello,
Yesterday I updated my box from M1 to Factory.
No problems with the update.
Today I installed the Nvidia driver from the nvidia site.
At the end I get a segfault.
When I now trying to log in into Gnome I see the login screen and then I see this message :
There is a problem that the system cannot repair. Try to log out and log in again.
With Icewm there is no problem.
Roelof
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
since friday I am unable to install updates with yast or zypper...
i do not know exactly what happens...
initially i though is something silly like a corrupted database as
zypper se -is refused to return results for packages I was sure where
installed
and did
rpm --rebuilddb
that at least fixed zypper se -is
but still no luck with installing updates... zypper dup and up will
both download the packages but simple do nothing in the install phase.
the same is true for yast
here are the offending versions
[root@abbaton:/home/alin]: zypper se -is zypper
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
--+--------+---------+------------+--------+---------------------
i | zypper | package | 1.6.10-4.1 | x86_64 | openSUSE-Factory-Oss
[root@abbaton:/home/alin]: zypper se -is libzypp
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
--+---------+---------+-----------+--------+---------------------
i | libzypp | package | 9.8.0-2.1 | x86_64 | openSUSE-Factory-Oss
[root@abbaton:/home/alin]: zypper se -is satsol
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
--+------------------+---------+------------+--------+---------------------
i | perl-satsolver | package | 0.42.0-6.2 | x86_64 | openSUSE-Factory-Oss
i | python-satsolver | package | 0.42.0-6.2 | x86_64 | openSUSE-Factory-Oss
i | satsolver-tools | package | 0.17.0-2.1 | x86_64 | openSUSE-Factory-Oss
Alin
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
I'm relatively new to Linux, a friend gave me, I think 5, SuSE 7.3 cds and it was the splash screen on installation showing the staff and
workplace that really got to me and Win xp didn't appeal to me after 98se. The packaging list would have seen the Packman email I cced
there about mjpegtools, I was very tired then now my head is clear.
During my period as a maintainer I've learned quite a bit about Linux internals and rules that are applied to the way that packages are
made up. One of these is the shared library policy which I've seen practical examples of it's necessity. I've also just discovered
something which appears to me to be a rot setting in the Linux development world or possibly these are two exceptions, one old and one new
or maybe somebody like me is needed, a fresh "outsiders perspective" from the inside.
I've learned the meaning of ABI (application binary interface), it's the address offset (from the base address the binary is loaded into)
of the various functions that shared libraries offer to their calling programs. Maybe it's a coincidence that I just happen to be trying to
turn a new not yet submitted library package into a proper shared library, as I said I lack Linux / Unix experience so please correct any
misconceptions I have, then my old enemy mjpegtools surfaces as version 2.0.0.
Both these packages are the "anti openSUSE shared library naming policy" and what appears to me to be a trend to deviate from consistency
in shared libraries, Mjpegtools appears, from what the developer has said (note appears means speculation not certainty) to have undergone
a "not small" ABI change and that would mean a bump in the major so version, I've studied libtool and other library build aspects since
making openCOLLADA and I'm not sure without digging through piles of references but I think libtool can actually detect these ABI changes.
Ok the punchline is mjpegtools's libraries are named thus and have been for at least the last three versions, I've downloaded an entire
history of mjpegtools source rpms to find out where this came from, mjpegtools supply a spec file which ours is based on, I only use
supplied spec files for reference nowadays, after I've made an original myself in my own words so to speak :
/usr/lib64/liblavfile-2.0.so.0
/usr/lib64/liblavfile-2.0.so.0.0.0
/usr/lib64/liblavjpeg-2.0.so.0
/usr/lib64/liblavjpeg-2.0.so.0.0.0
/usr/lib64/liblavplay-2.0.so.0
/usr/lib64/liblavplay-2.0.so.0.0.0
/usr/lib64/liblavrec-2.0.so.0
/usr/lib64/liblavrec-2.0.so.0.0.0
/usr/lib64/libmjpegutils-2.0.so.0
/usr/lib64/libmjpegutils-2.0.so.0.0.0
/usr/lib64/libmpeg2encpp-2.0.so.0
/usr/lib64/libmpeg2encpp-2.0.so.0.0.0
/usr/lib64/libmplex2-2.0.so.0
/usr/lib64/libmplex2-2.0.so.0.0.0
The new package I referred to earlier uses, taken from one of the three libraries, "libserd-2.0.0.so.0.0.0" ok this is easy, once I've
named the libraries container package "libserd-2_0_0-0" for the "untechnical" users, this is why some packages have such strange and ugly
names. The author of the new package has instructions that this naming is to ensure that his shared libraries future versions can be
installed in parallel, I've read about this somewhere, oh yes the shared library policy but doesn't that refer to the digits after the
".so" oh yes that's what they're there for. (I apologise to those of you that don't like sarcasm but it's the only thing I have to anchor
my sanity)
Maybe this is the root cause of gstreamer never actually functioning 100%, I've switched back to obsolete backend-xine for the umpteenth
time after trying gstreamer again. One thing I have a wealth of experience with is trouble shooting hardware and embedded program bugs in
things designed and produced both by myself and by third parties and the worst kind of bug is the type produced by a slight intermittent
clock jitter or for that matter an infrequent transient from an undefined logic state. Worst still is a part of a program that loses sync
and enters address space that is undefined but by sheer luck stumbles back into sync, this is actually extreme bad luck if you are talking
about life support systems or for those of you that value money over life a slot machine or vending machine. This can go unnoticed for
ever or irritate the life (excuse the pun) out of the user. Such a bug can be caused by an ABI missmatch, which is the reason why I'm so
vocal about software using the exact libraries it was built with, I was involved in a heated debate (wasn't really a debate because my
opinion was ignored) about obsoleting a Packman devel package with a ficticious version number to prevent it from being paired with an
openSUSE built library package because it introduces an element of uncertainty which to me is an undefined logic state and capable of
introducing the "hidden bug" I described earlier.
Is this a new trend in the Linux world? Are we eventually going to drop those pesky digits after ".so"? One thing that ms windows and osx
have going for them is singularity which makes regularity easy, opensource is a collaboration of many spread out all over the world,
something my generation wanted with a passion when we were young and wanted to unite the whole world in peace.
This is why the shared library and naming conventions are so important, otherwise paths will deviate and confusion will creep in.
As far as the new package is concerned, it's a small package and all three libraries build in one online build service page or the blink of
an eye. I'm busy learning the "waf" build system, quite good library build support and quite easy to get the libraries in shape. I just
have to get the named header directories to fit in and allow shared devel packages and then I will, in the best possible way (I would hate
to be in the position of the debian packager who clashed with Jorge Schilling) present my patches and explain the library packaging
policies of Linux distributions and how grateful I would be if could call the library containers "libserd0" and not "libserd-2_0_0-0"
(sarcasm tried to creep in there). If he doesn't want to due to ego maybe, to be a good musician or for that matter outstanding at anything
you have to have a large ego, I know I've got one myself, I'm a performer and I've dealt with musical performers in the past, in fact a
large percentage of my acquaintances .are musicians, sound engineers or both, larger than the technical portion. I wonder why I ended up
maintaining multimedia.
Why has mjpegtools been allowed to abuse library naming. I filed a bug with them thinking it was a problem with the 2.0rc1 version but the
developer I was communicating with didn't seem to understand what I was trying to say. I'm going to continue to work on patching mjpegtools
to have correct versioning, it's good practise and the right thing to do in my mind and as I pick up experience I will patch every other
package I stumble upon that has this disease and eventually be able to build libraries in my sleep, this frees time to do other things like
fixing somebodies computer, which is where I'm supposed to be now.
What is going on? I'm hoping that those of you who've been around Linux for a while can tell me. If the answer is "it doesn't matter" I'm
going to relentlessly campaign for a serious change in the openSUSE shared library policy and silently lose faith in the future of Linux.
Now go back up the page and look at the part that says "gstreamer doesn't quite work 100%". Can somebody please give me a pointer on how
to detect ABI differences between library versions. I know how to look for bad linking so far, maybe these are just isolated incidents.]
Thanks for your time.
Dave Plater
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi All;
Has anyone used an MSI 890FXA-GD65 with openSUSE yet? A fairly new board with:
1)USB-3
2)SATA III (6G) by AMD® SB850
3)Crossfire-X
4)AMD® 890FX and SB850 chipsets
5) PCI Express 2.0 x16 & PCI Express 2.0 x1
6)RAID 0, 1, 5, 10 (SATA III ) mode by AMD® SB850
7)audio integrated by Realtek® ALC892 Chipset.
Are any of these features NOT YET supported by openSUSE 11.4 or 12.1?
Thanks, Tom
--
Tom Taylor - retired penguin
openSuSE 11.3 x86_64 openSUSE 11.4 x86_64 openSUSE 12.1
KDE 4.4.4, FF 3.6.8 KDE 4.6.00, FF 4.0 KDE 4.6.1, FF 4.0.1
claws-mail 3.7.9
registered linux user 263467
linxt-At-comcast-DoT-net
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org