[packman] 13.1 mplayer has no alsa
Hey packagers, something is broken in openSUSE_13.1/Essentials in that MPlayer-1.1.1+r36500 is lacking alsa support. `mplayer -ao help` won't show alsa anymore. The MPlayer-1.1.1+r36500-3.1 package in openSUSE_12.3/Essentials still has it. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Manual dependencies on ffmpeg: not good
On Tuesday 2012-06-19 21:56, Cristian Morales Vega wrote: >>> zypper does not want to update to ffmpeg-0.11[packman], because of some whacky manual dependencies that someone had added. Drilled down (minimal testcase), in rpm lingo,: >>> >>>make a "zypper dup", this should resolve. >> >> I do not consider that an ideal solution, because it replaces all >> packages by random vendors, depending on which repositories are enabled. > >I agree with you in the general problem >(http://lists.links2linux.de/pipermail/packman/2012-May/011142.html). >But dist-upgrade behavior isn't random -> >http://forums.opensuse.org/english/get-technical-help-here/ how-faq-forums/unreviewed-how-faq/ 474523-software-management-dist-upgrade-way.html Indeed the process is not "random", it was more a tongue-of-speek. Using different prios for oss and pm is out of the question since it would shift preference to one vendor, which is not what I want. However, since I do not want "highest-version" either, using dup in itself is off the table, since I prefer libgst*, even if it's older from SUSE, but e.g. xine/etc. from pm, also even if it's older. I suppose there are vendor locks, but that would amount to a management chore across multiple systems, so I just keep using regular "zypper update" and make use of the implicit vendor lock; anything specific is "zypper install"-forced. That may also lock out downgrades, but such occus seldomly anyway. It also locks out removals, but that generally does not occur at all in a normal life, especially not with shlib packages. It just was unfortunate that it however did in the ffmpeg case due to the dependencies. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Manual dependencies on ffmpeg: not good
On Sunday 2012-06-17 14:39, Manfred Tremmel wrote: >Am Dienstag, 12. Juni 2012, 18:01:39 schrieb Jan Engelhardt: >> My openSUSE_12.1 system currently has ffmpeg-0.9.1-1.1[packman], but > >ffmpeg 0.9.1 has been replaced in January, you realy should update to >the latest version. > >> zypper does not want to update to ffmpeg-0.11[packman], because of >> some whacky manual dependencies that someone had added. Drilled down >> (minimal testcase), in rpm lingo,: > >make a "zypper dup", this should resolve. I do not consider that an ideal solution, because it replaces all packages by random vendors, depending on which repositories are enabled. >> Installation of libavcodec54 would force libavdevice53 out the >> system, which is an operation that is penalized by zypper and thus >> not rejected for "zypper up". libavdevice53.rpm is set to depend on a >> specific libavutil51 version. That is not how library versioning is >> meant to be done. > >This is how to prevent from incompatiblities through out different >compiling options or other problems. In that case, I suggest using a separate provides/requires, e.g. Provides: libavcodec-tremmels-special-cflags = 12 ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] Manual dependencies on ffmpeg: not good
My openSUSE_12.1 system currently has ffmpeg-0.9.1-1.1[packman], but
zypper does not want to update to ffmpeg-0.11[packman], because of
some whacky manual dependencies that someone had added. Drilled down
(minimal testcase), in rpm lingo,:
# rpm -Uhv libavcodec54-0.11-4.1.x86_64.rpm error: Failed dependencies:
libavutil51 = 0.11 is needed by libavcodec54-0.11-4.1.x86_64
# rpm -Uhv libavcodec54-0.11-4.1.x86_64.rpm libavutil51-0.11-4.1.x86_64.rpm
error: Failed dependencies:
libavutil51 = 0.9.1-1.1 is needed by (installed)
libavdevice53-0.9.1-1.1.x86_64
Installation of libavcodec54 would force libavdevice53 out the
system, which is an operation that is penalized by zypper and thus
not rejected for "zypper up". libavdevice53.rpm is set to depend on a
specific libavutil51 version. That is not how library versioning is
meant to be done.
Solutions:
1. If avdevice53 really requires avutil51-0.9.1 (rather than any
avutil.so.51), the ffmpeg folks screwed up their ABI.
2. If the dependency is artificial, remove the manual deps and let
Automatic Dependency resolution do its job.
Kill all of those that look like:
Requires: %{libnameavcodec} = %{version}
Requires: %{libnameavdevice} = %{version}
Requires: %{libnameavformat} = %{version}
Requires: %{libnameavutil} = %{version}
Requires: %{libnamepostproc} = %{version}
Requires: %{libnameswscale} = %{version}
Requires: %{libnameswresample} = %{version}
Requires: %{libnameavresample} = %{version}
[there are more]
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] mplayer: ASS subtitle reader crash
The Bleachverse 343 720p MKV file triggers a crash in the ASS subtitle reader in MPlayer-34016 currently shipped by pm. Please consider updating to at least 34204 which has been found to have the issue resolved. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] OBS: Have choice between liborc et liborc
Greetings. openSUSE 11.3 has a package called liborc-0_4-0, while packman has one that is called liborc0_4-0. This causes OBS to rightfully stop a build with: have choice for liborc-test-0.4.so.0()(64bit) needed by orc: liborc-0_4-0 liborc0_4-0 Please unify the naming so that pm's package is called like the SUSE one. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] [PM] mpc (openSUSE 11.2/x86_64)
Hi, the mpd-client package "mpc" in Packman/11.2 collides with the multiprecision library "mpc" in home:rguenther for gcc45 (thus it will likely end up in a future openSUSE release). Could mpc be renamed to something else? I suggest "mpd-client". thanks, Jan ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] [PM] mpd 0.15.7-0.pm.1.1 (openSUSE 11.2/x86_64)
Hi, mpd's init script contains Required-Start: alsasound but this is pointless for servers where mpd merely streams to an icecast or similar. I therefor suggest X-Should-Start: alsasound instead. At the same time, X-Should-Start: icecast should also be present to try avoiding starting mpd before icecast. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] xine fails to play mkv
I don't quite see as to why that happens given mplayer can do it, and both project use the same libraries. http://jengelh.medozas.de/files/takeshi.mkv $ rpm -q libxine1 xine-ui libxine1-1.1.16.3-0.pm.3 xine-ui-0.99.5cvs-20090203.pm.0821 (opensuse 11.1) $ xine takeshi.mkv [mpeg4 @ 0x91196f0]header damaged ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] MPlayer mit neuerem ffmpeg?
Hallo, mit ffplay svn-r16647 (ffmpeg-0.4.9.16647svn-20090116.pm.2207) lassen sich TGV-Dateien von Electronic Arts abspielen, mit dem MPlayer (MPlayer-1.0rc2_r27637-3.pm.3) geht das bisher noch nicht. Wäre da evtl. ein Update möglich? ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] libfmodex..
On Sunday 2008-11-02 13:50, Toni wrote:
>Am Sonntag, 2. November 2008 schrieb Jan Engelhardt:
>> Hi,
>>
>> I am needing fmodex 4.18, but upon further examination I found that
>> fmod.org produces totally braindead .so files that are not correctly
>> versioned according to
>> http://www.nondot.org/sabre/Mirrored/libtool-2.1a/libtool_6.html
>>
>> So until they fixed it, it will be necessary to put different fmod
>> versions into different directories, e.g. %_libdir/fmodex-%version/
>> instead of %_libdir, and %_includedir/fmodex-%version/fmodex instead of
>> %_includedir/fmodex. Could you do this modification for the package?
>> (And maybe call it libfmodex420 instead)
>I downgraded/updated to 4.18.10
>
>for the upcoming 4.20.xx packages I'll try to follow your suggestions. I must
>check the packman repo for "users" of fmod and how they deal with includes
>and linking.
I simply did this for the time being with my specfiles (see attachment
- it's the 420, but 418 is just changing numbers).
Since fmod does not use pkg-config or a standalone script à la
"PACKAGENAME-config", it may be necessary to patch some projects
depending on fmod to allow specifying extra flags :-/
Well, the specific package I need it for actually uses cmake, which,
as I just learned, needs just
cmake . -DFMOD_INCLUDE_DIR=/opt/libfmodex418/include \
-DFMOD_LIBRARY=/opt/libfmodex418/lib64/libfmodex64.so.418
And I think that fares very well.
# Copyright (c) 2007-2008 oc2pus
# This file and all modifications and additions to the pristine
# package are under the same license as the package itself.
#
# Please submit bugfixes or comments to [EMAIL PROTECTED]
# norootforbuild
%define _prefix /usr
%define _version2 42000
%define _my_provides /tmp/my-provides
%define flibdir /opt/%name/%_lib
%define fincludedir /opt/%name/include
Summary:FMOD is a cross platform audio library and toolset
Name: libfmodex420
Version:4.20.00
Release:jen0
License:see LICENSE.TXT
Group: Development/Libraries/C and C++
%ifnarch x86_64
Source0:
http://www.fmod.org/index.php/release/version/fmodapi%{_version2}linux.tar.gz
Source1:
http://www.fmod.org/index.php/release/version/fmodapi%{_version2}linux64.tar.gz
%else
Source1:
http://www.fmod.org/index.php/release/version/fmodapi%{_version2}linux.tar.gz
Source0:
http://www.fmod.org/index.php/release/version/fmodapi%{_version2}linux64.tar.gz
%endif
Url:http://www.fmod.org/
BuildRoot: %{_tmppath}/%{name}-%{version}-build
Obsoletes: fmod <= 4.06.20
Provides: fmod = 4.06.20
%description
FMOD is a cross platform audio library and toolset to let you easily
implement the latest audio technologies into your title.
The FMOD Ex sound system is a revolutionary new audio engine for
game developers, multimedia developers, sound designers, musicians
and audio engineers, based on the years of experienced of Firelight
Technologies(tm) previous product FMOD.
It also aims high - to push the boundaries of audio implementation
for games and the like while at the same time using minimal resources
and being scalable. This new engine is written from the ground up
since FMOD 3 was released and involves years of experience and
feedback from FMOD users to create the most feature filled and easy
to use product possible, without the rawbacks of legacy
implementation that FMOD 3 may have suffered from its years of
continuous development.
Copyright (c) Firelight Technologies, Pty, Ltd, 2004-2007
%package designerapi
Summary:FMODex Designer
Group: Development/Libraries/C and C++
Requires: libfmodex420 = %{version}
%description designerapi
FMODex Designer.
%package devel
Summary:Development package for the FMODex library
Group: Development/Languages/C and C++
Requires: libfmodex420 = %{version}
%description devel
Development package for the FMODex library.
%prep
%ifnarch x86_64
%setup -q -n fmodapi%{_version2}linux
%else
%setup -q -n fmodapi%{_version2}linux64
%endif
%__sed -i -e 's|ldconfig|#ldconfig|g' \
Makefile
%build
%install
%__install -dm 755 %{buildroot}%{flibdir}
%__install -dm 755 %{buildroot}%{fincludedir}/fmodex
%makeinstall \
DESTLIBDIR=%{buildroot}%{flibdir} \
DESTHDRDIR=%{buildroot}%{fincludedir}/fmodex
# install *.hpp (Makefile broken)
%ifarch x86_64
%__install -dm 755 %{buildroot}%{fincludedir}/fmodex
%__install -m 644 api/inc/*.hpp \
%{buildroot}%{fincludedir}/fmodex
%endif
pushd %{buildroot}%{flibdir}
%ifnarch x86_64
%__rm -f libfmodex.so
%__rm -f libfmodexp.so
ln -s libfmodex.so.%{version} libfmodex.so
ln -s libfmodexp.so.%{version} libfmodexp.so
ln -s libfmodex.so.%{version} libfmodex.s
[packman] libfmodex..
Hi, I am needing fmodex 4.18, but upon further examination I found that fmod.org produces totally braindead .so files that are not correctly versioned according to http://www.nondot.org/sabre/Mirrored/libtool-2.1a/libtool_6.html So until they fixed it, it will be necessary to put different fmod versions into different directories, e.g. %_libdir/fmodex-%version/ instead of %_libdir, and %_includedir/fmodex-%version/fmodex instead of %_includedir/fmodex. Could you do this modification for the package? (And maybe call it libfmodex420 instead) thanks, Jan ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] mpg123 broken
Hi, kurzer Bugreport: >> mpg123 blafasel.mp3 [module.c:110] error: Failed to open module alsa: file not found [module.c:110] error: Failed to open module oss: file not found [module.c:110] error: Failed to open module esd: file not found [module.c:110] error: Failed to open module jack: file not found [module.c:110] error: Failed to open module portaudio: file not found [module.c:110] error: Failed to open module pulse: file not found [module.c:110] error: Failed to open module sdl: file not found [module.c:110] error: Failed to open module nas: file not found [module.c:110] error: Failed to open module arts: file not found [audio.c:179] error: Unable to find a working output module in this list: alsa,oss,esd,jack,portaudio,pulse,sdl,nas,arts [audio.c:463] error: Failed to open audio output module [mpg123.c:757] error: Failed to initialize output, goodbye. >> rpm -q mpg123 mpg123-1.4.2-0.pm.1 Das ging mal mit einer vorigen Version... ___ Packman mailing list Packman@links2linux.de http://212.112.227.138/cgi-bin/mailman/listinfo/packman
[packman] Re: wxWidgets - Aprilvirus?
On Saturday 2008-04-05 14:08, Toni wrote:
das kann's ja nicht sein. Wer kommt denn auf die Idee, im Specfile
tausen Requires: einzufügen, die überhaupt nicht gebraucht werden - wozu
gibt es denn AutoReqProv?
doch genau das kann es sein...
jedes Paket welches wxWidgets-devel anzieht müsste sonst immer daran denken
die anderen ebenfalls als BuildRequires anzugeben. You See ?
Mag ja für dich vielleicht so sein, aber dass hier viele Pakete
deswegen reintrudeln ist nicht nett, zumal das original-SUSE-Paket
das ja auch nicht macht.
libpng-devel definitiv schonmal nicht. Oder wo ist #include in
/usr/include/wx-2.8 zu finden? Die Tatsache dass all diese Pakete mit
der vorigen .pm.-Version nicht notwendig waren gibt es keinen
Anhaltspunkt dass dies nun notwendig wäre.
und ob libpng-devel direkt von wxWidgets gebraucht wird, sei mal
dahingestellt, es liegt in diesem Fall aber daran das ein anderes *-devel
Paket eben nicht als Requires: libpng-devel angibt und es somit zu einem
compile/linker error kommt. Deshalb hat mein wxWidgets Paket eben
libpng-devel als Requires.
Und... das {andere} Paket zu korrigieren, ist keine annehmbare Lösung?
Wenn denn schon, dann mach doch ein Metapackage das da folgendes
enthält
Name: wxGTK-inter-devel
Essentialfor/Supplements: wxGTK-devel
Requires: alles-devel
dann kann man nämlich die inter-devel notfalls blacklisten.
___
Packman mailing list
Packman@links2linux.de
http://212.112.227.138/cgi-bin/mailman/listinfo/packman
[packman] wxWidgets - Aprilvirus?
Infolge des -rw-r--r-- 1 455 5200 11457785 Apr 1 20:05 wxWidgets-devel-2.8.7.1-0.pm.1.i586.rpm -Updates ist mir wohl ein Aprilvirus reingekommen: # smart upgrade --update ... Installing packages (25): avahi-devel libbonobo-devel libidl-devel dbus-1-devel libbonoboui-devel libmspack-devel dbus-1-glib-devel libcom_err-devel libusb-devel gail-devellibext2fs-devel libuuid-devel gconf2-devel libgnome-develorbit2-devel gnome-keyring-devel libgnomecanvas-devel unixODBC-devel gnome-vfs2-devel libgnomeprint-devel wxWidgets-gl-compat hal-devel libgnomeprintui-devel libblkid-devellibgnomeui-devel das kann's ja nicht sein. Wer kommt denn auf die Idee, im Specfile tausen Requires: einzufügen, die überhaupt nicht gebraucht werden - wozu gibt es denn AutoReqProv? Requires: gtk2-devel Requires: gnome-vfs2-devel Requires: libgnomeprintui-devel Requires: libpng-devel Requires: libjpeg-devel Requires: libmspack-devel Requires: libtiff-devel Requires: unixODBC-devel libpng-devel definitiv schonmal nicht. Oder wo ist #include in /usr/include/wx-2.8 zu finden? Die Tatsache dass all diese Pakete mit der vorigen .pm.-Version nicht notwendig waren gibt es keinen Anhaltspunkt dass dies nun notwendig wäre. Bitte um Lösung des Problems. ___ Packman mailing list Packman@links2linux.de http://212.112.227.138/cgi-bin/mailman/listinfo/packman
