It seems we should make sure other libraries mentioned in LSB are compiled against LSB versions of their dependencies wherever possible. So in this case we ought to modify QT and GTK+ to compile against libjpeg6 / -turbo.
It may be a good idea to audit all LSB-related packages for dependencies on other versions. Even if that's not actually required by LSB it is something we ought to be doing to prevent conflicts.
"Cristian Rodríguez<crrodriguez(a)opensuse.org>" <crrodriguez(a)opensuse.org> wrote:
El 07/11/10 12:09, Cristian Morales Vega escribió:
>>> That "libjpeg62 obsoletes and provides libjpeg8" is probably wrong?
>>> Shouldn't it obsolete/provide libjpeg6?
libjpeg-turbo has a different SONAME, so it SHOULD NOT not conflict, nor
obsolete libjpeg8 in anyway.
jpeg8 must remain installed on the user system on upgrade in case it is
needed by other packages.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
On Thu, 2010-11-04 at 18:06 -0300, Cristian Rodríguez wrote:
> El 04/11/10 17:53, Andrew Jorgensen escribió:
> > On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
> >> On Thursday 04 November 2010, Pavol Rusnak wrote:
> >>
> >>> It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or
> >>> libjpeg-turbo.
> >>
> >> Thats correct, mainly due to LSB requirements, which we chose to ignore.
> >
> > I'm going to recommend that we stop ignoring LSB requirements.
>
> Oh really ? the LSB is non-sense. what good reasons ?
At the risk of repeating myself: This pixbuf loader bug is just one
example.
The LSB exists to make it possible to run proprietary products on any
LSB-compliant linux distro. And despite the tunnel-vision open source
enthusiasts sometimes have there are a many important and useful
proprietary products out there. When we fail to run some product that
someone needs they go to Fedora or Ubuntu because the OS is irrelevant
to the vast majority of customers. The only thing that matters is what
the customer wants to /do/ with the OS.
I realize that in some cases LSB fails to accomplish this goal but in
this case it would have succeeded as it does in many cases.
If you feel that LSB is failing to accomplish this in some way please
step up and help give them constructive suggestions as to how it could
be accomplished better. In the real world there will always be
proprietary products and /we/ are better off if those products can run
smoothly on our favorite distro.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi, with the new blender-2.55.32862 waiting be submitted to factory, I'm
submitting (sr#52321) the openCOLLADA library package to factory as it's
needed for blenders new collada import export feature and resides in the
same graphics devel project as blender.
Collada 3D import and export libraries
COLLADA is a royalty-free XML schema that enables digital asset exchange
within the interactive 3D industry.
OpenCOLLADA is a Google summer of code opensource project providing
libraries for 3D file interchange between applications like blender.
COLLADABaseUtils : Utils used by many of the other projects
COLLADAFramework : Datamodel used to load COLLADA files
COLLADAStreamWriter : sources (Library to write COLLADA files)
COLLADASaxFrameworkLoader : Library that loads COLLADA files in a sax
like manner into the framework data model
COLLADAValidator : XML validator for COLLADA files, based on the
COLLADASaxFrameworkLoader
GeneratedSaxParser : Library used to load xml files in the way used by
COLLADASaxFrameworkLoader
Authors
-------
sebastian(a)opencollada.org gtempaccount.com
robert(a)opencollada.org gtempaccount.com
License = MIT
See :
https://collada.org/mediawiki/index.php/COLLADA_-_Digital_Asset_and_FX_Exch…
and
http://www.opencollada.org/
Regards
Dave P
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
> On Thursday 04 November 2010, Pavol Rusnak wrote:
>
> > It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or
> > libjpeg-turbo.
>
> Thats correct, mainly due to LSB requirements, which we chose to ignore.
I'm going to recommend that we stop ignoring LSB requirements. There
are some very good reasons to comply with LSB and we fail when we don't.
This pixbuf loader bug is just one example.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Moving to libjpeg-turbo would fix bnc#620175 Opensuse 11.3 Chrome Stable
Crashes When Trying to Attach a File.
Basically the problem is that Google's build of Chrome is against
libjpeg6 (because Ubuntu and Fedora use 6 - Fedora 14 uses
libjpeg-turbo, I haven't checked Ubuntu yet). This causes chrome to
crash when a gtk filechooser dialog sees a jpeg file (tries to load the
pixbuf loader which crashes because the loader is linked to libjpeg8).
This mixed jpeg problem will also cause problems for any app or browser
plugin compiled for other distros that happens to use gtk for file
choosers. For example it causes a crash with Novell's Moonlight plugin
on chrome for a similar reason (we use pixbuf loaders for all images,
we're looking at switching). The fun part is that our own plugin only
crashes in this way on our own distro.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Fedora 14 has been released with libjpeg-turbo
(http://libjpeg-turbo.virtualgl.org/). I see we have multiple packages
in home repos (home:Lazy_Kent, home:felfert, home:iboss32,
home:mkromer and home:prusnak)... so someone can comment about this?
Fedora sells this as a libjpeg API/ABI compatible changes that is just
faster. From a quick look it seems to be API/ABI compatible with the
old 6.2 version that was available for years, but 11.3 already
provides the binary incompatible 8.0. What other distros do?
Also, not sure if featurewise they are 100% equivalent (see
https://bugzilla.redhat.com/show_bug.cgi?id=639672).
Finally, this probably would be mostly a x86-64 improvement? Since we
target i586 for x86-32, that doesn't provides MMX/SSE support, the
speed improvement seems to be limited to a "25%" there.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
2010/11/4 Andrew Jorgensen <ajorgensen(a)novell.com>:
> Moving to libjpeg-turbo would fix bnc#620175 Opensuse 11.3 Chrome Stable
> Crashes When Trying to Attach a File.
>
> Basically the problem is that Google's build of Chrome is against
> libjpeg6 (because Ubuntu and Fedora use 6 - Fedora 14 uses
> libjpeg-turbo, I haven't checked Ubuntu yet). This causes chrome to
> crash when a gtk filechooser dialog sees a jpeg file (tries to load the
> pixbuf loader which crashes because the loader is linked to libjpeg8).
>
> This mixed jpeg problem will also cause problems for any app or browser
> plugin compiled for other distros that happens to use gtk for file
> choosers. For example it causes a crash with Novell's Moonlight plugin
> on chrome for a similar reason (we use pixbuf loaders for all images,
> we're looking at switching). The fun part is that our own plugin only
> crashes in this way on our own distro.
Never looked too deep into this. But Debian seems to version symbols
in a way that would solve this kind of problems
(http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps). Since for any
precompiled binary this can happen with a lot of libraries this could
be something good to copy.
As a side effect it would also remove the need for macros as
"%kde4_runtime_requires" (in an ideal case).
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hello,
I wonder, if libdbi and libdbi-drivers could be moved from Contrib to
Factory. Reason: syslog-ng's database support is based libdbi. If
libdbi(-drivers) is moved to Factory, then database could be enabled as
part of the next release.
Bye,
--
Peter Czanik (CzP) <czanik(a)balabit.hu>
BalaBit IT Security / syslog-ng upstream
http://czanik.blogs.balabit.com/
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hello,
is this known?
I will only tell all the people the update server for SLE is broken last
night.
The bad thing is to reregister the system after a broken connect, zypper
disabled the repository :(.
--
mit freundlichen Grüßen / best Regards,
Günther J. Niederwimmer
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi,
The most annoying M2 bug is still not fixed (Xorg crashes) and I don't
consider releasing Milestone3 in this state useful ;(
So I will cancel Milestone3 and move it to hopefully next week. If we can't
get to the core of it, we may need to disable compositing use in KDE.
Greetings, Stephan
--
Sent from openSUSE
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org