Re: [Mageia-dev] [126688] - 0.94
On 19 July 2011 21:12, r...@mageia.org wrote:
Revision 126688 Author cjw Date 2011-07-19 21:12:55 +0200 (Tue, 19 Jul 2011)
Log Message
- 0.94
Modified Paths
cauldron/dbus-glib/current/SPECS/dbus-glib.spec
Modified: cauldron/dbus-glib/current/SPECS/dbus-glib.spec
===
--- cauldron/dbus-glib/current/SPECS/dbus-glib.spec 2011-07-19 19:12:47 UTC
(rev 126687)
+++ cauldron/dbus-glib/current/SPECS/dbus-glib.spec 2011-07-19 19:12:55 UTC
(rev 126688)
@@ -1,13 +1,6 @@
-#if %mandriva_branch == Cooker
-# Cooker
-%define release %mkrel 2
-#%else
-# Old distros
-#define subrel 2
-#define release %mkrel 1
-#endif
-%define glib2_version 2.6.0
-%define dbus_version 0.94
+%define release %mkrel 1
+%define glib2_version 2.26.0
+%define dbus_version 1.2.16
%define lib_major 2
%define lib_api 1
@@ -18,13 +11,12 @@
Summary: D-Bus message bus
Name: dbus-glib
-Version: 0.88
+Version: 0.94
Release: %release
URL: http://www.freedesktop.org/Software/dbus
Source0:
http://dbus.freedesktop.org/releases/%name/%{name}-%{version}.tar.gz
License: AFL and GPLv2
Group: System/Libraries
-BuildRoot: %{_tmppath}/%{name}-%{version}-root
BuildRequires: glib2-devel = %{glib2_version}
BuildRequires: dbus-devel = %{dbus_version}
BuildRequires: libxml2-devel
@@ -63,7 +55,7 @@
%setup -q
%build
-
+autoreconf -fi
Hello,
The issue or running autoreconf in spec files is still unresolved, either:
- We only run it when needed (i.e. a patch that modifies configure.ac,
Makefile.{am,in}, building with a newer/older libtool) OR
- We run it in all the specs of packages that use libtool
Right now in most specs we only run it when needed, except some specs
you modified (like this one).
I am not with or against (don't have enough knowledge about libtool),
just pointing out that if autoreconf should be run for all packages
using libtool, then the policy should be clarified and applied to all
specs.
%configure2_5x \
--disable-tests \
--disable-verbose-mode \
@@ -99,9 +91,9 @@
%{_libdir}/pkgconfig/dbus-glib-%{lib_api}.pc
%{_includedir}/dbus-1.0/dbus/dbus-glib-bindings.h
%{_includedir}/dbus-1.0/dbus/dbus-gtype-specialized.h
-%{_includedir}/dbus-1.0/dbus/dbus-glib-error-enum.h
%{_includedir}/dbus-1.0/dbus/dbus-glib-lowlevel.h
%{_includedir}/dbus-1.0/dbus/dbus-glib.h
+%{_includedir}/dbus-1.0/dbus/dbus-gvalue-parse-variant.h
%{_datadir}/gtk-doc/html/dbus-glib/
%{_mandir}/man1/*
--
Ahmad Samir
Re: [Mageia-dev] Problems with dbus
On 5 August 2011 00:23, JA Magallon jamagal...@ono.com wrote: Hi... I'm on limited internet connection, so I'll be quick and dirty. Plz, take a look at this mdv bug: https://qa.mandriva.com/show_bug.cgi?id=63728 (copy) the problem is a bug in libdbus-glib-1_2 package, it is necessary a Debian patch http://patch-tracker.debian.org/package/dbus-glib/0.94-4 I suffer it for Usb modem, and mdv package made it work. Probably hurts more apps... Patch added from upstream GIT https://bugs.freedesktop.org/show_bug.cgi?id=37852 (same patch). Please test. (I didn't see any rebuild of network*manager-* in Debian, so I am not sure a rebuild is required). And a bug report would have worked to track the issue. -- Ahmad Samir
Re: [Mageia-dev] Audio Warning: New PulseAudio test release on the way....
2011/8/3 Kira elegant.pega...@gmail.com: 在 Wed, 03 Aug 2011 18:29:10 +0800, Colin Guthrie mag...@colin.guthr.ie寫道: Worrying! Is this localized at all? If so what language? Traditional Chinese...Sorry... It means sampling cache size: 0B Can you supply: sudo fuser -v /dev/snd/* /dev/snd/controlC0: kira 3001 F kde4 kira 3216 F kmix /dev/snd/pcmC0D1p: kira 3695 F...m amarok and pulseaudio -k; pulseaudio -v 1. E: main.c: unable to terminate background program: No such process exist. 2. as in the attachment, but still some localized message inside. Sorry. output? (for the second one, you may have to do: echo autospawn=no ~/.pulse/client.conf in order for it to actually start on the command line and not be autospawned by something else!) Put LC_ALL=C before any command and the output will be in English, e.g.: LC_ALL=C urpmi --auto-update -- Ahmad Samir
Re: [Mageia-dev] Switching VT when in GDM causes X11 quit with fatal error.
On 30 July 2011 14:07, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Ahmad Samir at 29/07/11 19:21 did gyre and gimble: On 28 July 2011 13:25, Colin Guthrie mag...@colin.guthr.ie wrote: [...] Note: systemd doesn't seem to give me a console login - so this is only with regular init - I presume I need to add a symlink somewhere to get regular console logins with systemd :) I'll look into that later. Col Check if plymouth hasn't still exited 'ps aux | grep plymouth'. That seems to be the issue. Killing that process allows systemd to give me my logins. I presume this a known bug/problem? Is anyone looking at it? I hit that issue when I switched to systemd, I didn't look further as I killed plymouth on my box (as usual). 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/] -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release polkit-kde-kcmodules-1-0.98.1-1.mga2
On 28 July 2011 07:25, Mageia Team buildsystem-dae...@mageia.org wrote: Name : polkit-kde-kcmodules-1 Relocations: (not relocatable) Version : 0.98.1 Vendor: Mageia.Org Release : 1.mga2 Build Date: Thu Jul 28 07:21:22 2011 Install Date: (not installed) Build Host: jonund Group : Graphical desktop/KDE Source RPM: (none) Size : 30057 License: GPL Signature : (none) Packager : Mageia Team http://www.mageia.org URL : https://projects.kde.org/projects/extragear/base/polkit-kde-kcmodules-1 Summary : PolicyKit KDE Configuration Description : Set of configuration modules which allows administrator to change polkit settings. ze ze 0.98.1-1.mga2: + Revision: 130049 - imported package polkit-kde-kcmodules-1 This package shouldn't provide polkit-agent: $ urpmq --provides polkit-kde-kcmodules polkit-agent [...] it doesn't include a polkit authentication agent, AFAICS. -- Ahmad Samir
Re: [Mageia-dev] Switching VT when in GDM causes X11 quit with fatal error.
On 28 July 2011 13:25, Colin Guthrie mag...@colin.guthr.ie wrote: [...] Note: systemd doesn't seem to give me a console login - so this is only with regular init - I presume I need to add a symlink somewhere to get regular console logins with systemd :) I'll look into that later. Col Check if plymouth hasn't still exited 'ps aux | grep plymouth'. -- 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/] -- Ahmad Samir
Re: [Mageia-dev] Updates and 0 release
On 26 July 2011 13:22, Luc Menut lme...@free.fr wrote: Le 26/07/2011 12:40, Michael Scherer a écrit : Hi, while trying to work on the queue of update needing a push, I noticed that almost all of them use a Release: 0. Since this has a specific meaning ( ie, used for pre release, or svn snapshot ), using this for updates is quite confusing, and I do not see the reason for that. When it is used for prerelease (mainly in cauldron), the release 0 is usually associated with a svn or git rev. number, or date, or alpha, beta ... so it is not so much confusing with this use in update for official release. Exactly. (And I didn't see any users getting confused by that all those years in mdv). If the goal is to be sure that the software is still upgradable, the whole %mkrel stuff should take care of that. And if not, we can rebuild in cauldron to increase the release. We regularly used release 0 and subrel 1 in Mdv for the packages updated with the same version in official releases and in cooker (firefox, thunderbird, java-1.6.0-sun, ...), to be sure that the package from the official release will be updated by a update to the devel release or the next official release. we often used in such packages: %if %mandriva_branch == Cooker # Cooker %define release %mkrel 1 %else # Old distros %define subrel 1 %define release %mkrel 0 %endif regards, Luc Agreed. Besides, one can simply forget to bump the rel in Cauldron and the issue will lay dormant until the next distro release is out and upgrades fail, worse if the package is on the DVD and users get the infamous urpmi-casacading-failure. -- Ahmad Samir
[Mageia-dev] The triage team.
Hello, Due to time constraints I have to leave the bug triage team. I'll still try to keep up with the bugs list when I have the time but won't be able primarily work on it. Thanks. -- Ahmad Samir
Re: [Mageia-dev] Need mentor(s) to become a Mageia packager
On 21 July 2011 22:14, Vincent vincent.hervi...@gmail.com wrote: Hi All, I am still trying to pack ZoneMinder for Cauldron. Now rpms are generated and rpmlint is not complaining, but I am still sure, it's not OK :) , that's why I need help. Attached is the spec file, if somebody could have a look. Here are my questions: - where should go the installed files? (Zoneminder provides perl modules, the site itself, CGI services , doc and conf). - some files have no path's variable: /usr/share/man/lib/perl5/5.14.1/x86_64-linux-thread-multi/perllocal.pod.xz /usr/local/share/man/man3/ZoneMinder.3pm ... Any idea, what it should be? - what should be the permissions for the site under the apache server? - should the %install section creates the database table/permissions for ZoneMinder? If so, is there any example how to achieve this? - should the %install section creates the service launcher scripts? If so, is there any example how to achieve this? Thanks in advance for you help! Vincent FWIW, Fedora has a zoneminder package http://pkgs.fedoraproject.org/gitweb/?p=zoneminder.git They've had it for a long time, so you should find loads of clues over there. -- Ahmad Samir
Re: [Mageia-dev] Need mentor(s) to become a Mageia packager
On 22 July 2011 07:43, Vincent vincent.hervi...@gmail.com wrote:
On 07/22/2011 01:46 AM, Michael Scherer wrote:
Le jeudi 21 juillet 2011 à 16:14 -0400, Vincent a écrit :
Hi All,
I am still trying to pack ZoneMinder for Cauldron.
Now rpms are generated and rpmlint is not complaining, but I am still
sure, it's not OK :) , that's why I need help.
Attached is the spec file, if somebody could have a look.
Here are my questions:
- where should go the installed files? (Zoneminder provides perl
modules, the site itself, CGI services , doc and conf).
conf - /etc/ . I would try to see how does others distribution, to have
at least a similar path to ease the work of people changing distribution
site - /var/www/zoneminder. Outside of the webroot, so people can
modify it with apache configuration
apache configuration - /etc/httpd/conf.d/webapps.d/ , iirc
perl module - like the other ( maybe jq can tell us the details )
cgi - I think there is something in /usr/lib/cgi-bin, not sure. I guess
checking other cgi would help.
I don't have a /usr/lib/cgi-bi, but I have a /var/www/cgi-bin. Can I put
them into /var/www/cgi-bin/Zonedaemon ?
doc - /usr/sharedoc, marked as such with %doc
- some files have no path's variable:
/usr/share/man/lib/perl5/5.14.1/x86_64-linux-thread-multi/perllocal.pod.xz
/usr/local/share/man/man3/ZoneMinder.3pm
...
Any idea, what it should be?
I do not understand the question :/
I don't know how to specify another path for those entries:
/usr/local/share/man/man3/ZoneMinder.3pm
In makefile I get the following:
INST_MAN3DIR = blib/man3
Without looking closely I'd say you can use something like:
%makeinstall INST_MAN3DIR=%{_mandir}/man3
(note that the Fedora spec doesn't do this, so it mightn't be needed).
(One more thing, all package names should be lowercase if possible, so
zoneminder).
How to change this blib path not to point to /usr/local/... ?
- what should be the permissions for the site under the apache server?
that depend on what does the site. There is basically some people that
say this should be 127.0.0.1 by default, and those that say if people
installed it, they want to use it on a network and are able to configure
apache properly, so it should be opened
- should the %install section creates the database table/permissions
for ZoneMinder? If so, is there any example how to achieve this?
Unfortunately, no. A server can be password protected, on another
computer, or using a specific database name.
I always wanted to have a proper framework for that ( like saying this
is the sql file and let some helper script take care of the rest, based
on configuration or offering a easy to use tools to create and install
database after installation ), but never wrote anything :)
- should the %install section creates the service launcher scripts? If
so, is there any example how to achieve this?
Yes. It was not migrated yet ( or maybe it was ), but this should be a
good start :
http://wiki.mandriva.com/en/Development/Howto/Initscripts
Thanks for your help!
Vincent
--
Ahmad Samir
Re: [Mageia-dev] Finalizing update process
On 19 June 2011 15:00, Michael Scherer m...@zarb.org wrote: Le samedi 18 juin 2011 à 23:25 +0300, Ahmad Samir a écrit : On 15 June 2011 22:32, Stew Benedict stewbi...@gmail.com wrote: qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. Yes, that requires to create a account for that. Dmorgan knows, I don't :/ ( and we should document that once the wiki will be installed ). The same for sec team, there should be a way to assign/put-in-CC. That would requires the creation of the secteam as something more formal than now, and for now, that's no. So you should better explain the need about assigning or put a group of people in CC when you can simply put one person for that. -- Michael Scherer Sorry, I seem to have missed this email. I can see secur...@groups.mageia.org can be set as bug assignee in bugzilla now, so the discussion is null at this point. About the better explanation, the benefits of having one generic email address set as assignee in security-related bug reports, just one point, not having one point of failure, if the only person in the sec team becomes unavailable for a prolonged period of time for any reason, someone will have to trudge through the bug reports assigned to him to change the assignee field, whereas if a generic email address is used that won't be necessary. -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
On 22 July 2011 11:27, Michael Scherer m...@zarb.org wrote: Le vendredi 22 juillet 2011 à 11:04 +0300, Ahmad Samir a écrit : On 19 June 2011 15:00, Michael Scherer m...@zarb.org wrote: Le samedi 18 juin 2011 à 23:25 +0300, Ahmad Samir a écrit : On 15 June 2011 22:32, Stew Benedict stewbi...@gmail.com wrote: qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. Yes, that requires to create a account for that. Dmorgan knows, I don't :/ ( and we should document that once the wiki will be installed ). The same for sec team, there should be a way to assign/put-in-CC. That would requires the creation of the secteam as something more formal than now, and for now, that's no. So you should better explain the need about assigning or put a group of people in CC when you can simply put one person for that. -- Michael Scherer Sorry, I seem to have missed this email. I can see secur...@groups.mageia.org can be set as bug assignee in bugzilla now, so the discussion is null at this point. About the better explanation, the benefits of having one generic email address set as assignee in security-related bug reports, just one point, not having one point of failure, if the only person in the sec team becomes unavailable for a prolonged period of time for any reason, someone will have to trudge through the bug reports assigned to him to change the assignee field, whereas if a generic email address is used that won't be necessary. If the only problem is to reassign bugs, then we can write a script. My main worries are that given that right now, there is 1 single person in the group, that change nothing. I would even add that it proves my point, using alias mean that people do not know who they assign the bugs to. So while you think there is no point of failure, but there is, and you do not see nor know it. Right. Sorry for wasting your time with my waffling then. Also, assigning thing to a group of people tend to make them think someone else will do it :/ Finally, if the problem is someone can leave and we have to reassign bug, there is nothing special regarding security bugs to that regard, and we have the need to reassign others bugs too, and yet, we do not use aliases. So why make a exception just for that ? -- Michael Scherer -- Ahmad Samir
[Mageia-dev] RFC: gtk-doc proposed changes
ATM gtk-doc requires dblatex which requires texlive - texlive-texmf; due to the outrageous size of texlive-texmf, building packages in local chroots becomes a bit of pain/burden on my HDD, also each of texlive and xmltex have I/O intensive postinstall scriptlets. I see the texlive-texmf issue is being discussed in another thread so I'll keep this one about gtk-doc; here're a couple of points: - Some packages have BR gtk-doc but it's redundant: o They don't have --enable-gtk-doc passed to ./configure, which means that BR isn't used at all o Most of those packages already bundle html gtk-doc's; is there any benefit rebuilding those docs when building the package? or should the gtk-doc BR get dropped in such cases (since no one complained about those html docs all those years)? - I am thinking of splitting gtk-doc itself, putting gtkdoc-mkpdf in a separate sub-package which will require dblatex: o AFAICS dblatex is only used for creating PDF's from XML sources, so only useful for gtkdoc-mkpdf o This will result in less HDD grinding due to texlive-texmf and xmltex being, unnecessarily, pulled in chroots (either local ones or on the BS). Note that for most of the packages I saw, --enable-gtk-doc-html is the default (assuming only --enable-gtk-doc was passed to configure). o I don't see any packages with pdf gtk-doc documentation: $ urpmf /usr/share/gtk-doc | grep pdf gives nothing at all. So, theoretically, this split shouldn't break any packages (there're 144 SRPMS that have BR gtk-doc and 5 -devel packages that require gtk-doc). And if any package breaks due to the split, the fix is simply adding BR gtk-doc-pdf. Of course we can make it more painful and require that those 149 packages get a test build before the split is OK'ed... WDYT? -- Ahmad Samir
Re: [Mageia-dev] Missing packages
On 21 July 2011 05:50, Thomas Spuhler tho...@btspuhler.com wrote: On Wednesday, July 20, 2011 08:21:40 pm Thomas Spuhler wrote: On Wednesday, July 20, 2011 01:55:28 am Anne nicolas wrote: Hi there Usual mail on missing packages. Please have a look on that list to decrease it: http://check.mageia.org/dependencies.html This is important to clean this list. Please report on this thread anything you do for it. Cheers I have several (The horde related) and it will take some time to get this all done. there are about 30 packages I need to redo and the names all cahnge to a php-pear-Horde_C style then there is the perlapi-5.12.2 which comes from swish-e that doesn't build on a 32 bit system. I am working with upstream to get it fixed, but they take their time. But there is one package I have a problem I cannot explain and I would like some help: php-pear-channel-symfony I have build this package twice with, well at least the system says so ( and I can install it locally), but it never makes it over to the mirrors. I checked the spelling, compared it with other channel packages, compared it to SUSE and all looks good. If someone find a little spare time... it would be appreciated I found this: php-pear-channel-symfony found in incorrect media core.x86_64 (allowed core.i586) error Why did it go to core.x86_64 it's a noarch package How do I move (or remove) this? -- Thomas noarch packages are copied to both i586 and x86_64 repos, so the error on http://check.mageia.org/dependencies.html doesn't make sense to me. Another issue it php-pear-channel-symfony provides and obsoletes _itself_, this is wrong, IIUC. (I've submitted a new package fixing this issue). -- Ahmad Samir
Re: [Mageia-dev] Missing packages
On 21 July 2011 08:51, Jani Välimaa jani.vali...@gmail.com wrote: 2011/7/21 Ahmad Samir ahmadsamir3...@gmail.com On 21 July 2011 05:50, Thomas Spuhler tho...@btspuhler.com wrote: On Wednesday, July 20, 2011 08:21:40 pm Thomas Spuhler wrote: On Wednesday, July 20, 2011 01:55:28 am Anne nicolas wrote: Hi there Usual mail on missing packages. Please have a look on that list to decrease it: http://check.mageia.org/dependencies.html This is important to clean this list. Please report on this thread anything you do for it. Cheers I have several (The horde related) and it will take some time to get this all done. there are about 30 packages I need to redo and the names all cahnge to a php-pear-Horde_C style then there is the perlapi-5.12.2 which comes from swish-e that doesn't build on a 32 bit system. I am working with upstream to get it fixed, but they take their time. But there is one package I have a problem I cannot explain and I would like some help: php-pear-channel-symfony I have build this package twice with, well at least the system says so ( and I can install it locally), but it never makes it over to the mirrors. I checked the spelling, compared it with other channel packages, compared it to SUSE and all looks good. If someone find a little spare time... it would be appreciated I found this: php-pear-channel-symfony found in incorrect media core.x86_64 (allowed core.i586) error Why did it go to core.x86_64 it's a noarch package How do I move (or remove) this? -- Thomas noarch packages are copied to both i586 and x86_64 repos, so the error on http://check.mageia.org/dependencies.html doesn't make sense to me. Another issue it php-pear-channel-symfony provides and obsoletes _itself_, this is wrong, IIUC. (I've submitted a new package fixing this issue). IIRC, It's a known problem that if you obsolete noarch package it's only removed from i586 repos. That probably explains the issue; the new package is no available on both archs. -- Jani Välimaa -- Ahmad Samir
Re: [Mageia-dev] [RPM] 1 core/updates_testing kdelibs4-4.6.5-0.1.mga1
2011/7/21 Thierry Vignaud thierry.vign...@gmail.com: On 13 July 2011 04:29, Mageia Team buildsystem-dae...@mageia.org wrote: mikala mikala 2:4.6.5-0.1.mga1: + Revision: 123536 - Update patch200 to really fix mga #897 - Update tarball to KDE SC 4.6.5 : - Fix several upstream patch ( see http://www.kde.org/announcements/announce-4.6.5.php ) - Add patch200 from 4.7 branch to fix mga #897 kde #271331 (Broken documentation with docbook-xsl 1.76) - Move dbus files from -devel to -core package - Drop patchs merged upstream This is broken: installing /mageia/stable/x86_64/media/core/updates_testing/lib64kemoticons4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64kio5-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64kjsembed4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64kparts4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64kntlm4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64katepartinterfaces4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64kfile4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64kjs4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64khtml5-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64solid4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64kdecore5-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates/mageia-kde4-config-common-1-12.1.mga1.noarch.rpm /mageia/stable/x86_64/media/core/updates/Default-kde4-config-1-12.1.mga1.noarch.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64krosscore4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64kunittest4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64kdeui5-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64ktexteditor4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64nepomuk4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64kcmutils4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/kdelibs4-core-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64nepomukutils4-4.6.5-0.1.mga1.x86_64.rpm /mageia/stable/x86_64/media/core/updates_testing/lib64nepomukquery4-4.6.5-0.1.mga1.x86_64.rpm Preparing... # Installation failed: file /usr/share/locale/en_US/entry.desktop from install of kdelibs4-core-2:4.6.5-0.1.mga1.x86_64 conflicts with file from package kde-l10n-en_US-2:4.6.2-7.mga1.x86_64 You have a pre-mga1 package, https://www.mageia.org/pipermail/mageia-dev/20110503/004364.html -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron nonfree/release flash-player-plugin11-11.0.1.60-0.b1.071311.1.mga2.nonfree
On 18 July 2011 19:28, Anssi Hannula anssi.hann...@iki.fi wrote: On 18.07.2011 17:14, Ahmad Samir wrote: On 18 July 2011 14:13, Balcaen John mik...@mageia.org wrote: On Monday 18 July 2011 12:33:34 Colin Guthrie wrote: 'Twas brillig, and Ahmad Samir at 18/07/11 12:01 did gyre and gimble: Does it complain about this if one removes the kcm module? I tested a while ago, we'd have to remove both the kcm module .so and .desktop files; I am OK with that, the GTK+ tool provides the same exact functionalities and is desktop-agnostic (i.e. it won't pull any extra deps AFAICS). I presume this is all just going into a flash-player-kde package rather than nuked completely? Is it possible to create this package on the fly? because last time we talked about that on the bug report ( https://bugs.mageia.org/show_bug.cgi?id=1275 ) it was not. -- Balcaen John You're right, I forgot about that limitation. @Colin: so, no we can't :) Actually, it is possible, with some added complexity (extraction of the KDE files from the file downloaded by the main pkg in the -kde subpkg %post script. I'll look into it. -- Anssi Hannula FWIW, on further investigation libflashplayer.so checks for KDE_FULL_SESSION and KDE_SESSION_VERSION env vars, if they're true and 4, respectively, it first tries to load the kcm module then falls back to /usr/bin/flash-player-properties, which means a 2-3sec lag between selecting Global Settings from the right click menu on any flash content, to the GTK config dialogue actually showing up. -- Ahmad Samir
Re: [Mageia-dev] FYI: telepathy-farsight has been renamed to telepathy-farstream upstream
On 20 July 2011 05:35, andre999 and...@laposte.net wrote: 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é No we can't, because telepathy-farstream isn't API/ABI compatible with telepathy-farsight. -- Ahmad Samir
Re: [Mageia-dev] Missing packages
On 20 July 2011 10:55, Anne nicolas enn...@mageia.org wrote: Hi there Usual mail on missing packages. Please have a look on that list to decrease it: http://check.mageia.org/dependencies.html This is important to clean this list. Please report on this thread anything you do for it. Cheers -- Anne http://www.mageia.org xcb-util bits, will be fixed when the script to remove binary rpms that have no scr.rpm, is deployed (they're remnants of the old xcb-util-0.3.6). -- Ahmad Samir
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
[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] 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
Re: [Mageia-dev] Problems with udev in kernel 2.6.38.8-desktop
On 18 July 2011 10:36, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Jeff Robins at 18/07/11 01:34 did gyre and gimble: On 07/17/2011 06:20 AM, Brian Smith wrote: Bug 1954 https://bugs.mageia.org/show_bug.cgi?id=1954 Sounds like the same bug I reported against in Cauldren with 2.6.38.8 I can confirm not seeing the bug here under 2.6.38.7 and having updated this morning it hasn't re appeared yet under 3.0 rc7. Brian Smith Is there a nice rpm I can easily download and use for the 3.0 kernel, otherwise what is the location for the media so that I can add it? It's in the core repository. It's just the latest version of the kernel package. A normal update of cauldron will bring it in by default. Col (I think Jeff is using mga1, not Cauldron). -- 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/] -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release mplayer-1.0-1.rc4.0.r32713.7.mga2
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). fwang fwang 1.0-1.rc4.0.r32713.7.mga2: + Revision: 125857 - rebuild for new dfb -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release mplayer-1.0-1.rc4.0.r32713.7.mga2
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? -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron nonfree/release flash-player-plugin11-11.0.1.60-0.b1.071311.1.mga2.nonfree
On 18 July 2011 11:31, Anssi Hannula anssi.hann...@iki.fi wrote: On 18.07.2011 08:20, Ahmad Samir wrote: On 18 July 2011 00:48, Anssi Hannula anssi.hann...@iki.fi wrote: On 18.07.2011 00:04, JA Magallón wrote: On Sun, 17 Jul 2011 14:06:12 +0200 (CEST), Mageia Team buildsystem-dae...@mageia.org wrote: Name : flash-player-plugin11 Relocations: (not relocatable) Version : 11.0.1.60 Vendor: Mageia.Org Release : 0.b1.071311.1.mga2.nonfree Build Date: Sun Jul 17 14:05:18 2011 Install Date: (not installed) Build Host: jonund Group : Networking/WWW Source RPM: (none) Size : 11376 License: Proprietary Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://www.adobe.com/products/flashplayer/ Summary : Flash Player plugin for browsers - 11 Beta 1 release Description : Adobe Flash Player plugin for browsers. 11 Beta 1 release. NOTE: This package does not contain the Flash Player itself. The software will be automatically downloaded from Adobe during package installation. Alternatively you can use the command download-flash-player-plugin manually. Installing this package indicates acceptance of the following documents: - Flash Player 11 License, http://labs.adobe.com/technologies/eula/flashplayer11.html - Adobe.com Terms of Use, http://www.adobe.com/go/labs_term_of_use - Adobe Online Privacy Policy, http://www.adobe.com/go/labs_privacy_policy anssi anssi 11.0.1.60-0.b1.071311.1.mga2: + Revision: 125340 - better obsoletes and conflicts + ahmad ahmad - imported package flash-player-plugin11 Why does it try to pull phonon and half KDE ? Fixed and resubmitted, thanks. -- Anssi Hannula lib*kutils4 should be a suggests at least otherwise opening Global Settings from the right click menu on any e.g. youtube video will complain about the missing lib. Trrh, we don't want flash player suggesting kde. Agreed. Does it complain about this if one removes the kcm module? I tested a while ago, we'd have to remove both the kcm module .so and .desktop files; I am OK with that, the GTK+ tool provides the same exact functionalities and is desktop-agnostic (i.e. it won't pull any extra deps AFAICS). -- Anssi Hannula -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release mplayer-1.0-1.rc4.0.r32713.7.mga2
On 18 July 2011 13:33, Michael Scherer m...@zarb.org wrote: Le lundi 18 juillet 2011 à 13:57 +0300, Ahmad Samir a écrit : 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. Isn't it sufficient to install real-codecs for that ? Do we have real-codecs in the distro repos? ( also, is there still people using real codecs nowadays ? ) No idea; you'd probably need to create a poll on the forum to find out. -- Michael Scherer -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron nonfree/release flash-player-plugin11-11.0.1.60-0.b1.071311.1.mga2.nonfree
On 18 July 2011 13:33, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Ahmad Samir at 18/07/11 12:01 did gyre and gimble: Does it complain about this if one removes the kcm module? I tested a while ago, we'd have to remove both the kcm module .so and .desktop files; I am OK with that, the GTK+ tool provides the same exact functionalities and is desktop-agnostic (i.e. it won't pull any extra deps AFAICS). I presume this is all just going into a flash-player-kde package rather than nuked completely? Could be, yes; but that -kde package won't be suggested by the main package so as not to suggest have of kde core libs/packages... 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/] -- Ahmad Samir
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 17 July 2011 13:09, Anssi Hannula anssi.hann...@iki.fi wrote: On 16.07.2011 15:17, Ahmad Samir wrote: On 16 July 2011 14:02, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 16 July 2011 11:11, Anssi Hannula anssi.hann...@iki.fi wrote: On 15.07.2011 11:10, Ahmad Samir wrote: Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. - For Cauldron: o Do we ship the 11 beta1 for both arch? o Just x86_64 and keep the 32bit stable flash for now o Keep the 32bit stable and create another spec (Name: flash-player-pluing11) for 11 beta1? this way 32bit users will have a choice to install the version they want. WDYT? I'd provide it as 'flash-player-plugin11' or 'flash-player-plugin-beta' for both cauldron and mga1. I had started working on flash-player-plugin11 yesterday (based on the current spec and the old PLF flash-player10.2). I've imported it in Cauldron. @Anssi (since you worked on the flash spec the most), please review, feel free to fix anything I missed. I removed an unwanted old obsoletes and made conflicts unversioned (as it indeed conflicts with all versions). Otherwise looks ok if it works. Thanks for the review, it works AFAICS, I tested both x86_64 and i586. Submitting to Cauldron for now. -- Anssi Hannula -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron nonfree/release flash-player-plugin11-11.0.1.60-0.b1.071311.1.mga2.nonfree
On 18 July 2011 00:48, Anssi Hannula anssi.hann...@iki.fi wrote: On 18.07.2011 00:04, JA Magallón wrote: On Sun, 17 Jul 2011 14:06:12 +0200 (CEST), Mageia Team buildsystem-dae...@mageia.org wrote: Name : flash-player-plugin11 Relocations: (not relocatable) Version : 11.0.1.60 Vendor: Mageia.Org Release : 0.b1.071311.1.mga2.nonfree Build Date: Sun Jul 17 14:05:18 2011 Install Date: (not installed) Build Host: jonund Group : Networking/WWW Source RPM: (none) Size : 11376 License: Proprietary Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://www.adobe.com/products/flashplayer/ Summary : Flash Player plugin for browsers - 11 Beta 1 release Description : Adobe Flash Player plugin for browsers. 11 Beta 1 release. NOTE: This package does not contain the Flash Player itself. The software will be automatically downloaded from Adobe during package installation. Alternatively you can use the command download-flash-player-plugin manually. Installing this package indicates acceptance of the following documents: - Flash Player 11 License, http://labs.adobe.com/technologies/eula/flashplayer11.html - Adobe.com Terms of Use, http://www.adobe.com/go/labs_term_of_use - Adobe Online Privacy Policy, http://www.adobe.com/go/labs_privacy_policy anssi anssi 11.0.1.60-0.b1.071311.1.mga2: + Revision: 125340 - better obsoletes and conflicts + ahmad ahmad - imported package flash-player-plugin11 Why does it try to pull phonon and half KDE ? Fixed and resubmitted, thanks. -- Anssi Hannula lib*kutils4 should be a suggests at least otherwise opening Global Settings from the right click menu on any e.g. youtube video will complain about the missing lib. -- Ahmad Samir
Re: [Mageia-dev] How to push new packages to Mageia 1 updates_testing
On 17 July 2011 23:43, Samuel Verschelde sto...@laposte.net wrote: Hi, I wanted to share the method I use when I need to push a new package (new = missing from Mageia 1) from cauldron to Mageia 1 updates. This concerns only packages available in Mandriva 2010.2 but absent from Mageia 1. I'm sharing for 2 reasons : - maybe I'm doing it wrong, so you can comment and maybe give me better instructions - it can be of use, the way I do it or the way I will be told to do :) Here is my procedure : svn cp svn+ssh://svn.mageia.org/svn/packages/cauldron/PACKAGENAME svn+ssh://svn.mageia.org/svn/packages/updates/1/PACKAGENAME (with comment Add PACKAGENAME to Mageia 1) svn mkdir svn+ssh://svn.mageia.org/svn/binrepos/updates/1/putty (with comment Add PACKAGENAME) 'svn mkdir' step is redundant, 'mgarepo sync -c' will automatically create the binrepos/updates/1/$pkg-name. mgarepo co 1/PACKAGENAME cd PACKAGENAME cp PATH_TO_BINARY_SOURCE_FILES_IN_CAULDRON SOURCES/ mgarepo sync -c #uploads the source files to binrepo vi SPECS/PACKAGENAME.spec #update release and add subrel mgarepo submit -t 1 --define section=core/updates_testing For release and subrel, usually a new package would have release 0 and subrel 1, but to allow migration from mandriva, I set a higher release that in mandriva 2010.2 if the version is the same, + subrel 1, then increase it in cauldron too so that it's higher than in Mageia 1. I do that to be safe : the point of subrel is to be increased without any risk of the package becoming not upgradable to the version in the n+1 distribution. If cauldron has release 5.mga2 and updates has 5.mga1, it looks safe, but as soon as we'll fix a bug in mga1, release will become 5.1.mga1 which is higher than 5.mga2. That's why, for security, I would set the release in cauldron to 6.mga2 so that we can increase the subrel at will in mga1. Comments ? Samuel Verschelde -- Ahmad Samir
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 16 July 2011 02:57, Michael Scherer m...@zarb.org wrote: Le vendredi 15 juillet 2011 à 11:10 +0300, Ahmad Samir a écrit : Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? Yes, I do. That's a beta, and stable is not a dumping ground for that. Right, let's do a head count: Mageia 64bit users who are using the 64bit Adobe Flash 11 Beta 1, please raise your hand (my hand is raised already, I've been using it for 2-3 days). The point, if there's no other easy way to watch flash for 64bit users without jumping through hoops (using nspluginwrapper, which is occasionally problematic, or using a 32bit browser on an x86_64 system, which entails installing some more 32bit libs), there's a good chance they'll use flash 11, alpha/beta/rc is still better than the hoops. Also we're talking about pushing it to backports, not updates. Anyway, since I am personally not affected by the whole issue, I am not pushing to submit to mga1, do a poll or whatever, when a consensus is reached we can act accordingly. -- Michael Scherer -- Ahmad Samir
Re: [Mageia-dev] Where is the KDE WM ?
On 15 July 2011 23:20, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Balcaen John at 15/07/11 20:16 did gyre and gimble: On Friday 15 July 2011 15:06:11 Frank Griffin wrote: On 07/15/2011 02:28 PM, Frank Griffin wrote: Has anyone else noticed that as of updating yesterday or today, the windows in KDE have no titlebars, and cannot be moved or closed (except through the individual app) ? I used to see this occasionally under GNOME 2.32, but logging out/in again usually put it right. That doesn't work in the current KDE. All windows open in the top left of the screen with no enclosing frame, i.e. the MenuBar is the topmost thing you see. Turning Compiz off gets the titlebars back, but I've had Compiz on for a week or more without this problem. Googling shows that there is some conflict between Compiz and KDE, and other distro forums mentioned a compiz-kde package. Has something similar not been rebuilt for the new KDE ? I just finished to push compiz 0.8.8 (works is done by julien) everything is working here. How do you configure compiz ? Here it's simply working by selecting compiz as the default windows manager using systemsettings ( kcmshell4 componentchooser in konsole) 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. Normally, you pick compiz via drak3d 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/] -- Ahmad Samir
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 16 July 2011 11:11, Anssi Hannula anssi.hann...@iki.fi wrote: On 15.07.2011 11:10, Ahmad Samir wrote: Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. - For Cauldron: o Do we ship the 11 beta1 for both arch? o Just x86_64 and keep the 32bit stable flash for now o Keep the 32bit stable and create another spec (Name: flash-player-pluing11) for 11 beta1? this way 32bit users will have a choice to install the version they want. WDYT? I'd provide it as 'flash-player-plugin11' or 'flash-player-plugin-beta' for both cauldron and mga1. I had started working on flash-player-plugin11 yesterday (based on the current spec and the old PLF flash-player10.2). -- Anssi Hannula -- Ahmad Samir
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 16 July 2011 14:02, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 16 July 2011 11:11, Anssi Hannula anssi.hann...@iki.fi wrote: On 15.07.2011 11:10, Ahmad Samir wrote: Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. - For Cauldron: o Do we ship the 11 beta1 for both arch? o Just x86_64 and keep the 32bit stable flash for now o Keep the 32bit stable and create another spec (Name: flash-player-pluing11) for 11 beta1? this way 32bit users will have a choice to install the version they want. WDYT? I'd provide it as 'flash-player-plugin11' or 'flash-player-plugin-beta' for both cauldron and mga1. I had started working on flash-player-plugin11 yesterday (based on the current spec and the old PLF flash-player10.2). I've imported it in Cauldron. @Anssi (since you worked on the flash spec the most), please review, feel free to fix anything I missed. -- Anssi Hannula -- Ahmad Samir -- Ahmad Samir
[Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. - For Cauldron: o Do we ship the 11 beta1 for both arch? o Just x86_64 and keep the 32bit stable flash for now o Keep the 32bit stable and create another spec (Name: flash-player-pluing11) for 11 beta1? this way 32bit users will have a choice to install the version they want. WDYT? -- Ahmad Samir
Re: [Mageia-dev] new mgarepo version
On 13 July 2011 00:30, nicolas vigier bo...@mars-attacks.org wrote: Hello. mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get Works OK, thanks. -- Ahmad Samir
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 15 July 2011 11:34, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Ahmad Samir at 15/07/11 09:10 did gyre and gimble: Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. I'd offer it in main/testing for both arches personally... breaking the rules somewhat but it does at least make life easier for debugging and triaging anyway to keep things consistent on both arches. But it's still a beta, with a it'll be release before the end of 2011 which is pretty elastic in terms of ETA - For Cauldron: o Do we ship the 11 beta1 for both arch? Yes (IMO) 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/] -- Ahmad Samir
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 15 July 2011 11:55, Angelo Naselli anase...@linux.it wrote: venerdì 15 luglio 2011 alle 10:10, Ahmad Samir ha scritto: Hello. As you've seen the thread, posted by Charles A Edwards, there's a new version of flash which has native 64bit support, it's still in beta but seems to work well, some questions: - Any objections about offering it in mga1? on x86_64 only and keeping the 32bit stable one as is for now; not having to install nspluginwrapper or a 32bit browser on a 64bit system is an improvement, IMHO. I'm in favour with some doubts though. Some people think mageia is quiet... so maybe we should start to increase updates/backports and improving people feelings... You mean create hype with updates? just updating for updating's sake is not useful, for me at least, unless an update fixes a bug in a package I am using. I say that without using that much mga1, but some days ago updates were so little... The big problem with this package though is that if it is buggy and moreover for security reasons, it isn't so upstream responsive, at least for x86_64 till now... I don't have hard numbers, but my guess would be that a lot of x86_64 users are already using the 11 beta1. adding it in the repos is just a convenience sort of thing (the same with packaging a binary blob that doesn't need compiling... even more so if the package in question is a skeleton package that downloads a tarball/rpm from upstream when the user installs a package). - For Cauldron: o Do we ship the 11 beta1 for both arch? i vote for that, cauldron is cauldron and we can revert or change things before freeze time, some months of testing will show us upstream movements also... [] Angelo -- Ahmad Samir
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
On 15 July 2011 14:17, Thomas Backlund t...@mageia.org wrote: Ahmad Samir skrev 15.7.2011 12:43: On 15 July 2011 11:34, Colin Guthriemag...@colin.guthr.ie wrote: I'd offer it in main/testing for both arches personally... breaking the rules somewhat but it does at least make life easier for debugging and triaging anyway to keep things consistent on both arches. But it's still a beta, with a it'll be release before the end of 2011 which is pretty elastic in terms of ETA _if_ we provide it for mageia 1, it belongs in backports(_testing), not updates(_testing) Good point, I didn't say where I'd submit it (but somehow I was thinking updates_testing...), you're right, should be backports. -- Thomas -- Ahmad Samir
Re: [Mageia-dev] new mgarepo version
On 14 July 2011 11:13, Angelo Naselli anase...@linux.it wrote: A bit hijacking the thread, but I have a quick question - would it be possible to have repsys on mageia? There is mgarepo on Mandriva for the ones willing to work with Mageia repositories from Mandriva; is it too much to ask for the opposite? (E.g., for the ones willing to work on Mandriva repos from Mageia)? IMO there's nothing that should block that, but packaging or license... ;) As a mandriva contributor -well something more indeed :)-, you could ask to get part of pacakgers, if you wish to :) In any case i cannot test it at the moment, but if you rebuilt on mageia and tested it, i could offer myself to submit it, just send me the srpms link :) Angelo Like Angelo, I don't think there're any restrictions on importing repsys, so I've imported it, should be on the mirrors soon. -- Ahmad Samir
Re: [Mageia-dev] new mgarepo version
On 14 July 2011 12:46, Angelo Naselli anase...@linux.it wrote: giovedì 14 luglio 2011 alle 12:18, Ahmad Samir ha scritto: Like Angelo, I don't think there're any restrictions on importing repsys, so I've imported it, should be on the mirrors soon. There's who talks... and who does :) (Sorry, didn't mean to step on your toes). Thanks Ahmad. Angelo -- Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 13 July 2011 12:15, Christiaan Welvaart c...@daneel.dyndns.org wrote:
On Wed, 13 Jul 2011, Ahmad Samir wrote:
https://bugs.mageia.org/show_bug.cgi?id=2065
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.
Always adding the same provides regardless of what gets added automatically
is probably better and easier. I'd like to modify or clarify your proposal a
bit. When name starts with lib, use %{oname}-devel and lib%{oname}-devel
as provides. oname must be defined in the specfile as the name without the
lib prefix. That is usually already the case and this macro is used as
argument for mklibname.
Christiaan
Agreed, liblib* shouldn't exist.
--
Ahmad Samir
Re: [Mageia-dev] new mgarepo version
On 13 July 2011 13:53, nicolas vigier bo...@mars-attacks.org wrote: On Wed, 13 Jul 2011, Angelo Naselli wrote: Ok, it's moved to updates now. Nicolas are you interested in mgarepo bash_completion? I imported it from mdvsys... Yes, I think you can add it. FWIW, I've been using the attached bash-completion file for some months now, however since I am not a bash-completion guru I didn't want to plague anyone else with any things I've messed up with it. @Angelo: Feel free to use anything from it, if any, to add to the file you have (note that I disabled the auto completion of package names in SVN since it's too slow for taste). -- Ahmad Samir mgarepo Description: Binary data
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 13 July 2011 14:27, nicolas vigier bo...@mars-attacks.org wrote: On Tue, 12 Jul 2011, Ernest N. Wilcox Jr. wrote: Date: Tue, 12 Jul 2011 11:16:24 +0200 From: Wolfgang Bornath molc...@googlemail.com To: Mageia development mailing-list mageia-dev@mageia.org Subject: Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs? Message-ID: CA+h4nj6KtYu8vUFcZ4mWUO08J5ZyxB5XnN2bsSLoqm8R7w6E=w...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 2011/7/12 andre999 and...@laposte.net: Wolfgang Bornath a ?crit : 2011/7/9 andre999and...@laposte.net: Wolfgang Bornath a ?crit : 2011/7/8 Thorsten van Liltv...@gmx.de: Am 08.07.2011 10:42, schrieb Wolfgang Bornath: 2011/7/8 James Kerrj...@jkerr82508.free-online.co.uk: This thread has strayed far from the original question, which could be re-stated as: Should tainted free software and tainted nonfree software be commingled in a single tainted repository? ... Besides, tainted is not only about patents, it's also about software which is illegal in certain countries (like libdvdcss). Ok, a relatively limited application. So in all, maybe a handful of packages at most should be in tainted. So why do we have more than 150 ? Sorry, but I do not understand your way of thinking. If a law exists it exists. It does not matter to a law whether it is likely to be enforced. Period. This is not paranoia, it is a matter of mind set. If robbery would not be prosecuted, would you go out and earn your doe by taking away handbags from old ladies? You would not, because it is wrong. For those who are living in countries where patents are valid and accepted by the law, using a patented software is wrong. So you must accept that there are people who would not do it. Telling them how they should think about it is not ours. That's why we have the tainted repo. -- wobo +1 I live in the USA, and while I do not personally support the concept of software pantents, I also do not want to violate them as long as they are leagally recognized where I live. For me, this is not a matter of risk, but one of ethics, morality, and respect. IMHO, the fact that my Countries Society recognizes patents as being legally binding makes it my responsibility to honor them, so I want to know if a software package may be affected by one or more patent(s) before I install it on my computer. If I know that (for example) package foo is affected by a patent, I can search for the patent holder, and make contact to request permission to ust the software, then abide with their response. This way, I fulfill my obligation to ask permission before using software that is (or may be) affected by some one elses property. I would no more use patented software without permission here in the USA than I would take my neighbor's lawnmower to cut my grass without his permission. I understand that the following may not be practicable, but I would like all software that is affected by a patent (and perhaps other licensing or copyright restrictions) to be placed in a restricted (tainted) repository. Also I would like to see patent (or contact) information in the software package's description to help facilitate my ability to ask permission to use the software. By doing these things, Mageia is doing more to support my ability to live by my personal convictions than to support patent law. I think we should not do that. Because we probably have more useful things to do than documenting patents and helping patent holders. And because it doesn't help users, on the contrary, it makes it more dangerous for them to use the software, because they cannot say they didn't know about the patent. (However, each package has a URL field, with a link to the upstream web site, that could be a good starting point for a search for those who wanna do it). -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
On 13 July 2011 13:53, Balcaen John mik...@mageia.org wrote: On Wednesday 13 July 2011 09:49:01 Samuel Verschelde wrote: [...] The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Maybe we should check it via rpmlint on package upload ? s/upload/submit/. -- Balcaen John -- Ahmad Samir
Re: [Mageia-dev] new mgarepo version
On 13 July 2011 15:27, Marianne Lombard maria...@tuxette.fr wrote: Le 13/07/2011 00:30, nicolas vigier a écrit : Hello. mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get Hi, I'm trying to do a anonymous checkout with mgarepo and ... it doesn't work (anonymous co because I don't have a packager account) What is the right configuration I need to put in my /etc/mgarepo.conf Regards (Reposting what I posted on IRC): $ mkdir -p ~/.mgarepo; cp /etc/mgarepo.conf ~/.mgarepo/config Then edit ~/.mgarepo/config and change: repository = svn+ssh://svn.mageia.org/svn/packages/ binaries-repository = svn+ssh://svn.mageia.org/svn/binrepos to repository = svn://svn.mageia.org/svn/packages/ binaries-repository = svn://svn.mageia.org/svn/binrepos -- Marianne Lombard (Jehane) Mageia User - Mageia french translation team Inside every fat girl, there is a thin girl waiting to get out (and a lot of chocolate) - Terry Pratchett -- Ahmad Samir
Re: [Mageia-dev] new mgarepo version
On 13 July 2011 16:16, Marianne Lombard maria...@tuxette.fr wrote: Le 13/07/2011 15:34, Ahmad Samir a écrit : (Reposting what I posted on IRC): $ mkdir -p ~/.mgarepo; cp /etc/mgarepo.conf ~/.mgarepo/config Then edit ~/.mgarepo/config and change: repository = svn+ssh://svn.mageia.org/svn/packages/ binaries-repository = svn+ssh://svn.mageia.org/svn/binrepos to repository = svn://svn.mageia.org/svn/packages/ binaries-repository = svn://svn.mageia.org/svn/binrepos It works but the comment in the config file is ... what you MUST not do ## uncomment it in case you don't have a account in the Mageia build system: #mirror = http://svn.mageia.org/svn/packages/cauldron/ I will open the bugreport Marianne Yeah, that's a remnant of repsys, which wouldn't work with our split binrepos, IINM. -- Marianne Lombard (Jehane) Mageia User - Mageia french translation team Inside every fat girl, there is a thin girl waiting to get out (and a lot of chocolate) - Terry Pratchett -- Ahmad Samir
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 12 July 2011 23:14, Renaud MICHEL r.h.michel+mag...@gmail.com wrote: On mardi 12 juillet 2011 at 22:48, andre999 wrote : I noticed that all packages in tainted contain .tainted. in the name. rsync permits adding the option --exclude '.tainted.' to permit excluding such packages if a mirror wants to. You should not do that, because you will end up with a broken repository, as the hdlist files will contain references to files which are not present on the mirror. A repository must be mirrored entirely or not at all. Yes, but then tainted is a separate repo, mirror admins can simply not mirror it if they want (that was one of the reasons why it _is_ a separate repo). So not mirroring tainted wouldn't break anything (other than that users won't get the full set of repos, but that's up to each mirror admin to decide, we only offer the option). (And I think it is already enough work for the mirror maintainers to have to exclude some directory, they surely don't want to maintain per mirror custom rules) -- Renaud Michel -- Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 8 July 2011 06:37, Ahmad Samir ahmadsamir3...@gmail.com wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
--
Ahmad Samir
Adding to the above, spturtle has suggested using pkgconfig()
provides: https://bugs.mageia.org/show_bug.cgi?id=2065
--
Ahmad Samir
Re: [Mageia-dev] [101505] Revert rpm5 stuffs and sync with fedora
On 10 July 2011 11:36, John Balcaen mik...@mageia.org wrote: 2011/7/10 cazzaniga.san...@gmail.com: I'm agree with ahmad: +1 Since oxygen-gtk3 is only useful for KDE users, it should be suggested by a KDE package, not in gtk+3.0, IMHO. (The same for gtk+2.0 suggesting oxygen-gtk). I guess it's not directly related to kde but rather to provide the same theme for xfce/gnome/kde aka oxygen while waiting for a decision of the artwork team (i guess no one want to port iaora to gtk3) Right; but if Ia_Ora doesn't get ported to GTK+3.0 then we should stick with the upstream default, which is Adwaita. Less maintenance costs, less downstream bugs for us... (Oxygen looks good on Dolphin, but a bit quirky on Firefox, whereas Clearlooks/Nodoka look good on Firefox, but not-so-hot on Dolphin). -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net -- Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 8 July 2011 17:31, nicolas vigier bo...@mars-attacks.org wrote:
On Fri, 08 Jul 2011, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
Good idea.
With version and release included :
Provides: %{name}-devel = %{version}-%{release}
Provides: lib%{name}-devel = %{version}-%{release}
Yes, of course.
--
Ahmad Samir
Re: [Mageia-dev] Wrong detection on rpmlint's unexpanded-macro
On 9 July 2011 05:55, Funda Wang fundaw...@gmail.com wrote: Hello, When submitting kdenetwork4, it was rejected because of unexpanded-macro: - unexpanded-macro /usr/share/apps/kppp/Provider/Netherlands/HetNet%032Frequent%032Surfen %032Frequent But I think unexpanded macro should be checked only in rpm's header (such as name, req, prov, obsoletes), not on the content of the package. Is it wanted? That looks like an unintended side-effect; it barfed on '%exclude %_kde_appsdir/kppp/Provider'; it shouldn't, IIUC. -- Ahmad Samir
[Mageia-dev] Change mandriva svn url in http://check.mageia.org
ATM in http://check.mageia.org when there's a newer version from Mandriva the url takes you to: http://svn.mandriva.com/viewvc/packages/cooker/$PKG/ IMHO, it would better be: http://svn.mandriva.com/viewvc/packages/cooker/$PKG/current/SPECS/$PKG.spec?view=log as this is what we'd check for whatever got changed in the package... -- Ahmad Samir
[Mageia-dev] Bug 1525
Hello, just giving it more exposure https://bugs.mageia.org/show_bug.cgi?id=1525 -- Ahmad Samir
Re: [Mageia-dev] IDE/SATA CDROM devices and user permissions problem (udev/kernel related?) (was Re: Bug 1525)
On 9 July 2011 16:22, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Ahmad Samir at 09/07/11 08:25 did gyre and gimble: Hello, just giving it more exposure https://bugs.mageia.org/show_bug.cgi?id=1525 Some kind of hint as to what it is about is nice :) Fixed that for ya :D Col Or people could read the report, but indeed having an interesting subject is always key. Thanks. -- 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/] -- Ahmad Samir
Re: [Mageia-dev] [101505] Revert rpm5 stuffs and sync with fedora
-%{_libdir}/gtk-%{api_version}/%{binary_version}/immodules/*.so
-%dir %{_libdir}/gtk-%{api_version}/%{binary_version}/printbackends
-%{_libdir}/gtk-%{api_version}/%{binary_version}/printbackends/*.so
-%{_libdir}/libgtk-3.so.%{lib_major}
-%{_libdir}/libgtk-3.so.%{lib_major}.*
-%{_libdir}/libgdk-3.so.%{lib_major}
-%{_libdir}/libgdk-3.so.%{lib_major}.*
-%_libdir/girepository-1.0/Gdk-%{api_version}.typelib
-%_libdir/girepository-1.0/GdkX11-%{api_version}.typelib
-%_libdir/girepository-1.0/Gtk-%{api_version}.typelib
-
-%files -n %{develname}
-%defattr(-, root, root)
-%doc docs/*.txt AUTHORS ChangeLog NEWS* README*
-%doc %{_datadir}/gtk-doc/html/gdk3
-%doc %{_datadir}/gtk-doc/html/gtk3
-%{_bindir}/gtk3-demo
-%{_datadir}/aclocal/*
-%{_datadir}/gtk-%{api_version}
-%{_includedir}/gtk-%{api_version}
-%{_libdir}/libgtk-%{api}.so
-%{_libdir}/libgtk-%{api}.la
-%{_libdir}/libgdk-%{api}.so
-%{_libdir}/libgdk-%{api}.la
-%{_libdir}/pkgconfig/gdk-*%{api_version}.pc
-%{_libdir}/pkgconfig/gtk+-*%{api_version}.pc
-%_datadir/gir-1.0/Gdk-%{api_version}.gir
-%_datadir/gir-1.0/GdkX11-%{api_version}.gir
-%_datadir/gir-1.0/Gtk-%{api_version}.gir
-
-%files -n %gail_libname
-%defattr(-,root,root)
-%{_libdir}/libgailutil-%{api}.so.%{gail_major}*
-%{_libdir}/gtk-%{api_version}/modules/libferret.so
-%{_libdir}/gtk-%{api_version}/modules/libgail.so
-
-%files -n %gaildevelname
-%defattr(-,root,root)
-%{_datadir}/gtk-doc/html/gail-libgail-util3
-%{_libdir}/libgailutil-%{api}.so
-%{_libdir}/libgailutil-%{api}.la
-%{_includedir}/gail-%{api_version}
-%{_libdir}/pkgconfig/gail-%{api_version}.pc
--
Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 8 July 2011 13:44, EatDirt dirt...@gmail.com wrote:
On 08/07/11 06:37, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
WDYT?
Hi! YES!!!
As a Padawan, this was one of my first troubles, to find the correct -devel
package name. Some packages have even different --provides according to the
arch :-/
[..]
Both Provides are certainly the best, but we may recommend the usage of
only one of type in Requires: lib%{name}-devel?
Cheers,
Chris.
For new specs maybe, but for old ones, that would break compatibility
with other specs that already have BR: %{name}-devel. So since we
can't easily get rid of one or the other, better have both...
--
Ahmad Samir
Re: [Mageia-dev] Updates testing
On 7 July 2011 22:04, philippe makowski makowski.mag...@gmail.com wrote: 2011/7/7 nicolas vigier bo...@mars-attacks.org: Yes, for the test about the bug fixed. But isn't there tests to check for regressions ? when you push a new minor version (only bugfix) for softwares like LibreOffice, Postgresql or Firebird for example, will the Mageia QA team run tests for regression and for all bug fixed ? wh ! IMHO, for big packages like libreoffice, we'll have to rely on the free-cost-daily-usage QA, i.e. pushing it to Cauldron users for 1-2month, and waiting till the dust settles before pushing to older stable releases. The interesting part about packages like libreoffice, is they're multi-purpose, so there's no easy way to make sure every functionality works(tm), other than actually letting testes/cauldron-users use it. -- Ahmad Samir
[Mageia-dev] Standardising the virtual Provides in -devel packages
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
--
Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release logrotate-3.8.0-1.mga2
On 4 July 2011 08:25, Mageia Team buildsystem-dae...@mageia.org wrote: Name : logrotate Relocations: (not relocatable) Version : 3.8.0 Vendor: Mageia.Org Release : 1.mga2 Build Date: Mon Jul 4 08:24:04 2011 Install Date: (not installed) Build Host: ecosse Group : File tools Source RPM: (none) Size : 55428 License: GPLv2 Signature : (none) Packager : Mageia Team http://www.mageia.org URL : https://fedorahosted.org/logrotate/ Summary : Rotates, compresses, removes and mails system log files Description : The logrotate utility is designed to simplify the administration of log files on a system which generates a lot of log files. Logrotate allows for the automatic rotation compression, removal and mailing of log files. Logrotate can be set to handle a log file daily, weekly, monthly or when the log file gets to a certain size. Normally, logrotate runs as a daily cron job. Install the logrotate package if you need a utility to deal with the log files on your system. ahmad ahmad 3.8.0-1.mga2: + Revision: 117993 - Update to 3.8.0, fixes: CVE-2011-1098 CVE-2011-1154 CVE-2011-1155 - Drop patch0, fixed upstream - Add BR acl-devel and compile with WITH_ACL - Put 'make test' in a %check section FWIW, I couldn't extract the commits from upstream SVN[1] that fixed those three CVE's (the upstream svn log isn't that clear to me..), so I can't backport the fixes to mga1. [1] http://svn.fedorahosted.org/svn/logrotate/ -- Ahmad Samir
[Mageia-dev] xcb-util update, which broke the BS
I updated xcb-util and stupidly obsoleted the old libs (which have been merged in the one lib), this broke the BS. First thing to do is rebuild startup-notification, but it fails, and I don't see why http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110706093849.ahmad.valstar.8189/log/startup-notification-0.12-2.mga2/install_deps-1.0.20110706093902.log lib64xcb-util0[== 0.3.8-1.mga2] should be available already from xcb-utils-0.3.8... so help! -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release logrotate-3.8.0-1.mga2
On 6 July 2011 11:29, nicolas vigier bo...@mars-attacks.org wrote: On Wed, 06 Jul 2011, Ahmad Samir wrote: On 4 July 2011 08:25, Mageia Team buildsystem-dae...@mageia.org wrote: Name : logrotate Relocations: (not relocatable) Version : 3.8.0 Vendor: Mageia.Org Release : 1.mga2 Build Date: Mon Jul 4 08:24:04 2011 Install Date: (not installed) Build Host: ecosse Group : File tools Source RPM: (none) Size : 55428 License: GPLv2 Signature : (none) Packager : Mageia Team http://www.mageia.org URL : https://fedorahosted.org/logrotate/ Summary : Rotates, compresses, removes and mails system log files Description : The logrotate utility is designed to simplify the administration of log files on a system which generates a lot of log files. Logrotate allows for the automatic rotation compression, removal and mailing of log files. Logrotate can be set to handle a log file daily, weekly, monthly or when the log file gets to a certain size. Normally, logrotate runs as a daily cron job. Install the logrotate package if you need a utility to deal with the log files on your system. ahmad ahmad 3.8.0-1.mga2: + Revision: 117993 - Update to 3.8.0, fixes: CVE-2011-1098 CVE-2011-1154 CVE-2011-1155 - Drop patch0, fixed upstream - Add BR acl-devel and compile with WITH_ACL - Put 'make test' in a %check section FWIW, I couldn't extract the commits from upstream SVN[1] that fixed those three CVE's (the upstream svn log isn't that clear to me..), so I can't backport the fixes to mga1. There are patchs on redhat bugzilla. CVE-2011-1098: https://bugzilla.redhat.com/show_bug.cgi?id=680798 CVE-2011-1154: https://bugzilla.redhat.com/show_bug.cgi?id=680796 CVE-2011-1155: https://bugzilla.redhat.com/show_bug.cgi?id=680797 OK, thanks. -- Ahmad Samir
Re: [Mageia-dev] xcb-util update, which broke the BS
On 6 July 2011 12:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 12:00, Funda Wang fundaw...@gmail.com wrote: The problem is libxcb is obsoleting libxcb-util0: $ rpm -qp --obsoletes libxcb-dpms0-1.7-1.mga1.i586.rpm libxcb-util0 libxcb-util1 So we need to bump the Epoch in xcb-util? Or remove the old obsoletes from libxcb. I think removing the old obsoletes is better. -- Ahmad Samir
Re: [Mageia-dev] xcb-util update, which broke the BS
On 6 July 2011 12:08, Funda Wang fundaw...@gmail.com wrote: 2011/7/6 Ahmad Samir ahmadsamir3...@gmail.com: On 6 July 2011 12:00, Funda Wang fundaw...@gmail.com wrote: The problem is libxcb is obsoleting libxcb-util0: $ rpm -qp --obsoletes libxcb-dpms0-1.7-1.mga1.i586.rpm libxcb-util0 libxcb-util1 So we need to bump the Epoch in xcb-util? No, we need to drop libxcb's obsoletes at first. I guess will need to add some conflicts in libxcb-util so that it will upgrade libxcb at first when upgrading from previous distros. Yes, (you probably missed my previous email), anyway, we may needn't add the obsoletes back, it was added 2years+ ago http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages?view=revisionrevision=383043 I'll try and check more thoroughly though. Thanks a bunch for the fix. 2011/7/6 Ahmad Samir ahmadsamir3...@gmail.com: I updated xcb-util and stupidly obsoleted the old libs (which have been merged in the one lib), this broke the BS. First thing to do is rebuild startup-notification, but it fails, and I don't see why http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110706093849.ahmad.valstar.8189/log/startup-notification-0.12-2.mga2/install_deps-1.0.20110706093902.log lib64xcb-util0[== 0.3.8-1.mga2] should be available already from xcb-utils-0.3.8... so help! -- Ahmad Samir -- Ahmad Samir -- Ahmad Samir
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 6 July 2011 13:40, Florian Hubold doktor5...@arcor.de wrote: Am 06.07.2011 12:10, schrieb Wolfgang Bornath: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. Doesn't seem so. If even Anssi asks me where this package should go, maybe this is not clear to everybody. Also if you reread this thread, there is no concesus here. Also regarding Ahmads answer. But if you tell me that is the status quo, and the others also say so, my question is anwered, and HandBrake should go to tainted. If HandBrake has a bundled faac, then it shouldn't go anywhere in the official Mageia repos, unless the bundles faac is disabled IIUC. -- Ahmad Samir
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 6 July 2011 13:58, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. Although the wording should be clearer / more precise. Romain -- Ahmad Samir
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 6 July 2011 14:27, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 14:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 13:58, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. It does differentiate; given that Anssi is the one who worked on the tainted policy the most, and he doesn't think faac should be in tainted, is enough to say that the wording in the wiki needs to express our stance on the issue in a clearer way... Although the wording should be clearer / more precise. Indeed. Romain -- Ahmad Samir
Re: [Mageia-dev] gstreamer packaging too split?
On 6 July 2011 15:09, Christiaan Welvaart c...@daneel.dyndns.org wrote: On Wed, 6 Jul 2011, Colin Guthrie wrote: Yeah it is a bit of a grab-bag of stuff, but again, should we still just bundle everything together anyway and sod the extra disk space needed? It would be a lot simpler for users (oh you need $foo? sure, just installed -ugly/-bad) which is advise they can get direct from upstream without having to know our particular packaging quirks. As someone who does upstream support for other projects, it's a pain to put caveats in all your advice for distros you don't know. That said, the trade off may be too much, hence the canvassing of opinions here :) I think there are only 2 solutions: - Add a meta package, e.g. gstreamer-codecs-all that can be used to make sure all available codecs are installed. Some people complain about bad and ugly so using those names more is not a good idea. But that's how upstream calls them, hiding them won't work, since they're too popular already. FWIW, there's gstreamer0.10-decoders, a meta package in mdv (not imported yet in Mageia). - Use the packagekit gstreamer plugin, so players install the correct plugins on demand. ATM it doesn't work, the urpmi backend needs some love.. Christiaan -- Ahmad Samir
Re: [Mageia-dev] Introducing several rpm macro
On 6 July 2011 06:30, Kira elegant.pega...@gmail.com wrote: 在 Wed, 06 Jul 2011 09:56:10 +0800, andre999 and...@laposte.net寫道: Funda Wang a écrit : Hello, I would like to introduce several rpm autoprovs, such as mimehandler, fontconfig, the same as fedora, opensuse and mandriva. So that we could eventually doing something like 'urpmi font(:lang=jp) mimehandler(audio/x-mp3). WDYT? If it provides extra functionality present in the other rpm distros, it sounds like a good idea. I agree that we can add some more functionalities to urpmi/rpm, but the user experience should be consistent. urpmi font(:lang=jp) is quite abnormal. Ideally, it won't be run by the user, but triggered automatically by packagekit when needed, IIUC. And, will we cooperate with mandriva with urpmi backend for packagekit? I think it is a very good idea, since we have that in common, and urpm* are nice tools. -- Ahmad Samir
Re: [Mageia-dev] Mageia Cauldron: Bad RPM's while update via urpmi
On 2 July 2011 11:39, Daniel Kreuter daniel.kreute...@googlemail.com wrote:
On Sat, Jul 2, 2011 at 5:31 AM, Wolfgang Bornath molc...@googlemail.com
wrote:
2011/7/2 Daniel Kreuter daniel.kreute...@googlemail.com:
Am 07/02/2011 11:12 AM, schrieb Kira:
在 Sat, 02 Jul 2011 17:07:26 +0800, Daniel Kreuter
daniel.kreute...@googlemail.com寫道:
Hello guys,
how can it be that there are bad rpm's in Cauldron? Sure it is a
development build but shouldn't the rpm's be clean so that urpmi can
install them?
I can remember 2 examples of packages which failed:
lib64kworkspace4 (4.6.90)
lib64ktaskmanager
Or are there error's while downloading the packages??
Greetings
D. Kreuter
Error message? What did urpmi tell you?
That this are bad rpm's and he failed to install them.
Could you pls give the exact error message, not your interpretation?
If the error message was really This is a bad rpm I can not install
it then I heve not seen such a message before as long as I am using
*rpm*
--
wobo
http://pastebin.com/tTHmMz7b
--
Mit freundlichen Grüßen
Greetings
Daniel Kreuter
Looks like a bad download, clear the cache:
rm -fv /var/cache/urpmi/partial/{lib64taskmanager4,lib64kephal4}*
then try again, urpmi will download them afresh.
--
Ahmad Samir
Re: [Mageia-dev] Mageia Cauldron: Bad RPM's while update via urpmi
On 2 July 2011 11:47, Daniel Kreuter daniel.kreute...@googlemail.com wrote: But before i will wait until urpmi has finished the rest, after that i will try to install the new packages. I also got an error on webkit, he wasn't able to download it can someone check that pls (I don't have the version in my mind)? -- Mit freundlichen Grüßen Greetings Daniel Kreuter Without the exact error message we can't guess... -- Ahmad Samir
Re: [Mageia-dev] Mageia Cauldron: Bad RPM's while update via urpmi
On 2 July 2011 18:05, andre999 and...@laposte.net wrote: David Walser a écrit : Wolfgang Bornath wrote: This explains it! Change the mirror, you are using ibiblio which has been reported numerous times in the forum and the mailing lists to be syncing very badly. I don't know about badly, but I found it to be a little bit behind. If you are located in north america, use mirrors.kernel.org which is fast and reliable. Has anyone had success using rsync with mirrors.kernel.org? When I tried it, the path to mageia kept toggling between mirrors/pub/mageia and mirrors/pub/pub/mageia every time I used it. It's like it's behind a load balancer where one of the machines behind it has the wrong rsync path configured. I just checked. I think that they haven't finished setting up the mirror. - They don't list Mageia in the sites they mirror. - Mageia's ftp and html links for them don't work. - It is the only rsync mirror in Mageia's list that doesn't list their bandwidth nor their source. ftp://mirrors.kernel.org has been working fine here for ~1 month now. You could try mageia.c3sl.ufpr.br (in Brazil), which is one of the faster rsync mirrors. My mirror in Canada uses it. -- André -- Ahmad Samir
Re: [Mageia-dev] mdv update problem
On 2 July 2011 19:07, Thomas Spuhler tho...@btspuhler.com wrote: I just update my wifes mandriva PC. One of the problems are these few packages: # urpmi --auto-update medium MageiMain is up-to-date medium MageiMain_Erlangen is up-to-date medium Core Release (distrib1) is up-to-date medium Core Updates (distrib3) is up-to-date medium Nonfree Release (distrib11) is up-to-date medium Nonfree Updates (distrib13) is up-to-date medium Tainted Release (distrib21) is up-to-date The following packages can't be installed because they depend on packages that are older than the installed ones: perl-SVN-1.6.16-5.mga1 git-svn-1.7.4.4-2.mga1 git-1.7.4.4-2.mga1 Continue installation anyway? (Y/n) y Packages are up to date https://bugs.mageia.org/show_bug.cgi?id=1700 https://bugs.mageia.org/show_bug.cgi?id=1521 -- Ahmad Samir
Re: [Mageia-dev] libperl not found
On 1 July 2011 03:24, Thomas Spuhler tho...@btspuhler.com wrote: On Thursday, June 30, 2011 12:16:47 am Cazzaniga Sandro wrote: Le 30/06/2011 06:54, Ahmad Samir a écrit : It seems libperl.so is hiding It is wehre it should be but cyrus-imap cannot find it. Maybe we have to check cyrus-imap instead of libperl.so, so. it gives the pretty much same error if you want to rebuild it. I remember it still work with perl-514.0 but not with 5.14.1 Below is the message # service cyrus-imapd start Starting cyrus-imapd: /usr/lib/cyrus-imapd/cyrus-master: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory -- Thomas net-snmp hardcodes the path to libperl.so, so it needed a rebuild, I've submitted it. -- Ahmad Samir
Re: [Mageia-dev] libperl not found
On 1 July 2011 05:35, Thomas Spuhler tho...@btspuhler.com wrote: On Thursday, June 30, 2011 08:08:48 pm Ahmad Samir wrote: On 1 July 2011 03:24, Thomas Spuhler tho...@btspuhler.com wrote: On Thursday, June 30, 2011 12:16:47 am Cazzaniga Sandro wrote: Le 30/06/2011 06:54, Ahmad Samir a écrit : It seems libperl.so is hiding It is wehre it should be but cyrus-imap cannot find it. Maybe we have to check cyrus-imap instead of libperl.so, so. it gives the pretty much same error if you want to rebuild it. I remember it still work with perl-514.0 but not with 5.14.1 Below is the message # service cyrus-imapd start Starting cyrus-imapd: /usr/lib/cyrus-imapd/cyrus-master: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory -- Thomas net-snmp hardcodes the path to libperl.so, so it needed a rebuild, I've submitted it. Thanks Ahmad Just curious, how did you find out? -- Thomas I sort of remembered from a previous perl upgrade that net-snmp was the culprit behind cyrus-imapd didn't work after the upgrade, that and: $ ldd /usr/lib64/libnetsnmpagent.so.25 linux-vdso.so.1 = (0x7fff2c5ff000) libnetsnmp.so.25 = /usr/lib64/libnetsnmp.so.25 (0x7f242c5ad000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f242c3a2000) libperl.so = not found libpthread.so.0 = /lib64/libpthread.so.0 (0x7f242c186000) libc.so.6 = /lib64/libc.so.6 (0x7f242be14000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f242ba29000) libnsl.so.1 = /lib64/libnsl.so.1 (0x7f242b81) /lib64/ld-linux-x86-64.so.2 (0x7f242cb1a000) libdl.so.2 = /lib64/libdl.so.2 (0x7f242b60b000) -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release kate-4.6.90-2.mga2
On 29 June 2011 11:14, Mageia Team buildsystem-dae...@mageia.org wrote: Name : kate Relocations: (not relocatable) Version : 4.6.90 Vendor: Mageia.Org Release : 2.mga2 Build Date: Wed Jun 29 11:02:19 2011 Install Date: (not installed) Build Host: ecosse Group : Graphical desktop/KDE Source RPM: (none) Size : 2009792 License: GPLv2 Signature : (none) Packager : Mageia Team http://www.mageia.org Summary : Advanced text editor Description : A fast and advanced text editor with nice plugins for KDE 4. mikala mikala 2:4.6.90-2.mga2: + Revision: 115701 - Add conflicts against kdesdk4 - Fix License - Add conflicts against kdelibs4-core - Clean spec - Add more requires on the -devel package - imported package kate + fwang fwang - add group for ktexteditor - bump epoch for libkatepartinterfaces - add conflicts on older packages FWIW, I think katepart should be split in its own sub-package, and kwrite should require it, (otherwise kwrite would require the full kate package to work). Also konqueror should suggest katepart, for the embedded text editor part. -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release kate-4.6.90-2.mga2
On 29 June 2011 16:08, John Balcaen mik...@mageia.org wrote: 2011/6/29 Ahmad Samir ahmadsamir3...@gmail.com: On 29 June 2011 11:14, Mageia Team buildsystem-dae...@mageia.org wrote: Name : kate Relocations: (not relocatable) Version : 4.6.90 Vendor: Mageia.Org [...] FWIW, I think katepart should be split in its own sub-package, and kwrite should require it, (otherwise kwrite would require the full kate package to work). Also konqueror should suggest katepart, for the embedded text editor part. Sure, Could you do the split needed changes , i'm moving won't be available to work on this today :/ Done. -- -- Balcaen John -- Ahmad Samir
Re: [Mageia-dev] libperl not found
On 30 June 2011 06:47, Thomas Spuhler tho...@btspuhler.com wrote: It seems libperl.so is hiding It is wehre it should be but cyrus-imap cannot find it. -- Thomas Logs, error messages? -- Ahmad Samir
Re: [Mageia-dev] schroot build problem with new libboost
On 28 June 2011 11:13, philippe makowski makowski.mag...@gmail.com wrote: 2011/6/28 Funda Wang fundaw...@gmail.com: quote /usr/bin/ld: cannot find -lboost_program_options /quote That is the problem here, it is looking for libboost_program_options, but we only have libboost_program_options-mt. and why ? under mga1 we have libboost_program_options.so.1.44.0 and under Cauldron libboost_program_options-mt.so.1.46.1 why not libboost_program_options.so.1.46.1 ? Fedora have both , why don't we have both ? [...] how to solve this ? (sorry it is out of my skills) For some reason that particular configure check (boost::program_options::validation_error) doesn't check multi-threaded libboost_program_options-mt.so, the other ones do. I've committed a fix, hopefully it'll work. -- Ahmad Samir
Re: [Mageia-dev] Updates going to Release?
On 27 June 2011 03:11, David W. Hodgins davidwhodg...@gmail.com wrote: On my Mageia 1 install ... urpmi --auto-select --resume --noclean To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium Core Release) libxine1 1.1.19 5.mga1 i586 (medium Tainted Release) libvlc-devel 1.1.9 4.mga1.taint i586 I thought updates, and new programs would go to Core Updates, and Tainted updates, not Release. That way the release synthesis.hdlist.cz wouldn't get changed. Regards, Dave Hodgins vlc-1.1.9-4.mga1.tainted existed in the tainted/release repo before Mageia 1 was ever released, so it's not an update. Tainted packages have a higher EVR than core ones (vlc-1.1.9-4.mga1.i586 vs. vlc-1.1.9-4.mga1.tainted.i586), hence urpmi proposed to replace vlc from core by vlc from tainted. -- Ahmad Samir
Re: [Mageia-dev] Backports policy proposal
On 25 June 2011 15:52, Angelo Naselli anase...@linux.it wrote: In data sabato 25 giugno 2011 15:27:01, Balcaen John ha scritto: Le samedi 25 juin 2011 10:08:58, Angelo Naselli a écrit : In data venerdì 24 giugno 2011 16:19:45, Buchan Milne ha scritto: Sorry, but a number of my packages were regularly backported, and I never needed cooker to be older ... +1, i just had problem when the pacakges where backported into 2010.1 and that broke the upgrade to mageia 1... Well here it just mean we probably failed to check backports package :/ Well indeed i've realized later, i should have been carefull in backporting 2010.1... but 2010.1 is not mageia 1 and mag2 should upgrade mga1... even if i have some doubt after mageia 9 (mga9-mga10) ... mga10 is higher than mga9: $ rpmdev-vercmp mga9 mga10 mga9 mga10 -- Angelo -- Ahmad Samir
Re: [Mageia-dev] Proposal of a backporting process
On 25 June 2011 22:15, Samuel Verschelde sto...@laposte.net wrote: Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit : On 25 June 2011 19:33, Samuel Verschelde sto...@laposte.net wrote: Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit : On 24 June 2011 02:09, Michael Scherer m...@zarb.org wrote: - Someone request a backport ( by bugzilla, by madb, by a email, by taking a packager family in hostage, whatever ). I would prefer use bugzilla but this may not be very user friendly, or too heavy. How would the packager get notified of backports requests via madb? There are several options : - option 1 : maintainers prefer to have all backports requests in bugzilla. Madb will then create backports requests via XML-RPC, with the original reporter in CC maybe, and regularly watch bug report status. This will be extra work on madb's side and force those users (who maybe don't know how to use bugzilla) to use 1 tool for the request and a different tool for testing reports, but why not. - option 2 : maintainers are OK to use bugzilla for bugs and madb for package requests = madb will query the maintainers database and notify the maintainer(s) by mail. It could, like bugzilla, send notifications to a ML too, and provide a simple yet sufficient tracking system (status, comments). [...] Would you elaborate on how bugzilla is heavy for a backports request? Heavy I don't know, but I think that we can give users a better tool to request backports, see what backports already have been requested, etc. Yes, but what's wrong with bugzilla and better in the other tool? Bugzilla is an issue tracker, and is centered on that concept. I think that a simple request backport button in a package database browsing application can be easier and more efficient, in that the need will be more easily transmitted from the user to the packager. The backports requests we get today (and got back in mandriva) don't represent the majority of needs. I'd like to see what happens if users have a dead simple way to request them. You want to interface for users, so that they don't have to deal with a 1minute-to-fill bug report to request a backport... that's your prerogative, I don' have a problem with that as long as it works. Plus, as we want to transform requester into tester, the more requests we can get, the more users we have a chance to turn into testers... And maybe more Tester will have to use bugzilla, as that's the designated tool to contact devs/packagers... so maybe it's a good chance users become familiar with bugzilla? I'm almost sure madb will have such a request backport button. It was planned in the original specs. There's still to decide what this button does : option 1 or option 2 above, or even (but not my choice) a redirect to a prefilled form in bugzilla. There's one point that for me favors the use of a dedicated tool : the fact that several users can request the same backport. Madb will be store existing requests and associate new requesters to them if needed. This way : - we will have means to see the most demanded backports - there will be only one (if any) associated bugzilla request, and once madb detects that the backport is available for testing, it will notify all associated users, and once available for good too. I think it's easier this way than asking to users to check if there's already a backport request for this program and add yourself in CC to the bug report if there's one, otherwise create a new backport request. FWIW, such kind of duplicate reports is easy to spot and marking one bug as a dupe of another adds the user to CC automatically. Again, I am not with or against using madb, simply because I've not seen in action and can't judge it. - a packager decide to do it. Based on the policy ( outlined in another mail ), and maybe seeing with the maintainer first about that for non trivial applications, the backport can be done, or not. The criterias for being backported or not are not important to the process, just assume that they exist for now ( and look at next mail ). So based on criteria, someone say it can be backported, so I do it. [...] - I am not sure on this part, but basically, we have 2 choices : - the packager take the cauldron package and push to backport testing - the packager move the cauldron package in svn to backport, and there send it to backport testing. Proposal 1 mean less work duplication, but proposal 2 let us do more customization. Option 1 doesn't only mean not duplicating work, but also that the the spec in backports svn isn't ever out-dated; the only reason I see a package being in stable distro SVN is if it's in /release|updates, not backports... I'm not sure I understand your point. What do you mean with out-dated specs in backports ? The cauldron one got some changes/patches, the one in backports didn't get them
Re: [Mageia-dev] Proposal of a backporting process
On 24 June 2011 02:09, Michael Scherer m...@zarb.org wrote: Hi, as said in the thread of firefox 5, and in the meeting of packager sooner this week, this is the first mail about backports ( on 3 ). So here is the proposal of a process, based on the feedback of people, and the idea of some packagers ( mainly stormi ). - Someone request a backport ( by bugzilla, by madb, by a email, by taking a packager family in hostage, whatever ). I would prefer use bugzilla but this may not be very user friendly, or too heavy. How would the packager get notified of backports requests via madb? Would you elaborate on how bugzilla is heavy for a backports request? - a packager decide to do it. Based on the policy ( outlined in another mail ), and maybe seeing with the maintainer first about that for non trivial applications, the backport can be done, or not. The criterias for being backported or not are not important to the process, just assume that they exist for now ( and look at next mail ). So based on criteria, someone say it can be backported, so I do it. [...] - I am not sure on this part, but basically, we have 2 choices : - the packager take the cauldron package and push to backport testing - the packager move the cauldron package in svn to backport, and there send it to backport testing. Proposal 1 mean less work duplication, but proposal 2 let us do more customization. Option 1 doesn't only mean not duplicating work, but also that the the spec in backports svn isn't ever out-dated; the only reason I see a package being in stable distro SVN is if it's in /release|updates, not backports... if the package doesn't build, the packager fix ( or drop the idea if this requires too much work ) - the packager send requesting feedback about the backport from the people who requested it, and test it as well. Probably off-topic, but how will that work with madb? i.e. how will the maintainer get the feedback? - based on feedback ( ie if the package work or if the packager is confident ), the packager decide to move it to backport for everybody, using some stuff similar to rpmctl ( the tool we used to move package at Mandriva ). The tool would also send notifications. The packager decides to move it and he has the necessary privileges to do so? or will he have to request someone from another team to move it? - if the package doesn't work, he either fix, or drop the backport idea. If he fix, we go back on testing, if he drop, we remove the rpm ( with a automated cleaning of rpm after 1 or 2 months ). [..] If the packager drop the backport, it should be notified to the requester ( hence the use of bugzilla, or a more suitable tool ) Agreed. This way : - packages are not sent untested, thus raising confidence in backports How many times did backports breaks a user's whole installation? we always say that backports should mainly be cherry picked, but not enabled all the time... so how does installing a new version of e.g. wine break the user's system when he can easily back out that rpm? - the QA should not be overloaded, and can focus on updates - sysadmins are not overloaded - people requesting backport see how QA work, and are involved into the distribution as testers, thus creating a much healthier discussion with packagers, and creating more incentive to help. And since they request the package, they will be motivated to test more than stuff they do not use. WDYT ? -- Michael Scherer -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2
On 23 June 2011 19:17, Florian Hubold doktor5...@arcor.de wrote: Am 22.06.2011 21:45, schrieb Ahmad Samir: On 22 June 2011 20:18, nicolas vigierbo...@mars-attacks.org wrote: On Wed, 22 Jun 2011, Florian Hubold wrote: Am 22.06.2011 07:40, schrieb Ahmad Samir: On 20 June 2011 11:24, Thierry Vignaudthierry.vign...@gmail.com wrote: On 7 June 2011 16:10, Mageia Teambuildsystem-dae...@mageia.org wrote: dmorgandmorgan 3.6.1-3.mga1: + Revision: 101519 - Provide devel subpackage ( partial merge of mdv commit 659516) As always, when one moves files between subpackages or to a new subpackage, conflicts tags should be added in order to ensure urpmi will put both packages in the same transaction: Installation failed: file /usr/include/valgrind/memcheck.h from install of valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package valgrind-3.6.0-2.mga1.x86_64 file /usr/lib64/pkgconfig/valgrind.pc from install of valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package valgrind-3.6.0-2.mga1.x86_64 Done. Minor nitpick: BuildRequires for xulrunner were changed after the split, for firefox5 not. Is there any special reason for this? Just wondering ... Because the devel files are now in valgrind-devel. Yes, i know about the split, you told me in IRC ;) Yeah, there're two types of BR here, just 'valgrind' if the build requires only the binary (/usr/bin/valgrind) and valgrind-devel if the build requires the valgrind header files; AFAICS for firefox, it doesn't require the valgrind headers (i.e. I don't see any checks for the headers failing in the build log). Alright, just wanted to mention it. Could also have been an oversight ... Yep, no problem :) -- Ahmad Samir
Re: [Mageia-dev] Firefox 5
On 23 June 2011 07:58, Dexter Morgan dmorga...@gmail.com wrote: On Thu, Jun 23, 2011 at 7:29 AM, Thierry Vignaud thierry.vign...@gmail.com wrote: On 22 June 2011 19:41, Florian Hubold doktor5...@arcor.de wrote: Well, it's quite possible that we have to include that in Mageia 1 as well, as this will be security update for Firefox 4. If we don't want to patch every CVE then we have to include it into Mageia 1 as well.. Would be nice to know, if this is planned? I have rebuild FF5 here locally for Mageia 1, and the only addons that i lost is Linkification, but that is merely due to it's developers who already messed up with FF4. They don't offer the proper update on Firefox Addons site. So, please, what about Firefox 5 for Mageia 1 as an update (backport?) Humm, MGA is stricter than MDV and refuses to backport packages directly from cauldron: mgarepo submit --define section=core/backports -t 1 /dev/null Submitting xulrunner at revision 110647 URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner error: command failed: ssh pkgsubmit.mageia.org /usr/local/bin/submit_package -t 1 --define sid=4845bffd-7f94-4c8c-931e-cfb746d01a0d --define section=core/backports -r 110647 svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner error: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner is not allowed for this target yes it needs to go to backports_testing before iirc Got a link to a thread on -dev ML / irc meeting log / insert your favourite communication method here, where this was decided? But i think sec team need to speak of FF5 first because i think this will be a candidate for updates regarding new firefox upstream policy -- Ahmad Samir
Re: [Mageia-dev] Firefox 5
On 23 June 2011 22:12, Dexter Morgan dmorga...@gmail.com wrote: On Thu, Jun 23, 2011 at 9:52 PM, Ahmad Samir ahmadsamir3...@gmail.com wrote: yes it needs to go to backports_testing before iirc Got a link to a thread on -dev ML / irc meeting log / insert your favourite communication method here, where this was decided? i told iirc so this is something i recall not something i tell it must be done. i think the most important part of my sentence is the last part but maybe you didn't read it ... I did read it, however my question wasn't only about firefox, but rather about the backports policy in general, since your yes it needs to go to backports_testing before iirc wasn't about firefox only, was it? :) But i think sec team need to speak of FF5 first because i think this will be a candidate for updates regarding new firefox upstream policy -- Ahmad Samir -- Ahmad Samir
Re: [Mageia-dev] Firefox 5
On 23 June 2011 23:48, David W. Hodgins davidwhodg...@gmail.com wrote: On Thu, 23 Jun 2011 15:52:30 -0400, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 23 June 2011 07:58, Dexter Morgan dmorga...@gmail.com wrote: yes it needs to go to backports_testing before iirc Got a link to a thread on -dev ML / irc meeting log / insert your favourite communication method here, where this was decided? This mailing list, thread Release cycles proposals, and discussion, messageid BANLkTimrPR-=ugqonfvakqpft80lni9...@mail.gmail.com Where Anne posted ... exactly what I had in mind. Having backports can allow choice between the last version of and the stable version with which I'm happy with. But indeed we need more quality in backport rpms that is policy and tests. In order for the qa team to perform the tests, before they go to the backports repository, they have to go to to the testing repository first. 1) It doesn't say we're going to use backports_testing, does it? guessing != an instated policy 2) IMHO, QA is too small to handle backports too Something that works in cauldron may not work when moved to backports, if a dependency is missed. By using backports_testing, we can catch that before it hits the average user. Regards, Dave Hodgins Right so, the plan is: - A packager submits to backports_testing and assigns to QA - QA tests, the package is good to go - The report is assigned to whoever has privileges to move packages from backports_testing to backports, atm that's sysadm team - Package is moved and the report closed Caveats: - QA is too small, and it'll take time/effort to get through the backported packages requiring tests, unless you depend on the user asking for the backport to have tested the package properly, the user will say it works if it works on his box for the arch he's using, he won't do both archs, not just because he's lazy, but maybe he has one Mageia box for example - Sysadm team is already overworked with many other tasks, meaning the packages requiring a move will rot for a while in backports_testing. Now compare that to what's used in e.g. mdv: - User asks for a backport - Packager submits the backport and closes the report Do you see the problem I am talking about yet? adding more complexity to backporting may result in less backports; the more the hoops, the less the backports, the more the users' complaints about I-want-the-latest-version-of-foo-yesterday. The quality of backports is a sentence that lacks statistics and numbers; in e.g. mdv, how many packages were backported to release foo? how many of them worked(tm)? how many of them didn't work and required a bit of fixing? how many of them didn't work and won't work due to any number of reasons? I think backports in mdv worked pretty well all those years, not all of them worked, but most of them did. -- Ahmad Samir
Re: [Mageia-dev] Firefox 5
On 24 June 2011 00:06, Michael Scherer m...@zarb.org wrote: Le jeudi 23 juin 2011 à 17:48 -0400, David W. Hodgins a écrit : On Thu, 23 Jun 2011 15:52:30 -0400, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 23 June 2011 07:58, Dexter Morgan dmorga...@gmail.com wrote: yes it needs to go to backports_testing before iirc Got a link to a thread on -dev ML / irc meeting log / insert your favourite communication method here, where this was decided? This mailing list, thread Release cycles proposals, and discussion, messageid BANLkTimrPR-=ugqonfvakqpft80lni9...@mail.gmail.com Where Anne posted ... exactly what I had in mind. Having backports can allow choice between the last version of and the stable version with which I'm happy with. But indeed we need more quality in backport rpms that is policy and tests. In order for the qa team to perform the tests, before they go to the backports repository, they have to go to to the testing repository first. Something that works in cauldron may not work when moved to backports, if a dependency is missed. By using backports_testing, we can catch that before it hits the average user. I think the question of ahmad was about backport vs updates. And I think firefox is suitable for the list of package exceptions that should be backported rather than using a patch ( see http://mageia.org/wiki/doku.php?id=updates_policy ). And so, since I guess everybody assume that ff and chromium can go in the list, as they are unsupported upstream _and_ too complex to fix with a patch. And to answer to am -- Michael Scherer Actually no, I meant the submit to backports privileges vs. only being able to submit to backports_testing. -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2
On 22 June 2011 20:18, nicolas vigier bo...@mars-attacks.org wrote: On Wed, 22 Jun 2011, Florian Hubold wrote: Am 22.06.2011 07:40, schrieb Ahmad Samir: On 20 June 2011 11:24, Thierry Vignaudthierry.vign...@gmail.com wrote: On 7 June 2011 16:10, Mageia Teambuildsystem-dae...@mageia.org wrote: dmorgandmorgan 3.6.1-3.mga1: + Revision: 101519 - Provide devel subpackage ( partial merge of mdv commit 659516) As always, when one moves files between subpackages or to a new subpackage, conflicts tags should be added in order to ensure urpmi will put both packages in the same transaction: Installation failed: file /usr/include/valgrind/memcheck.h from install of valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package valgrind-3.6.0-2.mga1.x86_64 file /usr/lib64/pkgconfig/valgrind.pc from install of valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package valgrind-3.6.0-2.mga1.x86_64 Done. Minor nitpick: BuildRequires for xulrunner were changed after the split, for firefox5 not. Is there any special reason for this? Just wondering ... Because the devel files are now in valgrind-devel. Yeah, there're two types of BR here, just 'valgrind' if the build requires only the binary (/usr/bin/valgrind) and valgrind-devel if the build requires the valgrind header files; AFAICS for firefox, it doesn't require the valgrind headers (i.e. I don't see any checks for the headers failing in the build log). -- Ahmad Samir
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
On 22 June 2011 22:47, Radu-Cristian FOTESCU beranger...@yahoo.ca wrote: I'm known to be grumpy and difficult, but I also believe in simplicity as a policy, therefore I'd like to ask you something. By no means I want to question Ahmad's judgment, however I strongly disagree with him on one point. As a _principle_. Otherwise, it's a tiny punctual question, but I'd like to know Mageia's patching _policy_. See comments 50 and downwards: https://bugs.mageia.org/show_bug.cgi?id=1659#c50 calibre-python2-env-fix.patch replaces '/usr/bin/env python2' with '/usr/bin/env python' The calibre developer has used '/usr/bin/env python' for ages, but relatively recently he has decided to switch to '/usr/bin/env python2' for fear that some distros would use Python 3 by default. Ahmad insists that '/usr/bin/python' should be used in Mageia. Actually, I said that the shebang should be removed altogether. Which is what was being done all those years calibre existed in the Mandriva repos (the same for Fedora, since they do remove the shebang, as the calibre spec was originally imported from Fedora, which I said in the report too). As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work. I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages! A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug. Should Mageia try to fix something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works? You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. Perfect policies that would require the revision of hundreds of packages that actually work are not my cup of tea. Of course, I am _not_ a Mageia packager and this is not my package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to improve upstream's work, this can prove to be catastrophic in complex cases. Thank you, R-C aka beranger -- Ahmad Samir
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
On 22 June 2011 23:14, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 22 June 2011 22:47, Radu-Cristian FOTESCU beranger...@yahoo.ca wrote: I'm known to be grumpy and difficult, but I also believe in simplicity as a policy, therefore I'd like to ask you something. By no means I want to question Ahmad's judgment, however I strongly disagree with him on one point. As a _principle_. Otherwise, it's a tiny punctual question, but I'd like to know Mageia's patching _policy_. See comments 50 and downwards: https://bugs.mageia.org/show_bug.cgi?id=1659#c50 calibre-python2-env-fix.patch replaces '/usr/bin/env python2' with '/usr/bin/env python' The calibre developer has used '/usr/bin/env python' for ages, but relatively recently he has decided to switch to '/usr/bin/env python2' for fear that some distros would use Python 3 by default. Ahmad insists that '/usr/bin/python' should be used in Mageia. Actually, I said that the shebang should be removed altogether. Which is what was being done all those years calibre existed in the Mandriva repos (the same for Fedora, since they do remove the shebang, as the calibre spec was originally imported from Fedora, which I said in the report too). Of course, or just /usr/bin/python. The /usr/bin/env way may be useful for upstream when creating binary tarballs; but not for us we build the package, and we know which version of python exists in the release we're pushing it to. Also, /usr/bin/python2 doesn't exist to begin with, as mikala pointed out. As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work. I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages! A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug. Should Mageia try to fix something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works? You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. Perfect policies that would require the revision of hundreds of packages that actually work are not my cup of tea. Of course, I am _not_ a Mageia packager and this is not my package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to improve upstream's work, this can prove to be catastrophic in complex cases. Thank you, R-C aka beranger -- Ahmad Samir -- Ahmad Samir
Re: [Mageia-dev] glib-compile-schemas?
On 21 June 2011 11:00, Funda Wang fundaw...@gmail.com wrote: Hello, Look at this change, http://svnweb.mageia.org/packages/cauldron/anjuta-extras/current/SPECS/anjuta-extras.spec?view=patchr1=89r2=98pathrev=99 I remembered such a post/postun script is handled by rpm triggers? see: /var/lib/rpm/filetriggers/glib-compile-schemas.* Will it need to be handled separately in individual package? I am not sure, I think that change should be reverted; indeed, it's already handled by an rpm filetrigger... -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2
On 20 June 2011 11:24, Thierry Vignaud thierry.vign...@gmail.com wrote: On 7 June 2011 16:10, Mageia Team buildsystem-dae...@mageia.org wrote: dmorgan dmorgan 3.6.1-3.mga1: + Revision: 101519 - Provide devel subpackage ( partial merge of mdv commit 659516) As always, when one moves files between subpackages or to a new subpackage, conflicts tags should be added in order to ensure urpmi will put both packages in the same transaction: Installation failed: file /usr/include/valgrind/memcheck.h from install of valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package valgrind-3.6.0-2.mga1.x86_64 file /usr/lib64/pkgconfig/valgrind.pc from install of valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package valgrind-3.6.0-2.mga1.x86_64 Done. -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
On 15 June 2011 22:32, Stew Benedict stewbi...@gmail.com wrote: On 06/15/2011 09:22 AM, Stew Benedict wrote: On 06/15/2011 08:50 AM, Dexter Morgan wrote: On Wed, Jun 15, 2011 at 2:20 PM, Thomas Backlundt...@mageia.org wrote: BTW, should we have a read-only security/update-announce ml that where we mail about all updates ? yes seems a must have to push updates descriptions , distributions affected, ... That is accounted for in the policy document (last line) Due to the unbridled enthusiasm for getting started on updates, we now have 4 trial packages :) vde2, mysql, curl, subversion Bugs: https://bugs.mageia.org/show_bug.cgi?id=1678 (vde2) https://bugs.mageia.org/show_bug.cgi?id=1554 (mysql) https://bugs.mageia.org/show_bug.cgi?id=1813 (curl) https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion) Packages need fixes applied, built for mga1 (I believe mysql is already in updates_testing), packager should do some initial testing then re-assign the bug to QA QA process for updates: http://mageia.org/wiki/doku.php?id=qa_updates -- Stew Benedict qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. The same for sec team, there should be a way to assign/put-in-CC. -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release rhythmbox-0.13.3-7.mga2
2011/6/16 JA Magallón jamagal...@ono.com: On Tue, 14 Jun 2011 18:32:23 +0200 (CEST), Mageia Team buildsystem-dae...@mageia.org wrote: Name : rhythmbox Relocations: (not relocatable) Version : 0.13.3 Vendor: Mageia.Org Release : 7.mga2 Build Date: Tue Jun 14 18:24:25 2011 Install Date: (not installed) Build Host: ecosse Group : Sound Source RPM: (none) Size : 10009472 License: GPLv2+ with exception Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://www.gnome.org/projects/rhythmbox/ Summary : Music Management Application Description : Music Management application with support for ripping audio-cd's, playback of Ogg Vorbis and Mp3 and burning of CD-Rs. dmorgan dmorgan 0.13.3-7.mga2: + Revision: 106171 - Fix file list - Add libproxy-devel as buildRequire - Rebuild against new brasero Needs another rebuild for new gnome-media: ne:~# rpm -qa *gnome-media* lib64gnome-media0-2.32.0-3.mga1 gnome-media-2.91.2-1.mga2 libgnome-media-profiles-3.0.0-6.mga2 lib64gnome-media-profiles0-3.0.0-6.mga2 one:~# urpme lib64gnome-media0 To satisfy dependencies, the following 3 packages will be removed (15MB): lib64gnome-media0-2.32.0-3.mga1.x86_64 lib64rhythmbox3-0.13.3-7.mga2.x86_64 (due to missing libgnome-media-profiles.so.0()(64bit)) rhythmbox-0.13.3-7.mga2.x86_64 (due to missing librhythmbox-core.so.3()(64bit), due to unsatisfied lib64rhythmbox3 = 0.13.3-7.mga2) Remove 3 packages? (y/N) -- J.A. Magallon jamagallon()ono!com \ Winter is coming... It'll require more than a rebuild; most likely we'll have to push a git snapshot of rhythmbox due to the gtk+3.0 changes (pterjan said he'll take care of it), should be soon. -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release rhythmbox-0.13.3-7.mga2
2011/6/17 JA Magallón jamagal...@ono.com: On Thu, 16 Jun 2011 21:12:39 +0300, Ahmad Samir ahmadsamir3...@gmail.com wrote: 2011/6/16 JA Magallón jamagal...@ono.com: On Tue, 14 Jun 2011 18:32:23 +0200 (CEST), Mageia Team buildsystem-dae...@mageia.org wrote: Name : rhythmbox Relocations: (not relocatable) Version : 0.13.3 Vendor: Mageia.Org Release : 7.mga2 Build Date: Tue Jun 14 18:24:25 2011 Needs another rebuild for new gnome-media: ne:~# rpm -qa *gnome-media* lib64gnome-media0-2.32.0-3.mga1 gnome-media-2.91.2-1.mga2 libgnome-media-profiles-3.0.0-6.mga2 lib64gnome-media-profiles0-3.0.0-6.mga2 one:~# urpme lib64gnome-media0 To satisfy dependencies, the following 3 packages will be removed (15MB): lib64gnome-media0-2.32.0-3.mga1.x86_64 lib64rhythmbox3-0.13.3-7.mga2.x86_64 (due to missing libgnome-media-profiles.so.0()(64bit)) rhythmbox-0.13.3-7.mga2.x86_64 (due to missing librhythmbox-core.so.3()(64bit), due to unsatisfied lib64rhythmbox3 = 0.13.3-7.mga2) Remove 3 packages? (y/N) ... It'll require more than a rebuild; most likely we'll have to push a git snapshot of rhythmbox due to the gtk+3.0 changes (pterjan said he'll take care of it), should be soon. Ahh, the pleasure of going bleeding edge... So the release of Gnome 3 is just the platform, everything around it has not caught up yet... One or two apps != everything :) I guess, that's normal with huge changes, it takes time till the ripple effect covers the whole pond. -- J.A. Magallon jamagallon()ono!com \ Winter is coming... -- Ahmad Samir
[Mageia-dev] nspluginwrapper reborn!
Hello, nspluginwrapper has been updated to 1.3.x and now to 1.4.x, i.e. it has a new upstream maintainer http://nspluginwrapper.davidben.net For the first time in probably 2-3years, the 32bit Adobe Flash player seemed to work for me in a 64bit browser (I tested firefox and konqueror). So give it a shot. (I've been suggesting, to users, _not_ to use nspluginwrapper for some years now, since it never worked for me and I saw a lot of reports of it not working in forums and bug reports, so this is my I take that back, it just needed some upstream love and care). -- Ahmad Samir
