Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 18 July 2011 22:37, Luc Menut lme...@free.fr wrote:
Le 13/07/2011 12:41, Ahmad Samir a écrit :
On 13 July 2011 12:34, nicolas vigierbo...@mars-attacks.org wrote:
On Wed, 13 Jul 2011, Ahmad Samir wrote:
...
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
I think it's better to use %{name}-devel for packages which don't have
pkgconfig files. And keep pkgconfig() provides for packages with .pc
files.
As spturtle said, conformity/consistency is good, i.e. all our
packages should have the same Provides, that's better in the long run,
and less confusing for new (and old too) packagers.
Couldn't we have a macro for this? It would help in consistency, and will
avoid typo.
We could use it like this:
%mkdevelprov %{name} %{version}
regards,
Luc
Good point. There'll be corner cases, but it should work for the
majority of packages.
--
Ahmad Samir
Re: [Mageia-dev] Where is the KDE WM ?
On 18 July 2011 21:48, Balcaen John mik...@mageia.org wrote: On Saturday 16 July 2011 11:06:59 Ahmad Samir wrote: [...] Interesting, that method never really worked before (or at least I never tested it). It worked since mikala added http://svnweb.mageia.org/packages/cauldron/kdebase4-runtime/current/SOURCES/ kdebase-runtime-4.6.0-fedora-support-for-compiz.patch, IIUC. Well i guess it's probably more related to the 0.8.8 we can read in the changelog (available in /usr/share/compiz/NEWS ...) Fixed drawing of switcher background with KDE4 window decorator And as far as i remember it was not working under Mageia 1( this patch was already available). Regards, -- Balcaen John I didn't test, (I don't use compiz); However, it can't work without that patch, the Exec line was wrong. -- Ahmad Samir
Re: [Mageia-dev] Cleaning orphans from the mirrors
I would suggest that if all the packages have been rebuilt, the orphan packages be removed im
[Mageia-dev] autopano-sift-C ought to be in tainted, instead of core repository
/ What are the patents number ? // / I was under the impression thathttp://www.google.com/patents?vid=6711293 is related to it, but I am not sure. That's it ! Though the author is a University professor and the owner a University, and we may suppose they won't pursue authors and distibutors of an opensource project, it is patented !
[Mageia-dev] An Mageia-made RPM of cross-mipsel-binutils is wished for ASAP
I'm asking politely to have the latest version from ftp://ftp.kernel.org/pub/linux/devel/binutils/ released as an official Mageia-RPM in the repos. Is that possible? I made a bugreport about it here: https://bugs.mageia.org/show_bug.cgi?id=1990 Thank you for reading /Kristoffer
Re: [Mageia-dev] Updates process is now available
Could we add a keyword validated_update to bugs that are ready to be moved to updates, so they can be found easily ? That would be useful indeed, the number of update candidates is growing and it's not easy to differentiate those who need testing and those who need to be pushed. Samuel Yep, can we add this ? -- Manuel Hiebel (leuhmanu)
[Mageia-dev] FYI: telepathy-farsight has been renamed to telepathy-farstream upstream
Hello, telepathy-farsight has been renamed to telepathy-farstream upstream. It's required by empathy to have call support. However some other packages (telepathy-qt4 and telepathy-call-ui) still use the old -farsight, so renaming the current package in SVN will render those two packages not build-able, until their perspective upstream adapt to the changes. So I'll copy telepathy-farsight to -farstream is SVN and submit it as a separate package, then when it's not needed any more we can add the proper obsoletes against telepathy-farsight. -- Ahmad Samir
Re: [Mageia-dev] FYI: telepathy-farsight has been renamed to telepathy-farstream upstream
On 19 July 2011 11:45, Ahmad Samir ahmadsamir3...@gmail.com wrote: Hello, telepathy-farsight has been renamed to telepathy-farstream upstream. It's required by empathy to have call support. However some other packages (telepathy-qt4 and telepathy-call-ui) still use the old -farsight, so renaming the current package in SVN will render those two packages not build-able, until their perspective upstream adapt to the changes. So I'll copy telepathy-farsight to -farstream is SVN and submit it as a separate package, then when it's not needed any more we can add the proper obsoletes against telepathy-farsight. -- Ahmad Samir FWIW, on further investigation, empathy still checks for telepathy-farsight, which doesn't make sense; (I'll try patching it). -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release mplayer-1.0-1.rc4.0.r32713.7.mga2
On 18.07.2011 13:57, Ahmad Samir wrote: On 18 July 2011 12:45, Samuel Verschelde sto...@laposte.net wrote: Le lundi 18 juillet 2011 11:26:34, Ahmad Samir a écrit : On 18 July 2011 10:51, Samuel Verschelde samuel.versche...@pmsipilot.com wrote: Le lundi 18 juillet 2011 10:11:32, Mageia Team a écrit : Name: mplayer Relocations: (not relocatable) Version : 1.0 Vendor: Mageia.Org Release : 1.rc4.0.r32713.7.mga2 Build Date: Mon Jul 18 09:51:27 2011 Install Date: (not installed) Build Host: ecosse Group : Video Source RPM: (none) Size: 8890529 License: GPLv2 Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.mplayerhq.hu Summary : Movie player for linux Description : MPlayer is a movie player for LINUX (runs on many other Unices, and non-x86 CPUs, see the documentation). It plays most MPEG, VOB, AVI, VIVO, ASF/WMV, QT/MOV, FLI, NuppelVideo, yuv4mpeg, FILM, RoQ, and some RealMedia files, supported by many native, XAnim, and Win32 DLL codecs. You can watch VideoCD, SVCD, DVD, 3ivx, FLI, and even DivX movies too (and you don't need the avifile library at all!). The another big feature of mplayer is the wide range of supported output drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, AAlib, but you can use SDL (and this way all drivers of SDL), VESA (on every VESA compatible card, even without X!), and some lowlevel card-specific drivers (for Matrox, 3Dfx and Radeon) too! Most of them supports software or hardware scaling, so you can enjoy movies in fullscreen. MPlayer supports displaying through some hardware MPEG decoder boards, such as the DVB and DXR3/Hollywood+! And what about the nice big antialiased shaded subtitles (9 supported types!!!) with european/ISO 8859-1,2 (hungarian, english, czech, etc), cyrillic, korean fonts, and OSD? Note: If you want to play Real content, you need to have the content of RealPlayer's Codecs directory in /usr/lib64/codecs/ Is it ok to have such a path (/usr/lib64/codecs/) in a summary ? Yes, because it's /usr/lib64/ in the x86_64 package and /usr/lib/ in the i586 one. (I think the email to the changelog ML resolves %_libdir/ depending on the machine that generated the email, not sure though). I'm not fond of descriptions changing according to the arch, it makes my life harder in madb where I need one description per package name (tainted packages are already problematic in this regard) :) Samuel Whether this causes problems for other tools or not, that bit of the description is giving users useful info. Maybe it can be moved to a README.urpmi, Anssi? IMO it can be removed, Real content plays fine without real-codecs (which is non-redistributable). -- Anssi Hannula
Re: [Mageia-dev] FYI: telepathy-farsight has been renamed to telepathy-farstream upstream
On 19 July 2011 13:38, Ahmad Samir ahmadsamir3...@gmail.com wrote:
On 19 July 2011 11:45, Ahmad Samir ahmadsamir3...@gmail.com wrote:
Hello,
telepathy-farsight has been renamed to telepathy-farstream upstream.
It's required by empathy to have call support. However some other
packages (telepathy-qt4 and telepathy-call-ui) still use the old
-farsight, so renaming the current package in SVN will render those
two packages not build-able, until their perspective upstream adapt to
the changes.
So I'll copy telepathy-farsight to -farstream is SVN and submit it as
a separate package, then when it's not needed any more we can add the
proper obsoletes against telepathy-farsight.
--
Ahmad Samir
FWIW, on further investigation, empathy still checks for
telepathy-farsight, which doesn't make sense; (I'll try patching it).
--
Ahmad Samir
For the sake of not botching the package, I think it'll build/work
with both telepathy-{farsight,farstream}; the latter being used for
Empathy call support.
--
Ahmad Samir
[Mageia-dev] maven packages not replacing older ones - conflict results
[root@ftgme2 ftg]# urpmi --auto-select --debug getting lock on urpmi parsing: /etc/urpmi/mediacfg.d/Devel-1-x86_64 examining synthesis file [/var/lib/urpmi/Core Release/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core Release Debug/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core Updates/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Release/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Release Debug/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Updates/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Release/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Release Debug/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core 32bit Release/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core 32bit Release Debug/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core 32bit Updates/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/plf-nonfree/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/plf-free/synthesis.hdlist.cz] skipping package lib64freetype6-2.4.4-3plf-plf2011.0.x86_64 skipping package freetype2-demos-2.4.4-3plf-plf2011.0.x86_64 skipping package freetype2-demos-2.4.4-4plf-plf2011.0.x86_64 skipping package lib64freetype6-devel-2.4.4-4plf-plf2011.0.x86_64 skipping package lib64freetype6-devel-2.4.4-3plf-plf2011.0.x86_64 skipping package lib64freetype6-static-devel-2.4.4-4plf-plf2011.0.x86_64 skipping package lib64freetype6-2.4.4-4plf-plf2011.0.x86_64 skipping package lib64freetype6-static-devel-2.4.4-3plf-plf2011.0.x86_64 getting exclusive lock on rpm opening rpmdb (root=, write=) auto-select: adding empathy-3.1.3-1.mga2.x86_64 replacing empathy-3.1.2.1-1.mga2.x86_64 auto-select: adding maven2-2.2.1-72.mga2.noarch replacing maven2-2.2.1-70.mga1.noarch auto-select: adding java-rpmbuild-1.7.5-13.mga2.x86_64 replacing java-rpmbuild-1.7.5-5.mga1.x86_64 auto-select: adding gnome-control-center-3.1.3-6.mga2.x86_64 replacing gnome-control-center-3.1.3-5.mga2.x86_64 auto-select: adding db51-utils-5.1.25-5.mga2.x86_64 replacing db51-utils-5.1.19-6.mga1.x86_64 selecting maven2-2.2.1-72.mga2.noarch set_rejected: maven2-2.2.1-70.mga1.noarch requiring maven-artifact-manager[== 2.2.1-72.mga2],maven-monitor[== 2.2.1-72.mga2],maven-plugin-registry[== 2.2.1-72.mga2],maven-profile[== 2.2.1-72.mga2],maven-project[== 2.2.1-72.mga2],maven-toolchain[== 2.2.1-72.mga2] for maven2-2.2.1-72.mga2.noarch chosen maven-artifact-manager-2.2.1-72.mga2.noarch for maven-artifact-manager[== 2.2.1-72.mga2] selecting maven-artifact-manager-2.2.1-72.mga2.noarch chosen maven-toolchain-2.2.1-72.mga2.noarch for maven-toolchain[== 2.2.1-72.mga2] selecting maven-toolchain-2.2.1-72.mga2.noarch chosen maven-monitor-2.2.1-72.mga2.noarch for maven-monitor[== 2.2.1-72.mga2] selecting maven-monitor-2.2.1-72.mga2.noarch chosen maven-project-2.2.1-72.mga2.noarch for maven-project[== 2.2.1-72.mga2] selecting maven-project-2.2.1-72.mga2.noarch requiring maven-plugin-registry,maven-profile for maven-project-2.2.1-72.mga2.noarch selecting maven-profile-2.2.1-72.mga2.noarch selecting maven-plugin-registry-2.2.1-72.mga2.noarch chosen maven-profile-2.2.1-72.mga2.noarch for maven-profile[== 2.2.1-72.mga2] chosen maven-plugin-registry-2.2.1-72.mga2.noarch for maven-plugin-registry[== 2.2.1-72.mga2] selecting java-rpmbuild-1.7.5-13.mga2.x86_64 set_rejected: java-rpmbuild-1.7.5-5.mga1.x86_64 selecting empathy-3.1.3-1.mga2.x86_64 set_rejected: empathy-3.1.2.1-1.mga2.x86_64 requiring libtelepathy-farstream.so.0()(64bit) for empathy-3.1.3-1.mga2.x86_64 chosen lib64telepathy-farstream0-0.1.1-1.mga2.x86_64 for libtelepathy-farstream.so.0()(64bit) selecting lib64telepathy-farstream0-0.1.1-1.mga2.x86_64 selecting gnome-control-center-3.1.3-6.mga2.x86_64 set_rejected: gnome-control-center-3.1.3-5.mga2.x86_64 To satisfy dependencies, the following packages are going to be installed: PackageVersion Release Arch (medium Core Release) empathy3.1.31.mga2x86_64 gnome-control-center 3.1.36.mga2x86_64 java-rpmbuild 1.7.513.mga2 x86_64 lib64telepathy-farstream0 0.1.11.mga2x86_64 maven-artifact-manager 2.2.172.mga2 noarch maven2 2.2.172.mga2 noarch (medium Core 32bit Release) maven-monitor 2.2.172.mga2 noarch maven-plugin-registry 2.2.172.mga2 noarch maven-profile 2.2.172.mga2 noarch maven-project 2.2.172.mga2 noarch maven-toolchain2.2.172.mga2 noarch 1.1MB of additional disk space will be used. 6.8MB of packages will be retrieved. Proceed with the
Re: [Mageia-dev] maven packages not replacing older ones - conflict results
On 07/19/2011 12:08 PM, Frank Griffin wrote: auto-select: adding maven2-2.2.1-72.mga2.noarch replacing maven2-2.2.1-70.mga1.noarch Actually, it looks like it *is* supposed to replace, so why the conflicts ?
Re: [Mageia-dev] maven packages not replacing older ones - conflict results
On 19.07.2011 19:13, Frank Griffin wrote: On 07/19/2011 12:08 PM, Frank Griffin wrote: auto-select: adding maven2-2.2.1-72.mga2.noarch replacing maven2-2.2.1-70.mga1.noarch Actually, it looks like it *is* supposed to replace, so why the conflicts ? dmorgan forgot to add conflicts entries when he moved files between packages. -- Anssi Hannula
[Mageia-dev] CUDA in Mageia vs compilers
Hi, all... As everybody else, I want to suggest some things for Mageia. One is just a simple update request, that could have gone through bugzilla, but it is closely related to the other... My suggestions: - update CUDA to 4.0 (easy) - (not so easy) As today, CUDA does not work with gcc-4.5 and upwards. In madriva there is a gcc42 package, but that has not been imported to Mageia, and anyways looks a bit old. So in short CUDA is unusable in mageia nowadays. What I propose is to have a gcc4 package, that contains the latest gcc-4.x.y (currently 4.4.6). Then we could setup things in CUDA to use that gcc instead of standard (I did it for myself but can try at system level). At least c,c++ and fortran would be usefull in that package. How hard would this be ? How complicated is to have two full compilers+libraries in a system ? Current gcc is already installed as gcc-4.5.2 and uses alternatives, but not so fortran and others... Do you see any other solution ? Thanks for your attention... -- J.A. Magallon jamagallon()ono!com \ Winter is coming...
Re: [Mageia-dev] maven packages not replacing older ones - conflict results
On Tue, Jul 19, 2011 at 6:15 PM, Anssi Hannula anssi.hann...@iki.fi wrote: On 19.07.2011 19:13, Frank Griffin wrote: On 07/19/2011 12:08 PM, Frank Griffin wrote: auto-select: adding maven2-2.2.1-72.mga2.noarch replacing maven2-2.2.1-70.mga1.noarch Actually, it looks like it *is* supposed to replace, so why the conflicts ? dmorgan forgot to add conflicts entries when he moved files between packages. -- Anssi Hannula my bad :/ i will fix this thank you
Re: [Mageia-dev] [RPM] cauldron nonfree/release flash-player-plugin11-11.0.1.60-0.b1.071311.1.mga2.nonfree
Just in case it catches anyone out, this new flash version does not record sound properly via PulseAudio. It outputs to PulseAudio fine, so it's just the input layer that's f**ked. Flash never was very good with it's audio handling :( I've reported it upstream: http://bugs.adobe.com/jira/browse/FP-7441 Col. -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] kernel 2.6.38.8 and ATI radeon
Le mardi 19 juillet 2011 18:29:08, Alberto Girlando a écrit : I am not sure I have to post here or make a bug report, but I have seen some discussion on the new kernel. Always do a bug report. System: 64-bit Upgraded from Mandriva via internet (no problem) When I upgraded to the kernel 2.6.38.8, the proprietary driver was not installed. I went to the Diplay, my ATI HD 2000 was recognized, and I was asked if I wanted to use the proprietary driver. I answered yes, but nothing apparently happened, and indeed, the driver is not in use, and I cannot access 3D effects. This of course did not happened with the previous kernel. We'll need more information : exact model of Radeon, etc.
Re: [Mageia-dev] FYI: telepathy-farsight has been renamed to telepathy-farstream upstream
Ahmad Samir a écrit : On 19 July 2011 11:45, Ahmad Samirahmadsamir3...@gmail.com wrote: Hello, telepathy-farsight has been renamed to telepathy-farstream upstream. It's required by empathy to have call support. However some other packages (telepathy-qt4 and telepathy-call-ui) still use the old -farsight, so renaming the current package in SVN will render those two packages not build-able, until their perspective upstream adapt to the changes. So I'll copy telepathy-farsight to -farstream is SVN and submit it as a separate package, then when it's not needed any more we can add the proper obsoletes against telepathy-farsight. -- Ahmad Samir FWIW, on further investigation, empathy still checks for telepathy-farsight, which doesn't make sense; (I'll try patching it). Couldn't we package telepathy-farstream with a provides telepathy-farsight to get around this problem ? (As was done with rarian for scrollkeeper.) Or are they incompatible ? -- André
[Mageia-dev] Packaging Mentors wanted
Hello everybody, We have 2 potential packager apprentices ... who have been waiting already 2 weeks. One has experiences including informal MDV packaging, and developing an open source game. The other is interested in console and associated packages among other things. More info at http://www.mageia.org/wiki/doku.php?id=packages_mentoring#packager_apprentice_table Any qualified Mageia packager willing to help out by mentoring an apprentice would be much appreciated. Regards :) -- André
