Re: [Mageia-dev] [116308]
On Thu, Jun 30, 2011 at 8:38 AM, r...@mageia.org wrote:
Revision 116308 Author ze Date 2011-06-30 08:38:32 +0200 (Thu, 30 Jun 2011)
Log Message
- add missing files
- fix minor errors
- list dirs so that can be removed in uninstall
Modified Paths
cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec
Modified: cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec
===
--- cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec 2011-06-30
06:13:28
UTC (rev 116307)
+++ cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec 2011-06-30
06:38:32
UTC (rev 116308)
@@ -95,15 +95,11 @@
%files -n kde4-filesharing
%defattr(-,root,root)
-%_kde_libdir/kde4/fileshare_propsdlgplugin.so
-%_kde_libdir/kde4/kcm_fileshare.so
-%_kde_libdir/kde4/kcm_kcmsambaconf.so
-%_kde_services/fileshare.desktop
-%_kde_services/fileshare_propsdlgplugin.desktop
-%_kde_services/kcmsambaconf.desktop
+%_kde_libdir/kde4/sambausershareplugin.so
+%_kde_services/sambausershareplugin.desktop
%_kde_services/ServiceMenus/smb2rdc.desktop
-%_kde_iconsdir/*/*/apps/kcmsambaconf.*
+
#-
%package -n kdnssd
Summary: DNS-SD Service Discovery Monitor
@@ -124,7 +120,7 @@
%_kde_services/zeroconf.protocol
#-
-%define libkgetcore %mklibname kgetcore %{%major}
+%define libkgetcore %mklibname kgetcore %{major}
%package -n %libkgetcore
Summary: Runtime library for KGET
@@ -135,7 +131,7 @@
%files -n %libkgetcore
%defattr(-,root,root)
-%_kde_libdir/libkgetcore.so.%{%major}*
+%_kde_libdir/libkgetcore.so.%{major}*
#-
%package -n kget
@@ -159,23 +155,28 @@
%defattr(-,root,root)
%_kde_bindir/kget
%_kde_appsdir/kget
+%_kde_applicationsdir/kget.desktop
%_kde_libdir/kde4/krunner_kget.so
%_kde_libdir/kde4/kget_*
%_kde_libdir/kde4/plasma_engine_kget.so
%_kde_libdir/kde4/kcm_kget_checksumsearchfactory.so
%_kde_libdir/kde4/kcm_kget_metalinkfactory.so
%_kde_services/plasma-engine-kget.desktop
-%_kde_datadir/applications/kde4/kget.desktop
%_kde_services/ServiceMenus/kget_download.desktop
%_kde_datadir/config.kcfg/kget*
%_kde_services/kget_*
%_kde_datadir/kde4/servicetypes/kget_*
+%dir %_kde_appsdir/dolphinpart/kpartplugins/
%_kde_appsdir/dolphinpart/kpartplugins/kget_plug_in.rc
%_kde_appsdir/dolphinpart/kpartplugins/kget_plug_in.desktop
+%dir %_kde_appsdir/khtml/kpartplugins/
Dirs must be owned by only one rpm. Do you think clever to own those
ones by kdenetwork4 ? i don't think.
I will revert and fix a better way
Re: [Mageia-dev] How is the obsoleted binaries be removed?
'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
2011/6/30 Dexter Morgan dmorga...@gmail.com:
On Wed, Jun 29, 2011 at 7:42 PM, Zé mmode...@gmail.com wrote:
2011/6/27 Funda Wang fundaw...@gmail.com:
Hello,
How is the obsoleted binaries be removed currently in Mageia? Does the
maintainer need to call for this? If yes, please remove
lib{,64}devhelp-2_1 from cauldron.
Thanks.
whats current problem?
You can obsolete it through BS, add an entry in the spec about it.
our policy is to not obsolete libs.
Then the repository will contain a lot of orphan libs.
I think Dexter was just replying to Ze rather than yourself Funda.
Meaning we don't obsolete libs in the spec file (as was true in mdv), so
removing old libs no longer used internally is still a manual
(rpmctl-type) task.
Col
--
Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] How is the obsoleted binaries be removed?
Le jeudi 30 juin 2011 à 09:41 +0100, Colin Guthrie a écrit :
'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
2011/6/30 Dexter Morgan dmorga...@gmail.com:
On Wed, Jun 29, 2011 at 7:42 PM, Zé mmode...@gmail.com wrote:
2011/6/27 Funda Wang fundaw...@gmail.com:
Hello,
How is the obsoleted binaries be removed currently in Mageia? Does the
maintainer need to call for this? If yes, please remove
lib{,64}devhelp-2_1 from cauldron.
Thanks.
whats current problem?
You can obsolete it through BS, add an entry in the spec about it.
our policy is to not obsolete libs.
Then the repository will contain a lot of orphan libs.
I think Dexter was just replying to Ze rather than yourself Funda.
Meaning we don't obsolete libs in the spec file (as was true in mdv), so
removing old libs no longer used internally is still a manual
(rpmctl-type) task.
I do not know if I proposed that already, but what about moving rpms
without source rpms after 2 weeks ( or 1 month ) ?
( and later remove the file after 1 month ). This let us the time to
rebuild everything, and provides automated cleaning ?
--
Michael Scherer
Re: [Mageia-dev] How is the obsoleted binaries be removed?
On Thu, Jun 30, 2011 at 11:08 AM, Michael Scherer m...@zarb.org wrote:
Le jeudi 30 juin 2011 à 09:41 +0100, Colin Guthrie a écrit :
'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
2011/6/30 Dexter Morgan dmorga...@gmail.com:
On Wed, Jun 29, 2011 at 7:42 PM, Zé mmode...@gmail.com wrote:
2011/6/27 Funda Wang fundaw...@gmail.com:
Hello,
How is the obsoleted binaries be removed currently in Mageia? Does the
maintainer need to call for this? If yes, please remove
lib{,64}devhelp-2_1 from cauldron.
Thanks.
whats current problem?
You can obsolete it through BS, add an entry in the spec about it.
our policy is to not obsolete libs.
Then the repository will contain a lot of orphan libs.
I think Dexter was just replying to Ze rather than yourself Funda.
Meaning we don't obsolete libs in the spec file (as was true in mdv), so
removing old libs no longer used internally is still a manual
(rpmctl-type) task.
I do not know if I proposed that already, but what about moving rpms
without source rpms after 2 weeks ( or 1 month ) ?
( and later remove the file after 1 month ). This let us the time to
rebuild everything, and provides automated cleaning ?
--
Michael Scherer
i agree with this and as they are on old/ we still can revive some if
needed ( like a rebuild not done, ... )
Re: [Mageia-dev] [116351]
On Thu, Jun 30, 2011 at 11:24 AM, r...@mageia.org wrote: Revision 116351 Author ze Date 2011-06-30 11:24:58 +0200 (Thu, 30 Jun 2011) Log Message - set default files attibutes No this is useless, please remove them
Re: [Mageia-dev] How is the obsoleted binaries be removed?
'Twas brillig, and Michael Scherer at 30/06/11 10:08 did gyre and gimble:
Le jeudi 30 juin 2011 à 09:41 +0100, Colin Guthrie a écrit :
'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
2011/6/30 Dexter Morgan dmorga...@gmail.com:
On Wed, Jun 29, 2011 at 7:42 PM, Zé mmode...@gmail.com wrote:
2011/6/27 Funda Wang fundaw...@gmail.com:
Hello,
How is the obsoleted binaries be removed currently in Mageia? Does the
maintainer need to call for this? If yes, please remove
lib{,64}devhelp-2_1 from cauldron.
Thanks.
whats current problem?
You can obsolete it through BS, add an entry in the spec about it.
our policy is to not obsolete libs.
Then the repository will contain a lot of orphan libs.
I think Dexter was just replying to Ze rather than yourself Funda.
Meaning we don't obsolete libs in the spec file (as was true in mdv), so
removing old libs no longer used internally is still a manual
(rpmctl-type) task.
I do not know if I proposed that already, but what about moving rpms
without source rpms after 2 weeks ( or 1 month ) ?
( and later remove the file after 1 month ). This let us the time to
rebuild everything, and provides automated cleaning ?
I agree in principle, but I would say:
1. Move rpms with no src.rpm after 2 weeks when there are no
(unobsoleted) rpms that depend on it.
2. If other rpms do depend on it, send an automated mail to cauldron to
tell people to rebuild them against the newer lib.
Other than that small caveat... yeah it seems like a nice idea!
Col
--
Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2
2011/6/30 Balcaen John mik...@mageia.org: On Thursday 30 June 2011 04:45:15 Mageia Team wrote: Name : libkdeedu Relocations: (not relocatable) Version : 4.6.90 Vendor: Mageia.Org Release : 4.mga2 Build Date: Thu Jun 30 04:40:17 2011 Install Date: (not installed) Build Host: ecosse Group : Graphical desktop/KDE Source RPM: (none) Size : 204136 License: GPLv2 Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://edu.kde.org Summary : Free Educational Software based on the KDE technologies Description : Runtime library for KDE Education Application fwang fwang 4.6.90-4.mga2: + Revision: 116239 - do not obsolete old packages I do understand that you don't wont to obsolete kdeedu,but without the obsolete kdeedu-core kdeedu-devel would have been stick for ever on the mirror until a sysadmin intervention. Agree. But such a task shouldn't be pushed into packaging, and we have already push needed conflicts so that it won't affect users. -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2
On Thursday 30 June 2011 04:45:15 Mageia Team wrote: Name: libkdeeduRelocations: (not relocatable) Version : 4.6.90Vendor: Mageia.Org Release : 4.mga2Build Date: Thu Jun 30 04:40:17 2011 Install Date: (not installed) Build Host: ecosse Group : Graphical desktop/KDE Source RPM: (none) Size: 204136 License: GPLv2 Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://edu.kde.org Summary : Free Educational Software based on the KDE technologies Description : Runtime library for KDE Education Application fwang fwang 4.6.90-4.mga2: + Revision: 116239 - do not obsolete old packages I do understand that you don't wont to obsolete kdeedu,but without the obsolete kdeedu-core kdeedu-devel would have been stick for ever on the mirror until a sysadmin intervention. -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2
On Thu, Jun 30, 2011 at 1:01 PM, Funda Wang fundaw...@gmail.com wrote: 2011/6/30 Balcaen John mik...@mageia.org: On Thursday 30 June 2011 04:45:15 Mageia Team wrote: Name : libkdeedu Relocations: (not relocatable) Version : 4.6.90 Vendor: Mageia.Org Release : 4.mga2 Build Date: Thu Jun 30 04:40:17 2011 Install Date: (not installed) Build Host: ecosse Group : Graphical desktop/KDE Source RPM: (none) Size : 204136 License: GPLv2 Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://edu.kde.org Summary : Free Educational Software based on the KDE technologies Description : Runtime library for KDE Education Application fwang fwang 4.6.90-4.mga2: + Revision: 116239 - do not obsolete old packages I do understand that you don't wont to obsolete kdeedu,but without the obsolete kdeedu-core kdeedu-devel would have been stick for ever on the mirror until a sysadmin intervention. Agree. But such a task shouldn't be pushed into packaging, and we have already push needed conflicts so that it won't affect users. don't forget to tell to your lovely sysadmin team the packages you want to be removed ;)
[Mageia-dev] updates-announce mailing list
Hello, People who want to receive notifications of updates on the stable release can subscribe to the updates-announce mailing list : https://ml.mageia.org/wwsympa-wrapper.fcgi/info/updates-announce
Re: [Mageia-dev] updates-announce mailing list
Le jeudi 30 juin 2011 à 14:33 +0200, nicolas vigier a écrit : Hello, People who want to receive notifications of updates on the stable release can subscribe to the updates-announce mailing list : https://ml.mageia.org/wwsympa-wrapper.fcgi/info/updates-announce Is there a simple web page planned? like http://www.mandriva.com/fr/support/security/advisories/?dis=2010.1
Re: [Mageia-dev] updates-announce mailing list
On Thu, 30 Jun 2011, Manuel Hiebel wrote: Le jeudi 30 juin 2011 à 14:33 +0200, nicolas vigier a écrit : Hello, People who want to receive notifications of updates on the stable release can subscribe to the updates-announce mailing list : https://ml.mageia.org/wwsympa-wrapper.fcgi/info/updates-announce Is there a simple web page planned? like http://www.mandriva.com/fr/support/security/advisories/?dis=2010.1 Yes. It is not done yet, but it is planned. https://www.mageia.org/pipermail/mageia-dev/2011-June/006092.html
Re: [Mageia-dev] Update of backport, policy proposal
Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit : Hi, The last mail from the backport trilogy. And like all good trilogy, that's where the suspens is present ( as for the 1 and 2 part, you know there is another episode ) This mail is about handling update on the backport repository. Either new version, or bugfix, or security upgrade. Everybody was focused on should we do patch, or should we do more backport issue, but the real problem is not really here. First, we have to decide what kind of update do we want to see, among the 3 types : - bugfixes - security bug fixes, - new version As I said in another thread, I think that for backports we can allow ourselves to rely more heavily on the upstream projects than we do for stable updates. - we try to provide the new upstream stable versions when asked for and conform to the policy - we guarantee support for packaging bugs (those are our bugs) - for bugs : -- they are fixed in a new upstream stable version : we provide it. -- they are not : we don't fix them. We're providing the latest from upstream, those bugs have to be fixed upstream. -- complex cases : fix available upstream but in a development branch and no release soon, or new version non backportable for technical or policy reasons = we patch -- of course nothing prevents diligent packagers from going farther and putting more energy in bug fixing when upstream is failing, but it's not what we promise to do for all backports. - security bugs : I see 2 options. The easier for us is to treat them like the other bugs : rely on upstream fixes. Maybe this gives an acceptable level of risk. The other solution is a full security process similar to the one we have for stable updates. I would start with the first one and see later if we can switch to the second one. For comparison, the level of support for stable updates is : - we try to bring as little changes to the package as possible, with the ideal situation being not having to issue updates at all, - we guarantee support for packaging bugs (those are our bugs) - for bugs : -- they are fixed upstream : we backport patches from upstream newer releases, or provide upstream new stable bugfix-only releases. Occasionnally a non bugfix- only new version can be provided, with a sufficient amount of QA and if the new version doesn't change users habits too much. -- they are not fixed upstream : we try to fix it ourselves or get patches from other distributions - security bugs : fully supported, even more than standard bugs, and without waiting for users to report security bugs. As we have to explain what the differences in terms of support between updates and backports is, to ourselves but also to users, here is how I would describe it : - updates : report bugs to us first. - backports : ask for a newer stable version if a bug has been fixed there, or report bugs to both the software's developers and us Then as we want to have working backports, I think we need to do test, like we do for normal backports, or updates. This mean someone need to test, besides the packagers. For the first one, we can assume that if there is a bug, someone will fill it. Then we can assign it to the one that backported to fix the packages, and ask the reporter to test. Agreed. For the 3rd one, I guess we can use the same as 1st one. If no one ask, do nothing. If someone ask, do the same as others backports, and erase the previous one. Agreed. For the 2nd one, it all depend on how we find out about security issues. A tool like the one used by debian/ubuntu that check for each package if the version is vulnerable or not could help packager to know if a backport requires a fix or not, like this is done for the others packages. That could help indeed, such a tool could automatically create a bug report in bugzilla via XML-RPC for example. Useful for stable updates also of course. However, this mean that someone will have to check if the bug is fixed, and the question is who ( and I do not have a answer that I find good enough yet ). This could even be more tricky if we consider that this can be a version upgrade, and a security fix. Even if we trust the upstream to fix the security issue, we still want to have it working. That's a good question, given that priority will be given to stable updates testing rather than backports. With a big security team I would say the security team, but for now I would trust the upstream here. But besides this question, there is a more important problem. If we think that some packages updates are important enough to be sent to user without them asking for explicitly, we cannot let people pick only some packages on demand by disabling backports. Either backports source is enabled in urpmi, and this would mean that backports are treated like update from a user point of view, or the backports are enabled on demand, meaning that the user is on his
Re: [Mageia-dev] Update of backport, policy proposal
Le mardi 28 juin 2011 03:44:24, andre999 a écrit : 2) Backports would not be removed from repos when a newer backport arrives, except those affected by security updates. This allows reverting to previous backports if a user finds a problem with a backport on their system. I'd prefer that we don't keep multiple backports versions in the repositories, for the sake of simplicity. Users who ask for the latest must accept that sometimes the latest is not the greatest. Plus, we have the backports_testing repos so that users can test and spot bugs before the old backport is replaced with the new one. I want stable : don't use backports. I want the latest : use backports. I want an intermediate version : no, sorry, your need is too specific. You can still compile it. Samuel
Re: [Mageia-dev] Update of backport, policy proposal
Le jeudi 30 juin 2011 15:59:21, Samuel Verschelde a écrit : Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit : However, this mean that someone will have to check if the bug is fixed, and the question is who ( and I do not have a answer that I find good enough yet ). This could even be more tricky if we consider that this can be a version upgrade, and a security fix. Even if we trust the upstream to fix the security issue, we still want to have it working. That's a good question, given that priority will be given to stable updates testing rather than backports. With a big security team I would say the security team, but for now I would trust the upstream here. Or rather, the packager who backported the software, with the help of the security team and/or QA team if needed. Samuel
Re: [Mageia-dev] Update of backport, policy proposal
On Thu, 30 Jun 2011, Samuel Verschelde wrote: Le mardi 28 juin 2011 03:44:24, andre999 a écrit : 2) Backports would not be removed from repos when a newer backport arrives, except those affected by security updates. This allows reverting to previous backports if a user finds a problem with a backport on their system. I'd prefer that we don't keep multiple backports versions in the repositories, for the sake of simplicity. Users who ask for the latest must accept that sometimes the latest is not the greatest. Plus, we have the backports_testing repos so that users can test and spot bugs before the old backport is replaced with the new one. I want stable : don't use backports. I want the latest : use backports. I want an intermediate version : no, sorry, your need is too specific. You can still compile it. I think we can still keep the old versions on the repository. urpmi will install the last one, but allow advanced users to use rpm manually to install an older version if needed. However I don't think we should make updates on older versions.
Re: [Mageia-dev] Update of backport, policy proposal
Le mardi 28 juin 2011 03:44:24, andre999 a écrit : 2) Backports would not be removed from repos when a newer backport arrives, except those affected by security updates. This allows reverting to previous backports if a user finds a problem with a backport on their system. I'd prefer that we don't keep multiple backports versions in the repositories, for the sake of simplicity. Users who ask for the latest must accept that sometimes the latest is not the greatest. Plus, we have the backports_testing repos so that users can test and spot bugs before the old backport is replaced with the new one. I want stable : don't use backports. I want the latest : use backports. I want an intermediate version : no, sorry, your need is too specific. You can still compile it. Samuel Le mardi 28 juin 2011 03:44:24, andre999 a écrit : 2) Backports would not be removed from repos when a newer backport arrives, except those affected by security updates. This allows reverting to previous backports if a user finds a problem with a backport on their system. I'd prefer that we don't keep multiple backports versions in the repositories, for the sake of simplicity. Users who ask for the latest must accept that sometimes the latest is not the greatest. Plus, we have the backports_testing repos so that users can test and spot bugs before the old backport is replaced with the new one. I want stable : don't use backports. I want the latest : use backports. I want an intermediate version : no, sorry, your need is too specific. You can still compile it. Samuel Well sometimes latest version comes with bug corrections so it may be considered as more stable than the previous version. Olivier
[Mageia-dev] Need mentor(s) to become a Mageia packager
Hi All,
I would like to participate to your project and to help you by packaging
rpms.
As I don't know what needs to be packed, I've tried to make rpm for
ZoneMinder 1.24.4. But it fails to install into BUILDROOT environment. I
must have done something wrong while setting installation destinations.
Attached is the spec file, and the patch to make it compiled.
If any mentor could help me, or assign me something else to pack, I would be
glad.
Regards
Vincent
--- ./src/zm_rtsp.cpp.orig 2011-06-30 13:37:20.175609094 -0400
+++ ./src/zm_rtsp.cpp 2011-06-30 13:37:46.618610480 -0400
@@ -311,7 +311,7 @@
}
catch( const Exception e )
{
-Error( e.getMessage().c_str() );
+Error( %s, e.getMessage().c_str() );
return( -1 );
}
--- ./src/zm_signal.cpp.orig 2011-06-30 13:44:42.850610241 -0400
+++ ./src/zm_signal.cpp 2011-06-30 13:48:02.785610651 -0400
@@ -109,7 +109,7 @@
char **messages = backtrace_symbols( trace, trace_size );
if ( size_t offset = strcspn( messages[trace_size-1], ) )
{
-snprintf( cmd_ptr, sizeof(cmd)-(cmd_ptr-cmd), messages[trace_size-1] );
+snprintf( cmd_ptr, sizeof(cmd)-(cmd_ptr-cmd), %s, messages[trace_size-1] );
cmd_ptr += offset;
}
else
@@ -123,7 +123,7 @@
cmd_ptr += snprintf( cmd_ptr, sizeof(cmd)-(cmd_ptr-cmd), %p, trace[i] );
}
Info( Backtrace complete, please execute the following command for more information );
-Info( cmd );
+Info( %s, cmd );
#endif // HAVE_DECL_BACKTRACE
#endif // ( HAVE_SIGINFO_T HAVE_UCONTEXT_T ) || HAVE_STRUCT_SIGCONTEXT
#endif // ZM_NO_CRASHTRACE
%define name ZoneMinder
%define version 1.24.4
%define release %mkrel 1
Summary: ZoneMinder, the all-in one Linux GPL'd security camera solution.
Name: %{name}
Version: %{version}
Release: %{release}
URL: http://www.zoneminder.com/
Source0: http://www2.zoneminder.com/downloads/%{name}-%{version}.tar.gz
Patch0: ZoneMinder-1.24.4-src.patch
License: GPLV2 or later
Group: Multimedia
BuildRequires: automake
BuildRequires: ffmpeg
BuildRequires: gnutls-devel
BuildRequires: %{_lib}ffmpeg-devel
BuildRequires: %{_lib}gnutls-devel
BuildRequires: %{_lib}jpeg-devel
BuildRequires: %{_lib}mysql-devel
BuildRequires: %{_lib}pcre-devel
BuildRequires: perl(Archive::Tar)
BuildRequires: perl(Archive::Zip)
BuildRequires: perl(Date::Manip)
BuildRequires: perl(DBD::mysql)
BuildRequires: perl(Device::SerialPort)
BuildRequires: perl(MIME::Lite)
%description
Welcome to ZoneMinder, the all-in-one Linux GPL'd security camera solution.
A while back my garage was burgled and all my power tools were stolen! I realized shortly after that if I'd just had a camera overlooking the door then at least I'd have know exactly when and who did the dirty deed. And so ZoneMinder was born. It's still relatively new but hopefully it has developed into something that can be genuinely useful and prevent similar incidents or even perhaps bring some perpetrators to justice.
PROPOSED ADDITION Most commercial security systems are designed as a monitoring system that also records. Recording quality can vary from bad to unusable, locating the relevant video can range from challenging to impractical, and exporting can often only be done with the manual present. ZoneMinder was designed primarily to record, and allow easy searches and exporting. Recordings are of the best possible quality, easy to filter and find, and simple to export using any system with a web browser. It also monitors.
ZoneMinder is designed around a series of independent components that only function when necessary limiting any wasted resource and maximising the efficiency of your machine. A fairly ancient Pentium II PC should be able to track one camera per device at up to 25 frames per second with this dropping by half approximately for each additional camera on the same device. Additional cameras on other devices do not interact so can maintain this frame rate. Even monitoring several cameras still will not overload the CPU as frame processing is designed to synchronise with capture and not stall it.
As well as being fast ZoneMinder is designed to be friendly and even more than that, actually useful. As well as the fast video interface core it also comes with a user friendly and comprehensive PHP based web interface allowing you to control and monitor your cameras from home, at work, on the road, or even a web enabled cell phone. It supports variable web capabilities based on available bandwidth. The web interface also allows you to view events that your cameras have captured and archive them or review them time and again, or delete the ones you no longer wish to keep. The web pages directly interact with the core daemons ensuring full co-operation at all times. ZoneMinder can even be installed as a system service ensuring it is right there if your computer has to reboot for any reason.
The core of ZoneMinder is the capture and analysis of images and there is a highly
Re: [Mageia-dev] Need mentor(s) to become a Mageia packager
2011/6/30 Vincent vincent.hervi...@gmail.com Hi All, I would like to participate to your project and to help you by packaging rpms. As I don't know what needs to be packed, I've tried to make rpm for ZoneMinder 1.24.4. But it fails to install into BUILDROOT environment. I must have done something wrong while setting installation destinations. Attached is the spec file, and the patch to make it compiled. If any mentor could help me, or assign me something else to pack, I would be glad. Regards Thanks for your proposal, of course any help on packaging side is welcome. Here are some wiki page to read about mentoring process: http://mageia.org/wiki/doku.php?id=packagings[]=mentor#packagers_organization http://mageia.org/wiki/doku.php?id=packagings[]=mentor#resources http://mageia.org/wiki/doku.php?id=packages_mentoring and http://mageia.org/wiki/doku.php?id=packager_start You can apply here on -dev ML looking for a mentor Also we have weekly meeting on IRC you can attend if you are around Welcome on board (or in hell as you want) At the moment we are organizing a mentoring team. Please have some patience. Regards Magnus Vincent
[Mageia-dev] [RFC] Update to Gnome 3.1
Hello, i would like us to update to gnome 3.1 ( which will give gnome 3.2 ). Is there someone against ?
Re: [Mageia-dev] [115962]
2011/6/29 John Balcaen mik...@mageia.org: 2011/6/29 r...@mageia.org: Revision 115962 Author ze Date 2011-06-29 15:57:57 +0200 (Wed, 29 Jun 2011) Log Message - no need to buildrequire and use kde-macros - use rpm native macros and not variables [...] We were using kde4-macros especially because attica is maintained requires by KDE, so it's easier to follow it (like a urpmf --requires kde4-macros Core_Release_SRPMS ) Since attica only needs qt4 theres no need to use kde-macros, thats why you also have qt cmake macros like %cmake_qt4 -- -- Balcaen John -- Zé
Re: [Mageia-dev] [115561] add versioned requires for common package
2011/6/29 John Balcaen mik...@mageia.org:
2011/6/29 r...@mageia.org:
Revision 115561 Author fwang Date 2011-06-29 06:48:40 +0200 (Wed, 29 Jun
[...]
Modified: cauldron/libkipi/current/SPECS/libkipi.spec
===
--- cauldron/libkipi/current/SPECS/libkipi.spec 2011-06-29 04:47:46
UTC (rev
115560)
+++ cauldron/libkipi/current/SPECS/libkipi.spec 2011-06-29 04:48:40
UTC (rev
115561)
@@ -39,7 +39,7 @@
%package -n %{libkipi}
Summary: libkipi library
Group: System/Libraries
-Requires: kipi-common
+Requires: kipi-common = %{epoch}:%{version}
[...]
Should we really have a library requiring an other package ? (via an
explicit Requires i mean)
(maybe we should move this requires to somewhere else ? )
I remember we did agreed on this, that a lib package having explicite
requires is not a good idea, but since the require already existed
there i just set versioning
But as you now know this is being fixed :)
--
Zé
Re: [Mageia-dev] [115962]
On Thursday 30 June 2011 22:09:15 Zé wrote: 2011/6/29 John Balcaen mik...@mageia.org: 2011/6/29 r...@mageia.org: Revision 115962 Author ze Date 2011-06-29 15:57:57 +0200 (Wed, 29 Jun 2011) Log Message - no need to buildrequire and use kde-macros - use rpm native macros and not variables [...] We were using kde4-macros especially because attica is maintained requires by KDE, so it's easier to follow it (like a urpmf --requires kde4-macros Core_Release_SRPMS ) Since attica only needs qt4 theres no need to use kde-macros, thats why you also have qt cmake macros like %cmake_qt4 I know that it's just using qt4 but we're using kde4 macros as convention here following our kde's spec layout. -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Update of backport, policy proposal
Samuel Verschelde a écrit : Le mardi 28 juin 2011 03:44:24, andre999 a écrit : 2) Backports would not be removed from repos when a newer backport arrives, except those affected by security updates. This allows reverting to previous backports if a user finds a problem with a backport on their system. I'd prefer that we don't keep multiple backports versions in the repositories, for the sake of simplicity. Users who ask for the latest must accept that sometimes the latest is not the greatest. Plus, we have the backports_testing repos so that users can test and spot bugs before the old backport is replaced with the new one. I want stable : don't use backports. I want the latest : use backports. I want an intermediate version : no, sorry, your need is too specific. You can still compile it. I'm trying to consider the needs of a typical backport user, who needs to revert to a previous version of a backport already installed, due to problems with a newer backport. A problem which will often affect only some users installing the particular backport. They won't activate the backport repository. So when installing backports, they will only see a list of backports (at least via rpmdrake). They are not necessarily familiar with compiling (unlike most of us). Suppose for a package release A we have issued backports B and C. If B causes problems on a particular system, the user reverts to A. No problem. If a user has installed B, which worked well for them, and subsequently installes C which has problems, they would like to revert to B. (Reverting to A could cause a loss of data as well as functionality.) So why tell the user that they can't revert to a backport version that already worked for them ? I would suggest a message such as : users installing backports should install the latest version for the package unless they need to revert to a previous version due to problems (To appear only when they have chosen to install backports.) I realise that this complicates the presentation, and maybe another solution could be found. (For example, saving all backports packages installed on a system, so that they can be reinstalled.) (A case-by-case analysis of new backports could show which previous backports could be safely removed, for minor changes such as simple bug fixes.) Or maybe make these backports only visible with urpmi, so that users of the graphic interfaces won't see them. (As someone else suggested.) This would of course require the graphic interfaces to avoid displaying these older backports, but would provide the other advantages of keeping the backports. Keeping previous backports would facilitate producing security updates for all backports actually installed on various user's systems. This adds some complexity for security updates, in exchange for greater security. Samuel -- André
Re: [Mageia-dev] Firefox 5
On Thu, 23 Jun 2011, Luc Menut wrote: Le 23/06/2011 07:58, Dexter Morgan a écrit : On Thu, Jun 23, 2011 at 7:29 AM, Thierry Vignaud thierry.vign...@gmail.com wrote: On 22 June 2011 19:41, Florian Hubolddoktor5...@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.. ... 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 Yes, I think Firefox 5 should be an updates. Firefox 5 is a security update for Firefox 4 and 4.0.1. There will be no Firefox 4.0.2. Yes, as patch to fix security are not provided for firefox 4, and not easy to backport, it needs to be updated to version 5. It is listed as an exception on the updates policy page : http://mageia.org/wiki/doku.php?id=updates_policy
[Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of course), the bloody m*f*er kded4 (the worse idea in KDE4) constantly takes 55-75% CPU. Of course, killing it is possible, but this affects the plasmoids. (E.g. it made me inadvertently filling an invalid bug report 1981, which disappeared once I let kded4 live.) Really, isn't anybody experiencing high CPU from kded4? (This is making me crazy. Otherwise, I'll tell you some day about a bug/crash that was *accidentally* fixed by KDE 4.6.90.) Thanks, R-C aka beranger
Re: [Mageia-dev] [RFC] Update to Gnome 3.1
On Thu, 30 Jun 2011, Dexter Morgan wrote: Hello, i would like us to update to gnome 3.1 ( which will give gnome 3.2 ). When is the release of gnome 3.2 planned ?
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
On Thu, Jun 30, 2011 at 19:34, Radu-Cristian FOTESCU beranger...@yahoo.cawrote: This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of course), the bloody m*f*er kded4 (the worse idea in KDE4) constantly takes 55-75% CPU. Of course, killing it is possible, but this affects the plasmoids. (E.g. it made me inadvertently filling an invalid bug report 1981, which disappeared once I let kded4 live.) The solution which worked most of the time for such issues in kde 4.6.xx was: 1. open a terminal 2. run killall plasma-desktop 3. plasma-desktop the plasmoids and the desktop come back, and kded4 stops using that much CPU. Last time I looked what it was looking CPU at, it was caused by some run-away timer loop deep in kdelibs, but as those issues are quite random I haven't figured out what exactly causes this. -- Eugeni Dodonov http://eugeni.dodonov.net/
Re: [Mageia-dev] [RFC] Update to Gnome 3.1
On Fri, Jul 1, 2011 at 12:41 AM, nicolas vigier bo...@mars-attacks.org wrote: On Thu, 30 Jun 2011, Dexter Morgan wrote: Hello, i would like us to update to gnome 3.1 ( which will give gnome 3.2 ). When is the release of gnome 3.2 planned ? in october so we will at least have gnome 3.2.x in mageia 2
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
The solution which worked most of the time for such issues in kde 4.6.xx was: 1. open a terminal 2. run killall plasma-desktop 3. plasma-desktop the plasmoids and the desktop come back, and kded4 stops using that much CPU. Last time I looked what it was looking CPU at, it was caused by some run-away timer loop deep in kdelibs, but as those issues are quite random I haven't figured out what exactly causes this. Евгений, thank you, but this is not a solution. It is not a solution because, as soon as plasma-desktop is back, kded4 takes the same 55...75% CPU. It is not a solution because, even if it were a temporary fix, it needed to be run after each and every login. Now, I know my KDE is somewhat b0rken, because akonadiserver can't start -- but I could live just fine this way in KDE 4.6.3-4.6.4, if not even better than with it. So I should report this as a bug, however I won't do it as long as I'm the only Cauldron user to experience it. OTOH, let me tell you how to crash *any* KDE4 version (have to report it upstream, works on F15 too): 1. Folder View for the Desktop. 2. Click on a desktop icon, F2 (rename), select the text, right-click (as a reflex to find a menu with Copy); 3. plasma-desktop glorious crash. Here's the KDE bug that was fixed by accident in KDE 4.6.90: Upstream bug 235020, with duplicates 228036, 236800, 256257, 255393, 256993, 257591, 262912, 264287, 264664, 265064, 265823, 266245, 270591, 272198, 272662, 274792, 274135, 274659, 275301, 275906, 275906, 276020, 276261. In short: KCharSelect crashes in some circumstances. How to make KCharSelect crash on any version up to and including 4.6.4: 1. Open KCharSelect and make it have the minimum horizontal size (it should display 18 characters on a row; if it doesn't, keep it at this size nevertheless); 2. Select the DejaVu Sans or any other DejaVu typeface. 3. Keep European Alphabets in the first drop-down list. 4. In the second drop-down list, start to switch the code pages between the available ones, in order: -- Basic Latin -- Latin-1 Supplement -- Latin Extended A -- Latin Extended B -- Latin Extended Additional -- Latin Extended C -- Latin Extended D and so on. 5. It should have crashed by now. If not, keep switching back and forth between the code pages until it does! The bug is actually triggered by unknown errors in some fonts (the DejaVu family being one of them). It's funny to use KDE4 (I was a GNOME guy, that is, until GNOME Shell was announced). Except that kded4 is not funny. Best regards, R-C aka beranger
Re: [Mageia-dev] [115962]
2011/6/30 Balcaen John mik...@mageia.org: On Thursday 30 June 2011 22:09:15 Zé wrote: 2011/6/29 John Balcaen mik...@mageia.org: 2011/6/29 r...@mageia.org: Revision 115962 Author ze Date 2011-06-29 15:57:57 +0200 (Wed, 29 Jun 2011) Log Message - no need to buildrequire and use kde-macros - use rpm native macros and not variables [...] We were using kde4-macros especially because attica is maintained requires by KDE, so it's easier to follow it (like a urpmf --requires kde4-macros Core_Release_SRPMS ) Since attica only needs qt4 theres no need to use kde-macros, thats why you also have qt cmake macros like %cmake_qt4 I know that it's just using qt4 but we're using kde4 macros as convention here following our kde's spec layout. But that layout is to apply for kde packages and for the ones that require kde, when thats not the case why is there any need to apply kde macros? I dont see the point for that. -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net -- Zé
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
On Thursday 30 June 2011 15:34:50 Radu-Cristian FOTESCU wrote: This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of course), the bloody m*f*er kded4 (the worse idea in KDE4) constantly takes 55-75% CPU. Of course, killing it is possible, but this affects the plasmoids. (E.g. it made me inadvertently filling an invalid bug report 1981, which disappeared once I let kded4 live.) Really, isn't anybody experiencing high CPU from kded4? Nop you're not the only one. However here killing this process does not seems to affect my plasmoids. It could be an upstream bug but it would be nice to narrow it. @ first i was looking @ the nm applet, but a fresh install (by dropping all package only install the minimum aka kmail, dolphin,kdebase4-workspace) does not fix the problem (there's an upstream bug related to kded with networkmanagement kde #220047) (This is making me crazy. Otherwise, I'll tell you some day about a bug/crash that was *accidentally* fixed by KDE 4.6.90.) Which one ? ;o) -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
On Thursday 30 June 2011 16:10:46 Radu-Cristian FOTESCU wrote: [...] Now, I know my KDE is somewhat b0rken, because akonadiserver can't start -- but I could live just fine this way in KDE 4.6.3-4.6.4, if not even better than with it. Well only kdepim is broken so it's not a big deal if you're not using it. (You should be able to use akregator). -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
Le 2011-06-30 18:34, Radu-Cristian FOTESCU a écrit : This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of course), the bloody m*f*er kded4 (the worse idea in KDE4) constantly takes 55-75% CPU. Of course, killing it is possible, but this affects the plasmoids. (E.g. it made me inadvertently filling an invalid bug report 1981, which disappeared once I let kded4 live.) Really, isn't anybody experiencing high CPU from kded4? (This is making me crazy. Otherwise, I'll tell you some day about a bug/crash that was *accidentally* fixed by KDE 4.6.90.) Thanks, R-C aka beranger Mine was doing this and I tried to stop it (I don't really know how to do this), so in the end I let it go. It has now stopped. Could it be that it is indexing all of your files? I know that I have 600 gigs of data, and, if KDE4 was trying to index all of these files (photos, music and larger LibreOffice files that it would take quite a while to index them. Maybe this is the problem? My CPU has returned to normal after a couple days of churning. I also never log-out of my system. Cheers Marc
Re: [Mageia-dev] libperl not found
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
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
On Thursday, June 30, 2011 05:23:58 pm Marc Paré wrote: Le 2011-06-30 18:34, Radu-Cristian FOTESCU a écrit : This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of course), the bloody m*f*er kded4 (the worse idea in KDE4) constantly takes 55-75% CPU. Of course, killing it is possible, but this affects the plasmoids. (E.g. it made me inadvertently filling an invalid bug report 1981, which disappeared once I let kded4 live.) Really, isn't anybody experiencing high CPU from kded4? (This is making me crazy. Otherwise, I'll tell you some day about a bug/crash that was *accidentally* fixed by KDE 4.6.90.) Thanks, R-C aka beranger Mine was doing this and I tried to stop it (I don't really know how to do this), so in the end I let it go. It has now stopped. Could it be that it is indexing all of your files? I know that I have 600 gigs of data, and, if KDE4 was trying to index all of these files (photos, music and larger LibreOffice files that it would take quite a while to index them. Maybe this is the problem? My CPU has returned to normal after a couple days of churning. I also never log-out of my system. Cheers Marc I get 50% on a VM -- Thomas
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 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
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] Anybody having high CPU by kded4 after upgrading to 4.6.90?
(This is making me crazy. Otherwise, I'll tell you some day about a bug/crash that was *accidentally* fixed by KDE 4.6.90.) Which one ? ;o) See https://mageia.org/pipermail/mageia-dev/2011-July/006180.html R-C
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
Could it be that it is indexing all of your files? NOPE. I never ever use indexing, no matter what the OS is. R-C
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
Well only kdepim is broken so it's not a big deal if you're not using it. (You should be able to use akregator). Yes, akregator works just fine. R-C
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
However here killing this process does not seems to affect my plasmoids. I'm surprised to see you writing it. After killing kded4: 1. Klipper was not reacting. 2. The keyboard layout systray icon was dead. 3. Any changes in the way the clock is displayed (hour/date format) were not applied. 4. Hibernation was completely broken (doing nothing), only logout, shutdown and restart worked. 5. Power Management profiles were not displayed and could not be editer, nor were they functional. Other effects might have taken place, that was at first sight. So kded4 is indeed a *vital* process of the KDE4 desktop. It could be an upstream bug but it would be nice to narrow it. @ first i was looking @ the nm applet, but a fresh install (by dropping all package only install the minimum aka kmail, dolphin,kdebase4-workspace) does not fix the problem (there's an upstream bug related to kded with networkmanagement kde #220047) Not easy to narrow it here either. If it's an upstream one (can't test 4.6.90 in other distro for now), then the upstream QA is non-existent. R-C aka beranger
[Mageia-dev] About the input method in KDE
https://bugs.mageia.org/show_bug.cgi?id=1836 There's a special plasmoid which can help with user experience of those who used input method, but ever since the package request, there's no response. Would someone help with this one? Since we have determined to use iBus as the default input method, then iBus version of kimpanel backend should be included, not just scim version.
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
I was trying to investigate the kded4 high CPU load, and I started to investigate some upstream reports, even if not necessarily reported for 4.6.90. Some such reports were related to ntrack, e.g. http://bugs.kde.org/268038 What the heck is ntrack and why do we need it? (The official description tells me exactly nothing). There is *no* ntrack in either of Mandriva or Fedora -- it's actually likely to be an Ubuntu project; either way, it's definitely *not* part of the KDE4 project, as it's hosted on https://launchpad.net/ntrack Then why the heck removing libntrack0 wants to remove *all* the KDE??? Is Mageia becoming Kubuntu? All these excessive dependencies are making me sick. Everything depends on everything. Is dynamic loading of libraries, with dynamically getting pointers to functions and using them or not, depending on availability, a mechanism that only works in Windows? Then, you'll excuse me, for the fist time in 9 days, I'll reboot into XP SP3. And I'm doing that because, after having rebooted in F15, their plasma (4.6.3) crashed on me for 3 times in 5 minutes. This is unbearable. Pissed off, R-C aka beranger
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
2011/7/1 Marc Paré m...@marcpare.com Mine was doing this and I tried to stop it (I don't really know how to do this), so in the end I let it go. It has now stopped. Could it be that it is indexing all of your files? I know that I have 600 gigs of data, and, if KDE4 was trying to index all of these files (photos, music and larger LibreOffice files that it would take quite a while to index them. Maybe this is the problem? My CPU has returned to normal after a couple days of churning. I also never log-out of my system. I don't believe. My installation has no data. One core is using continuously 100% (with sometimes switching the core) Magnus
